New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need package maintainers #25

Closed
gnunn1 opened this Issue Jan 15, 2016 · 203 comments

Comments

Projects
None yet
@gnunn1
Owner

gnunn1 commented Jan 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bilelmoussaoui

bilelmoussaoui Jan 15, 2016

Contributor

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

Contributor

bilelmoussaoui commented Jan 15, 2016

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

@gnunn1 gnunn1 changed the title from Need an Arch package maintainer to Need a package maintainers Jan 15, 2016

@gnunn1 gnunn1 changed the title from Need a package maintainers to Need package maintainers Jan 15, 2016

@gnunn1 gnunn1 added the help wanted label Jan 17, 2016

@gnunn1

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Jan 18, 2016

Owner

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.

Owner

gnunn1 commented Jan 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dsboger

dsboger Jan 18, 2016

Contributor

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.

Contributor

dsboger commented Jan 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Jan 18, 2016

Owner

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?

Owner

gnunn1 commented Jan 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Jan 18, 2016

Owner

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

Owner

gnunn1 commented Jan 18, 2016

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

@dsboger

This comment has been minimized.

Show comment
Hide comment
@dsboger

dsboger Jan 18, 2016

Contributor

Ok, waiting for the fixed GtkD release.

Contributor

dsboger commented Jan 18, 2016

Ok, waiting for the fixed GtkD release.

@dsboger

This comment has been minimized.

Show comment
Hide comment
@dsboger

dsboger Jan 23, 2016

Contributor

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?

Contributor

dsboger commented Jan 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Jan 23, 2016

Owner

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).

Owner

gnunn1 commented Jan 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dsboger

dsboger Jan 23, 2016

Contributor

Ok, understood, i686 removed from terminix-git.

Contributor

dsboger commented Jan 23, 2016

Ok, understood, i686 removed from terminix-git.

@gnunn1

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Jan 23, 2016

Owner

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.

Owner

gnunn1 commented Jan 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dsboger

dsboger Jan 24, 2016

Contributor

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.

Contributor

dsboger commented Jan 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Jan 24, 2016

Owner

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).

Owner

gnunn1 commented Jan 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dsboger

dsboger Jan 24, 2016

Contributor

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.

Contributor

dsboger commented Jan 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Jan 24, 2016

Owner

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.

Owner

gnunn1 commented Jan 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Jan 24, 2016

Owner

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

Owner

gnunn1 commented Jan 24, 2016

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

@gnunn1

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Jan 24, 2016

Owner

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.

Owner

gnunn1 commented Jan 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Jan 27, 2016

Owner

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.

Owner

gnunn1 commented Jan 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@luisdavim

luisdavim Feb 10, 2016

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

luisdavim commented Feb 10, 2016

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

@gnunn1

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Feb 10, 2016

Owner

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

Owner

gnunn1 commented Feb 10, 2016

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

@edubxb

This comment has been minimized.

Show comment
Hide comment
@edubxb

edubxb Feb 11, 2016

Contributor

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.

Contributor

edubxb commented Feb 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@carlwgeorge

carlwgeorge Feb 12, 2016

Creating a proper Makefile would be very beneficial to packagers.

carlwgeorge commented Feb 12, 2016

Creating a proper Makefile would be very beneficial to packagers.

@gnunn1

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Feb 12, 2016

Owner

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.

Owner

gnunn1 commented Feb 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dsboger

dsboger Feb 18, 2016

Contributor

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.

Contributor

dsboger commented Feb 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Feb 19, 2016

Owner

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.

Owner

gnunn1 commented Feb 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dsboger

dsboger Feb 19, 2016

Contributor

Done.

Contributor

dsboger commented Feb 19, 2016

Done.

@Conan-Kudo

This comment has been minimized.

Show comment
Hide comment
@Conan-Kudo

Conan-Kudo Feb 23, 2016

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

Conan-Kudo commented Feb 23, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Sep 30, 2016

Owner

I've pushed 1.30 as a stable release.

Owner

gnunn1 commented Sep 30, 2016

I've pushed 1.30 as a stable release.

@ximion

This comment has been minimized.

Show comment
Hide comment
@ximion

ximion Sep 30, 2016

Contributor

@Dicebot That would already be very helpful!

Contributor

ximion commented Sep 30, 2016

@Dicebot That would already be very helpful!

@ximion

This comment has been minimized.

Show comment
Hide comment
@ximion

ximion Oct 15, 2016

Contributor

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

Contributor

ximion commented Oct 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Nov 3, 2016

Owner

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

Owner

gnunn1 commented Nov 3, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@dsboger

dsboger Nov 3, 2016

Contributor

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

Contributor

dsboger commented Nov 3, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Nov 3, 2016

Owner

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

Owner

gnunn1 commented Nov 3, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@dsboger

dsboger Nov 3, 2016

Contributor

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?

Contributor

dsboger commented Nov 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Nov 3, 2016

Owner

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.

screenshot from 2016-11-03 13-46-51

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.

Owner

gnunn1 commented Nov 3, 2016

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.

screenshot from 2016-11-03 13-46-51

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Nov 3, 2016

Owner

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.

Owner

gnunn1 commented Nov 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dsboger

dsboger Nov 3, 2016

Contributor

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)?

Contributor

dsboger commented Nov 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Nov 3, 2016

Owner

@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!).

Owner

gnunn1 commented Nov 3, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Nov 14, 2016

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 commented Nov 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@egmontkob

egmontkob Nov 14, 2016

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 :)

egmontkob commented Nov 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Dec 9, 2016

Owner

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.

Owner

gnunn1 commented Dec 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Jan 8, 2017

Owner

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.

Owner

gnunn1 commented Jan 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Feb 18, 2017

Owner

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

Owner

gnunn1 commented Feb 18, 2017

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

@gnunn1 gnunn1 closed this Feb 18, 2017

@bilelmoussaoui

This comment has been minimized.

Show comment
Hide comment
@bilelmoussaoui

bilelmoussaoui Mar 12, 2017

Contributor

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

Contributor

bilelmoussaoui commented Mar 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ivoarch

ivoarch Mar 12, 2017

Contributor

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

ivoarch commented Mar 12, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@bilelmoussaoui

bilelmoussaoui Mar 12, 2017

Contributor

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

Contributor

bilelmoussaoui commented Mar 12, 2017

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

@hotice

This comment has been minimized.

Show comment
Hide comment
@hotice

hotice Mar 15, 2017

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

hotice commented Mar 15, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@gnunn1

gnunn1 Mar 15, 2017

Owner

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

Owner

gnunn1 commented Mar 15, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ximion

ximion Apr 4, 2017

Contributor

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.

Contributor

ximion commented Apr 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ivoarch

ivoarch Apr 8, 2017

Contributor

EPEL Package for CentOS 7 via CORP .

Contributor

ivoarch commented Apr 8, 2017

EPEL Package for CentOS 7 via CORP .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment