Tilix: 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! :+1:

[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]

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]

Ok, waiting for the fixed GtkD release.

[dsboger]

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" [email protected] 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
https://github.com/gnunn1/terminix/issues/25#issuecomment-174201192.

[dsboger]

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]

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 [email protected] 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
https://github.com/gnunn1/terminix/issues/25#issuecomment-174238437.

[dsboger]

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]

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]

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]

@Conan-Kudo Understood, unfortunately like I said earlier though I don't have enough familiarity with Make to do this very easily. GtkD does use a make file though, I'll have a look at it when I get some time.

[dsboger]

I have pushed to AUR a new version of the PKGBUILD for terminix-git [1]. This new version pulls latest GtkD from master. I've added a dub command to make it use the cloned repo for gtk-d dependency and another to forget it after building terminix. I have not much experience with dub, so I'm not sure I've done it the right way. Although the script seems to work, It'd be great if someone could review it.

[1] https://aur.archlinux.org/packages/terminix-git/

[gnunn1]

Had a quick look and seems reasonable to me. When the package gets built, you should see a bunch of .a files appear in the GtkD directory you cloned, if you see that then it is working correctly.

[Smando87]

Are you still interested in a copr repo for Fedora?

[gnunn1]

@Smando87 Absolutely

[Smando87]

give it a try :)
https://copr.fedorainfracloud.org/coprs/smando87/terminix/

[gnunn1]

@Smando87 I just tried it out, works very well. Are you willing to keep this up to date? If so, I'll disable the Fedora RPM build in OBS in favor of this and include this in the list of available builds.

Any chance you would add Redhat 7 to your copr so I can get rid of maintaining OBS completely?

[Smando87]

Yes i'll keep up to date, but give me about 2/3 days for automate the builds and extends the repo for other version of fedeora e REHL if possible.

[gnunn1]

@Smando87 Any update on this?

[paolostivanin]

I can create a PPA for Ubuntu 15.04, 15.10 and 16.04 :-) but I can do it only next week! :+1:

[gnunn1]

@paolostivanin Sure that would be great, thanks.

[edubxb]

Great @paolostivanin I can test the package in Debian Testing, and probably, in Unstable.

[graingert]

@paolostivanin any updates to the PPA?

[HeikoAdams]

Fedora COPR is in progress :smile:

[HeikoAdams]

My copr with v 0.55.0 is online: https://copr.fedorainfracloud.org/coprs/heikoada/terminix/

[gnunn1]

@HeikoAdams Are you willing to keep this COPR up to date, if so I'll deprecate my OBS version of the rpm's and link to your COPR on the project page.

[paolostivanin]

@graingert sorry all, but I have been very busy these days. By Friday night I will give you the link to the PPA :-)

[HeikoAdams]

@gnunn1 I'll try to keep it up to date.

[Conan-Kudo]

@HeikoAdams You're missing the %{?dist} tag in your spec Release field. See this Fedora wiki page on why you need it.

[HeikoAdams]

@Conan-Kudo yes, you're right. Will be fixed with next build

[davidgao]

Maybe we can still keep one OBS running? AFAIK COPR only builds for fedora, and it's sad to have rpms for fedora but not for openSUSE. OpenSUSE has a rolling distribution anyway.
I'll spend a few days to check specs. If I don't run into trouble, I could possibly be packaging for SUSE systems.

[gnunn1]

@davidgai I'm not even building an openSUSE rpm in OBS as far as I can tell? Anyway, I desperately want to get out of the business of managing and building packages as it takes time away from development, hence why I want to deprecate the OBS version. If you want to take it over and keep it up to date let me know :)

[davidgao]

True, I went through your OBS and found no openSUSE build. I'm currently
working on that thing offline. I'll inform you when my building scripts are
good enough.

[paolostivanin]

Hi, all, I'm working on the ppa right now!
cheers

[paolostivanin]

update: I have a problem with Launchpad, I have dput'ted the package correctly but I'm not getting the email notification that it has been accepted/rejected -.-

[davidgao]

update: packaged gtkd-3 for openSUSE on OBS, think I've done it properly. If things don't break, terminix should be there tomorrow.

[gnunn1]

@paolostivanin Any luck resolving the issue with launchpad? If there is anything I can do to help just let me know.

[khurshid-alam]

@paolostivanin Your ppa is empty. How are you uploding? Did you use debuild -S -sa? Can you show your code?....may be uploading it to a bazaar branch first?

[Kami-no]

Gentoo Overlay

[gnunn1]

Just an FYI, I'm shutting down the OBS build service I maintain at the end of April and getting out of the packaging business completely. It will be up to the community to create and maintain packages from that point forward. @dsboger does a great job with maintaining the Arch package, hopefully others will step up over time for the other distributions but I'm done spending time on packaging instead of developing.

[HeikoAdams]

@gnunn1 my COPR is back on the road and up2date again. :+1:

If somebody want's to help maintaining the COPR requests are welcome :smile:

[gnunn1]

@HeikoAdams That's great, but to put it on the front page as the official COPR it really needs to get updated a day or two after each release. If you can commit to that let me know.

[HeikoAdams]

@gnunn1 I've subscribed the releases feed so the COPR should be up2date in time

[gnunn1]

@HeikoAdams Thanks, I'll update the front page to point to your COPR and deprecate my OBS.

[kmf]

@paolostivanin how's the Ubuntu Packages coming along .... do you need assistance of some sort?

[paolostivanin]

Hi, all,
sorry for the long delay but I was busy with my master's thesis defense.
I tried to setup a new ppa, I dput'ted the package, everything went fine but I never received any confirmation email -.-
Honestly, I don't know what to do, it never happened to me before :-/

[alexanderad]

For those who is interested in getting terminix installed right away on Ubuntu 16.04:

$ sudo aptitude install deb
$ wget http://downloads.dlang.org/releases/2016/dmd_2.071.0-0_amd64.deb
$ sudo dpkg -i dmd_2.071.0-0_amd64.deb
$ git clone https://github.com/gnunn1/terminix.git && cd terminix
$ dub build --build=release
$ chmod +x install.sh
$ sudo ./install.sh

You are there! :dancer:

[graingert]

Don't really fancy running sudo ./install.sh
On 20 Apr 2016 08:44, "Alexander Shchapov" [email protected] wrote:

For those who is interested in getting terminix installed right away on
Ubuntu 16.04:

$ sudo aptitude install deb
$ wget http://downloads.dlang.org/releases/2016/dmd_2.071.0-0_amd64.deb
$ sudo dpkg -i dmd_2.071.0-0_amd64.deb
$ git clone https://github.com/gnunn1/terminix.git && cd terminix
$ dub build --build=release
$ chmod +x install.sh
$ sudo ./install.sh

You are there! [image: :dancer:]

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/gnunn1/terminix/issues/25#issuecomment-212304133

[alexanderad]

Well, this is the way you install any package, @graingert, isn't it? If it is deb, you'll run apt against it with sudo. You may want to supply prefix other than /usr it defaults to, but this is a different story then.

[gnunn1]

@graingert Completely understandable, hopefully at some point someone steps up and puts together a working deb file.

[freongrr]

@alexanderad, your instructions don't work for me. dud is not included in the package you linked to.

But installing dub and dmd from the official PPA works: http://d-apt.sourceforge.net/

[khurshid-alam]

@gnunn1 It is difficult to compile and create a deb (packaging binary into deb is different) under Ubuntu as dub and dmd are not available in Debian unstable. That means, you first need to get those binaries into ppa......then you can upload the source into the same ppa and let launchpad to compile....

May be we could send a mail to Debian mailing list or dub/dmd maintainer to upload it in Debian sid.

[paolostivanin]

@khurshid-alam that's what I tried to do. I have created packages for D, GtkD and Terminix but after I dput'ted D I've never received a confirmation/rejection e-mail from Launchpad -.-
Launchpad is the worst build system I have ever used...

[khurshid-alam]

@paolostivanin That's weird. Could you please upload your source to a bazaar branch or in Github....even a shared dropbox folder will do.....I will take a look. Thanks.

[gnunn1]

@khurshid-alam While not a PPA, is something like d-apt feasible?

http://d-apt.sourceforge.net/

[khurshid-alam]

@gnunn1 Sourceforge contains the binary.Launchpad does not allow uploading of binary packages directly. It needs you to upload the dsc file along changes and original tarball. Then the build system builds it in a clean chrooted environment. And you can add another ppa as a dependency.

That is why we need the source (along with debian folder) of dub and dmd. I tried with apt-get --allow-unauthenticated source gtkd, but I am getting authentication error.

[gnunn1]

@khurshid-alam Thanks for the detailed explanation, for those interested there is some discussion happening around getting D packaged for debian on the D forums, here is a link:

http://forum.dlang.org/thread/[email protected]

[mannol]

Shooting a blank here but, AppImage seems like a nice solution to a packaging problem.

[probonopd]

@mannol I have put together a quick AppImage which can be downloaded here. To use it download, chmod a+x, and run.

Works for me on Ubuntu 16.04, I did not test it on other distributions yet. Due to Terminix' dependencies on very new libraries which I did not bundle in this AppImage I would not expect it to run on much older distributions. Let me know how it goes.

[gnunn1]

@probonopd That's very cool, works well on my Arch system. If you (or someone else) is willing to keep this up to date I'd be happy to put a link to it with the other distributions on the front page.

[probonopd]

@gnunn1 Some more testing is required on different distros. What is the oldest distribution you are supporting?

[gnunn1]

@probonopd I see this more as an option for distributions where a package isn't available, in the case Ubuntu based ones are the biggest hole right now. Ubuntu 15.04 and Elementary Freya would probably be the oldest in that category. I also support RHEL 7.2 but it has an rpm package in COPR already so this would be less needed for that.

[probonopd]

@gnunn1 on elementary OS Freya it does not work due to the missing libvte-2.91.so.0 at the moment. Freya comes with libvte2_90.so.9.

PRETTY_NAME="elementary OS Freya"
VERSION_ID="0.3"
...
object.Exception@../../../.dub/packages/gtk-d-3.3.1/src/gtkc/Loader.d(123): 
Library load failed: libvte-2.91.so.0

I am not sure if bundling libvte inside the AppImage is a good idea because it draws in a huge load of dependencies.

Can you relax the libvte requirement and accept older versions too?

[gnunn1]

@probonopd Possibly, right now the vte library version is statically specified in GtkD in paths.d but there might be some options here. Give me some time to look into it.

[probonopd]

On CentOS 7 I get

2016-05-01T15:13:24.340:resource.d:getResource:102 Unexpected error loading resource /com/gexperts/Terminix/css/terminix.Adwaita.css
2016-05-01T15:13:24.340:resource.d:getResource:103 Error: The resource at '/com/gexperts/Terminix/css/terminix.Adwaita.css' does not exist

Any idea what I could do about it?

[gnunn1]

@probonopd You can ignore it, it has no impact on functionality. It's a result of adding per theme CSS support, I need to tweak things so theme CSS which isn't present isn't reported as an error.

[gnunn1]

@probonopd At the moment there is no way to downgrade the VTE as it is hard coded in GtkD. Thus I would only worry about distros with the supported VTE version for AppImage.

[probonopd]

OK, that's pretty much what https://bintray.com/probono/AppImages/Terminix/_latestVersion#files is doing right now.

[Mailaender]

Has anyone actually succeeded in getting a source build done? So far I have only seen repacks of pre-compiled binaries. See https://github.com/gnunn1/terminix/issues/304 for my failed attempts on creating a proper package for @openSUSE.

[dsboger]

@Mailaender terminix-git on AUR (https://aur.archlinux.org/packages/terminix-git/) compiles from source and works fine (I use it daily). Have a look at the build() function in the PKGBUILD (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=terminix-git, lines 25 to 36 plus 43 are only needed to avoid dub from pulling and building GtkD in the ~/.dub directory).

[Mailaender]

Thanks. That helped a lot. Finally: the first package that really compiles from source https://build.opensuse.org/request/show/394122

[gnunn1]

@Mailaender That's awesome, thanks for all of your work on this. If you are committed to keeping this up to date I would love to add a link to the project page to it, just let me know.

[Mailaender]

You can link https://software.opensuse.org/package/terminix which will pick up official packages as well as community packages of various quality. I could try to submit this to openSUSE:Factory, but the lacking dependency management of dub might cause the review to fail.

[probonopd]

Is anyone interested in adopting the AppImage?

[mehcode]

@probonopd For the app image -- can you add -w $HOME to the execute command? I get dumped in some weird directory.

[dsboger]

Hello folks, I'm doing an experiment of implementing autotools support for building terminix dynamically linked against system-wide gtkd/vted, without dub. Most of the process is working, but the gtkd-3 and vted-3 shared libraries must also have been compiled with dmd. What is not ironed out yet is the i18n/l10n support with gettext, especially updating the pot/po files with new strings (I'll use the script extract-strings.sh for now).

I intend to use that support in the terminix-git package in AUR, in the hopes that it might be merged upstream once properly tested. dub is nice for taking the build process out of the way of development, but not that nice for downstream packaging (and that is out of its scope, actually). What do you think?

[gnunn1]

@dsboger Sounds great, I would be quite happy to accept an autotools based build as an alternative to dub. Thanks for taking this on!

[khurshid-alam]

@probonopd It would be nice if you can set ARCH="all" in the appimage recipe....may be as a separate recipe just to check whether it can compile for i386/i686 (32 bit) as well. The thing is I want to run terminix everywhere including on older computers (at my office). :)

[dsboger]

I've pushed autotools support to my tree (https://github.com/dsboger/terminix). Updated terminix-git on AUR to latest release and changed it to build using autotools. terminix-git depends on gtkd-dmd (also on AUR) and links dinamically against it. I created gtkd-dmd because gtkd is compiled with ldc, but latest release of ldc cannot build terminix and we cannot link binaries from different compilers. Everything is on AUR already, re-testing everything right now.

EDIT: I'll make a PR as soon as I test it properly.

[probonopd]

@probonopd For the app image -- can you add -w $HOME to the execute command? I get dumped in some weird directory.

Done @mehcode, starting with the 0.60.0 AppImage.

check whether it can compile for i386/i686 (32 bit) as well

@dsboger I currently only do 64-bit builds but it would be trivial to also do 32-bit builds. I hope that someone from the terminix project (upstream) will take over the AppImage recipe and do "official" builds that are provided directly by the project, similar to https://musescore.org/en/download#AppImage

[gnunn1]

@probonopd Just to be clear, hopefully someone will volunteer to take over the AppImage but it won't be upstream in the sense of me (i.e. primary Terminix developer/maintainer) taking it over. I don't want to be in the packaging business, it takes too much time away from development and too much distro specific knowledge, hence this topic looking for volunteers.

I'm happy to support package maintainers though in any way I can other then actually being directly responsible for the packaging.

[gargullia]

@gnunn1 I want to be the repository maintainer for Ubuntu. What do I need? To become an official repository

[gnunn1]

@gargullia All I'm looking for is someone to create a PPA with a working deb package and is willing to keep it up to date. If you do that, I'd be happy to add a link on the Terminix home page to your PPA.

[hotice]

Until someone gets dmd and whatever other dependencies are missing from the official Ubuntu/Debian repositories, into the repos, I doubt someone will create a PPA for Terminix. Looking at dmd, it looks pretty complicated to package just for a PPA (and Launchpad PPAs can't depend on external repositories like the d-apt repo).

[graingert]

snap package?

[dsboger]

DMD Build script for Arch might help people that need to do it for other distros. Does not seem that complicated, although I only have experience with Arch-based packaging.

[mehcode]

@hotice Couldn't someone (I would but I just don't have the time) setup and maintain a binary PPA? Similar to https://github.com/alanfranz/atom-text-editor-repository

[gnunn1]

I've released a new 1.0.0 release of Terminix. As part of this, I've created a new branch called stable, as the name implies this branch is for the stable, production version of Terminix. Development will continue as it does now on the Master branch. The intent is that stable versions of packages build from the stable branch, git version of branches that are intended to reflect development in progress would build from master.

[probonopd]

Terminix-1.0.0-x86_64.AppImage

[egmontkob]

FYI: I've just filed a Debian RFP (Request For Package), hope this helps:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825069

[wilzbach]

Hi all,

I've just filed a Debian RFP (Request For Package), hope this helps:

The best is to make a bit of noise at dub, s.t. we get a common way to install dub packages for distributing.

https://github.com/dlang/dub/issues/839

For the Debian RFP it might help to ping @ximion - he probably can give you advice on how to proceed.

[dsboger]

Have you people given a try to the recently merged autotools support?

AUR terminix-git package is built with autogen.sh; ./configure; make; make install (I use it daily).

If it proves stable enough, we could politely ask for @gnunn1 to also release for every new version a source tarball generated with make dist.

[ximion]

@dsboger The autotools stuff seems to check for dmd things, and having dmd is a no-go in Debian due to its non-free license (unless of course we have all D stuff in the non-free repository, which would be pretty sad).
Regarding dub: In order to use it on distros, https://github.com/dlang/dub/issues/838 _must_ be resolved somehow otherwise we really can't ship this. Bonus points for resolving https://github.com/dlang/dub/issues/840 and https://github.com/dlang/dub/issues/839 too ^^
Additionally, GtkD loading GTK+ dynamically and shipping prebuilt files is an issue (not a hard-blocker though), because this means that the GTK+ package in Debian and the GtkD package might get out of sync easily, and packaging stuff which dynamically loads libraries at runtime is a bit less fun.

A RFP at Debian is a good start, but we really need to have these dub issues resolved to move forward...
Btw, D having an unstable ABI with differences between dmd, ldc and gdc is also really bad for distros, because in distros we do like shared libraries a lot (they simplify fixing bugs without rebuilding stuff). With the current state of matters we need to statically link all the things, which dub does anyway. Debian policy allows that, so it's no a problem per-se and rather an inconvenience.

Having Terminix in Debian would definitely be a great, on GNOME it IMHO is the best terminal emulator.

[phw]

The autotools stuff seems to check for dmd things, and having dmd is a no-go in Debian due to its non-free license

As terminix currently supports only DMD that's also an important issue unrated to the autotools Support.

[ximion]

As terminix currently supports only DMD that's also an important issue unrated to the autotools Support.

It does? In that case, that is an even more important issue to address - it must compile with LDC and/or GDC to be suitable for Debian main (GDC is probably a bit harder because its Phobos is pretty old, but making it work with LDC might be doable with less effort).

[gnunn1]

@ximion As you pointed out above, GDC and LDC use older versions of phobos/language spec and thus trail DMD so that's where the issue with Terminix is coming from. I'm not adverse to supporting LDC, assuming any changes I would need to make to the code are minimal, I just haven't had time to try it out and see where it is at with respect to phobos/language support. I tried GDC once, since I make heavy use of std.experimental.logger which isn't supported in GDC it was a no go for me. I'm not willing to start doing weird things like including my own copy of std.experimental.logger to make it work.

IMHO as you correctly point out DMD, LDC, and GDC to start aligning on the version of phobos they are including in terms of a stable, or least versioned, ABI.

[wilzbach]

I'm not adverse to supporting LDC, assuming any changes I would need to make to the code are minimal

Have you tried the latest ldc (1.0.0-beta2)? It has dmd-fe, dmd-be and Phobos at 2.070.2 now :)

[ximion]

@gnunn1 That's a perfectly valid point - I was also really disappointed to not find std.experimental.logger in GDC, and ended up writing my own, dumb logger because LDC wasn't working at that time (this changed meanwhile, I think).
Outdated Phobos and incompatible compilers is IMHO the biggest reason D adoption is so low. I am hoping for LDC to fix this, and maybe in a distant future compilers could stop bundling Phobos and we could build it independently from the compiler, given that they support a certain version of the D spec.

[dsboger]

@ximion Autotools builds Terminix dynamically linked against GtkD shared libraries. The issue is that both must be built with the same D compiler (that's why I created a gtkd-dmd package in AUR. gtkd package uses LDC) and Terminix only compiles with DMD.

If someone would write a ldc-git package for AUR, I'd be glad to test moving terminix-git to build with LDC. Of course I'll do the same tests when next version of LDC is officially released. That could pave the way for official packages everywhere, I think?!

[ximion]

@dsboger Jup, when Terminix compiles with LDC, there is no hard blocker for distributing it in other Linux distros.
For the "libraries loaded at runtime" thing, I was referring to GtkD itself loading GTK+ at runtime, which is kind of meh for distros, but wouldn't stop us from distributing it.
In Debian, we will likely need to make one D compiler the default to build stuff with, until D has a stable ABI that doesn't vary between compilers.
I'll try to compile Terminix with LDC Git tomorrow :-)

Btw, I was quite surprised to see that Arch allows non-free stuff in their community repos...

[wilzbach]

I'll try to compile Terminix with LDC Git tomorrow :-)

Works - see #355 ;-)

[wilzbach]

If someone would write a ldc-git package for AUR

Your wish has been heard. I currently let it conflict with ldc, s.t. it can be used as a drop-in replacement.
Let me know if you have other requirements for packaging.

https://aur.archlinux.org/pkgbase/ldc-git

[probonopd]

@gnunn1

I don't want to be in the packaging business

Understood, but would you consider a PR similar to this one that generates an AppImage from the build artifacts from your existing Travis CI builds?

[gnunn1]

@probonopd Sorry but I don't think so, I wouldn't be in a position to maintain it and fix any issues with it.

[gnunn1]

A note for package maintainers, with the addition of feature #135 there is a new shell integration script that should be packaged with terminix but should not be sourced in any fashion. The intent of this script is for the user to use it on remote systems that are accessed via SSH to integrate better with terminix. At this time the script is relatively simple but as more advanced features are added it will grow.

The install.sh script that generates the terminix archive packages the script in the /usr/share/terminix/scripts directory which is new. I'm open to discussion if there is a better spot for this to be located though.

[dsboger]

Given the fix to https://github.com/ldc-developers/ldc/issues/1534 has been merged, I can now compile and run Terminix with LDC from master, dynamically linked against gtkd-3 and vted-3 shared libraries.

[gnunn1]

Just an FYI, I'm planning on rolling out a new stable release of terminix in two weeks or so. This stable release will include the new design, background image support and automatic profile switching as well as miscellaneous bug fixes. I've run extract-strings and updated git with the new localizations so hopefully a couple of weeks will be enough for translators to catch up as much as possible.

[ximion]

For Debian, we really really really need https://github.com/dlang/dub/issues/838 fixed in order to continue... And of course, Terminix must compile with GDC or LDC.

[gnunn1]

@ximion Is the autotools build support that @dsboger added an option for debian?

[ximion]

@gnunn1 It doesn't help if Terminix has Autotools, all its build dependencies would need that too, and Terminix would need to find those dependencies when they were installed into $some_path.

[gnunn1]

@ximion The only dependency Terminix has is GtkD and it uses make.

[dsboger]

@ximion Terminix already compiles with LDC from git master. I have some commits that add support for LDC in autotools, but I'm waiting for the next release of LDC before pushing them (I may anticipate that PR, if you want to try it). The only dependency of Terminix is GtkD, which already builds with LDC and make; make install (check this)

EDIT: ugly typo.

[dsboger]

Also, GtkD supports pkg-config, so autotools support uses that to find the libs.

[ximion]

@gnunn1

The only dependency Terminix has is GtkD and it uses make.

Right, vted-3 is part of GtkD, I didn't see that.
Okay, then only LDC 1.0 is missing in Debian in order to continue (compiling with 0.17 fails here).

[crbelaus]

Maybe a snap package could help distributing Terminix accross multiple distributions. Currently it supports: Arch, Debian, Fedora, Gentoo and Ubuntu (maybe more).

[ximion]

@gnunn1 Legal review took a bit longer, but Terminix is available on Debian now.
It won't migrate into the release suite though until the LDC issues have been worked out. This is also the prerequisite for having it build correctly on Ubuntu and Tanglu. Konstantinos Margaritis, the LDC maintainer at Debian, is working on this.

• You can see the package's status for Debian at:
  https://tracker.debian.org/pkg/terminix
  Package for the unstable suite is available at https://packages.debian.org/sid/terminix
• For Ubuntu, Terminix is waiting on LDC: https://launchpad.net/ubuntu/+source/terminix
  Will be available at http://packages.ubuntu.com/yakkety/terminix after build.
• Same for the Tanglu Debian derivative: http://packages.tanglu.org/source/staging/terminix
  Build is waiting for a fixed LDC.

It might take a while for some of the pages linked above to become fully available (and contain all data we have for the package) since it's a new package, so be patient :-)

@gnunn1 Furthermore, did you know that the file data/gsettings/com.gexperts.Terminix.gschema.xml is licensed under GPL-3+? Ideally, to fully satisfy the requirements of the GPL, you should include a copy of the GPL together with the project's sources.
Also, you're saying you don't support 32bit: In Debian, we have a 32bit package, and also soon packages for ARM, ARM64 etc., so any testing on those architectures is highly welcome.

And that's it for now, Debian users should find Terminix in GNOME Software soon (if they use unstable).

[gnunn1]

@ximion thanks so much for your work on this, I really appreciate it.

[Tinche]

My attempts to snap Terminix have run into a snag: https://lists.ubuntu.com/archives/snapcraft/2016-July/000533.html

[gnunn1]

@Tinche Try disabling the DBus activation. First modify the terminix desktop:

Change:

DBusActivatable=true

To

DBusActivatable=false

And then delete the /usr//share/dbus-1/services/com.gexperts.Terminix.service file from the snap.

Hopefully that will do the trick.

[dsboger]

@gnunn1 Doing a quick test here, it seems that is not enough. I think any G[tk]Application will bind to a DBus name. Maybe there is a property/parameter that will prevent that?

[gnunn1]

@dsboger Thanks, looking at the snap PR referenced in the mailing list (https://github.com/snapcore/snapd/pull/1446) more closely it looks like GTKApplication is not supported at all at this point.

The only other thing I can suggest is to try running Terminix with the --new-process flag which constructs GtkApplication with the NON_UNIQUE flag but I suspect that it still binds to DBus.

[hotice]

I created a Terminix PPA for Ubuntu 16.04 / Linux Mint 18: https://launchpad.net/~webupd8team/+archive/ubuntu/terminix It's uses the official Debian packaging (thanks to the packagers!) with a minor tweak to get gtk-d to build in Ubuntu 16.04. I couldn't get ldc to build in Ubuntu 16.10 and I assume that's why the package is not in the official 16.10 repositories yet.

[kmf]

Awesome

[gnunn1]

@hotice That's awesome, thanks, I'll update the front page to include it. Also, thanks for the articles you've written about Terminix on webupd8, greatly appreciated as I certainly notice the increase in interest after each one.

[graingert]

@hotice do you need ldc built into the ppa?

[graingert]

@hotice ah it's for libphobos2-ldc71_1.1.0-2~webupd8~xenial_amd64.deb (1.0 MiB)

[gnunn1]

Just an FYI I've checked some stuff into master that hasn't been tested well so don't be surprised if git is unstable for a few days. Should have everything tidied up by the end of Sunday.

[gargullia]

@gnunn1 Will version 16.04 from the official repository?

[gnunn1]

@gargullia AFAIK it is still waiting on a fix for LDC, having said that I'm not the one doing the packaging so I'm not the best to ask, I'd have to defer to @ximion who did great work on this.

[gargullia]

@gnunn1 those. will release for 16.04 when it will be ready LDC

[ximion]

@gnunn1 @gargullia On Debian, LDC is FTBFSing on PowerPC, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833020 - this bug is ultimately https://github.com/ldc-developers/ldc/issues/1652 which hopefully will get resolved quickly. LDC currently has been dropped from Debian Testing because of this.
For Ubuntu, the status for 16.10 is tracked in https://bugs.launchpad.net/ubuntu/+source/ldc/+bug/1607432, I can compile LDC without issues, but apparently other have problems with it still.

16.04 will not have Terminix, unless someone doe the work and backports a newer LDC, GtkD and Terminix to xenial-backports (which is work I can't do and also find less useful, since a PPA for it exists).

[gnunn1]

Thanks for the detailed update @ximion, really appreciate it

[gargullia]

@gnunn1 @hotice Please correct the error: the installation of a repository webupd8 is put only the English language. Add Russian

[hotice]

@gargullia it looks like locale files aren't built with autotools (or maybe I'm missing something, but this is also the case for the official Debian package).

[gargullia]

@hotice The fact that locally generated. in the catalog usr/share/locale/ru}/LC_MESSAGES/terminix.mo file does not exist
Add # Compile po files echo "Copying and installing localization files" for f in po/*.po; do echo "Processing $f" LOCALE=$(basename "$f" .po) mkdir -p ${PREFIX}/share/locale/${LOCALE}/LC_MESSAGES msgfmt $f -o ${PREFIX}/share/locale/${LOCALE}/LC_MESSAGES/terminix.mo done

[dsboger]

AUR package terminix-git builds all locales. Are you building from master or latest stable? Do you have a LINGUAS file inside po directory? If not, you may try generating it like autogen.sh from master and building again.

[lots0logs]

@gnunn1 We're still packaging Terminix in our repo. The problems that we had initially with the automated builds have been resolved.

[hotice]

@dsboger Thanks. The issue was autogen.sh not being run.

@gargullia I updated the PPA, install the update and the localization files should be available.

[mihails-strasuns]

FYI: I can take over maintenance of Arch terminix package if you want - and eventually move it to [community] it there won't be much issues. Would wait for LDC to stabilize a bit first though.

[dsboger]

I'd be happy to hand terminix over so it could move to [community]. But please, notice that currently terminix in AUR just repackages the binaries provided by @gnunn1.

@gnunn1 Would you agree with moving the terminix package to be compiled with LDC, once no workarounds are needed?

@Dicebot I such case, you would also need to move gtkd to [community], I guess?

[gnunn1]

@dsboger Absolutely, no issue from me

[mihails-strasuns]

@dsboger

I'd be happy to hand terminix over so it could move to [community]. But please, notice that currently terminix in AUR just repackages the binaries

Ok, I'll check the current state of AUR package and write back. Please ping from your contact e-mail to [email protected]

I such case, you would also need to move gtkd to [community], I guess?

If gtkd provides own shared library. Arch Linux packaging policies are very different from Debian - it is ok to do internet downloads (i.e. via dub) but it is usually not ok to package header-only libraries. I will look into that.

[gnunn1]

For package maintainers, please note that the addition of a password manager from #443 adds optional dependencies on gnome-keyring and libsecret. I say optional dependencies since terminix should run fine without them however an error dialog will be displayed if the password manager is accessed without them present.

[dsboger]

@gnunn1 Does it depend on gnome-keyring itself (the binaries) or libgnome-keyring.so or both? Oddly we have separate packages for those on Arch.

[gnunn1]

@dsboger It actually does not depend on gnome-keyring directly, it should depend on libsecret, I should be more careful how I phrase things. Here is the libsecret package I have on my system:

https://www.archlinux.org/packages/extra/x86_64/libsecret/

[dsboger]

@gnunn1 Understood. It seems libsecret optionally depends on gnome-keyring itself. I don't know much about these packages, but it seems gnome-keyring provides a DBus service that libsecret uses?

terminix-git updated.

[vltr]

Hello! I bumped into a "problem" many users (perhaps one reported and at least I'm the second one) have been complaining about building GtkD from AUR. I know its the only dependency for building terminix (from AUR), so I'll share what I found here too -- it may help packaging or troubleshooting.

For some [unknown/random/buggy/special/unlisted/non-checked/i-dont-have-time] reason, spawning multiple jobs seems to break gtkd build, exactly like @marcio mentioned. By using -j1, the build went just fine in here. I hope it helps someone, at least for now ;)

I'm sorry I can't do anything _for now_ (I'm really out of spare time), but I'll love to work on terminix - I was looking for a terminal app to swap from terminator for a long time! Not that terminator isn't good ... It has been a faithful friend for almost a decade :smile:

[gnunn1]

Just an FYI that I may have broken autotools, I needed to add a dependency in dub.json for an X11 library in order to see if it resolves a focus issue with quake mode on Ubuntu. If it does resolve the issue, I may need some help figuring out the best to handle this dependency while maintaining while ensuring terminix can still be built by packagers.

[ximion]

@gnunn1 Try Meson ;-) It works quite well for D projects, with the only exception of not rebuilding dependencies properly sometimes, due to LDC/GDC/DMD not providing GCC-conformant depfiles or not providing depfiles at all or having broken depfile generation.

At least for me, using Meson would mean I could drop some (minor) hacks from the Debian packaging.

[gnunn1]

@ximion Thanks for the reminder, how does meson handle dependencies which need to be downloaded from the dub repository like this X11 library I'm trying out here?

[ximion]

@gnunn1 Hah, that's a tricky thing - until someone writes a native dub interface, Meson will only handle this dependency properly if it also has a Meson build definition.
If that is the case, adding it is easy: https://github.com/mesonbuild/meson/wiki/Wrap-dependency-system-manual

If this is not the case, you can still use the library, but only with some hacks in Meson itself, making it call dub to download & build a static library and adding that to the build.

[gnunn1]

@ximion Thanks, I'll check that out.

[ximion]

@gnunn1 In general, pure D dependencies make a very sad story on distributions at time, due to the ABI incompatibilities between the different D compilers, no real standard to find D headers or D source code (in case the dependency is source-only) and dub not being suitable for use with the way Linux distros work at time.
Meson helps a bit here though, by eliminating the dub issues :P

[gnunn1]

Looks like this fixes the bug so I'll need to include this library, I'll try to figure out a way to do it that is packaging friendly but not sure how likely that is. I'm not keen on spending a ton of time on sorting this out.

[ximion]

Which library are we talking about exactly?

[gnunn1]

It is this one https://github.com/nomad-software/x11 which is a fork of https://github.com/D-Programming-Deimos/libX11. The original one can be built as a static lib whereas the fork is focused on dub.

Would a git submodule be an option for the fork, essentially allow it's code to be fetched as part of the clone and built with in-line with terminix?

[khurshid-alam]

Just to let you people know that i386/armhf builds for ldc are failing in Yakkety.

ldc source: https://launchpad.net/ubuntu/+source/ldc/1:1.1.0git216c112-1ubuntu2
Build log: https://launchpadlibrarian.net/284680317/buildlog_ubuntu-yakkety-i386.ldc_1%3A1.1.0git216c112-1ubuntu2_BUILDING.txt.gz

So can't compile on yakkety.

[gnunn1]

@khurshid-alam That's building with the 32 bit compiler isn't it, generally I don't actively support 32 bit architectures. Having said that, if someone wants to submit PRs to fix 32 bit issues I'm happy to accept them as I have in the past.

[ximion]

@gnunn1 @khurshid-alam Nah, that's looking like an LDC bug. Please help resolving https://github.com/ldc-developers/ldc/issues/1774 to get this working again.

[ximion]

@gnunn1 As for the dependency-issue: Embedding is normally frowned upon at Debian, but it would be okay in this case, I think - especially since you will be the only project using this piece of code.
A submodule will be pain for you though, since Git doesn't include submodules in automatically generated release tarballs, you would need to manually make one.
Maybe just adding the files / importing the functions you need makes sense.

I could also quickly convert the dependency to Meson, looks rather easy to do ^^

[gnunn1]

@ximion I'm trying out embedding, it works fine and I only need two files from that repository but it's not sustainable. I really need a longer term way to use arbitrarily use DUB libraries as needed.

I'd be interested in seeing the Meson approach if you are willing to do it and it's easy to do, I'm really out of my depth here in terms of C build tools as I'm a Java guy in my day job.

@dsboger Do you have any thoughts about this?

[gnunn1]

I've embedded the two X11 files I'm using from that package instead of using the dub dependencies for now. @dsboger could you update the autotools to include x11 as a library dependency, I'm struggling to get it working.

[dsboger]

@gnunn1 I'm working on it now. I'll post a PR as soon as I can make it build.

[mihails-strasuns]

@ximion would you be interested in a new tool that simply fetches dub registry packages if they are not found locally? I am not interested in meson but do also have problems with dub coupling of build system and dependency management.

[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]

@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]

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]

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:

    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: https://github.com/ldc-developers/ldc/issues/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 .