# how to get zenmap back

## russK

I'm not exactly sure when I lost zenmap.  I found this thread that touches on it:  here

So I'm learning that something about python or gtk or whatever is dragging it down, and it seems the ebuild silently decides to build nmap without zenmap.  Perhaps I missed a news read.

Does anyone know how to get zenmap back?

Thanks for any hints.

----------

## Ant P.

Does USE=zenmap emerge -av nmap work?

----------

## steve_v

 *Ant P. wrote:*   

> Does USE=zenmap emerge -av nmap work?

 

Nope. zemap USE flag removed 2020-05-21.

Due to pygtk/python 2.7 deprecation, there is no zenmap in portage ATM. 

This python 2.7 must die bollocks is, frankly, getting pretty infuriating.

----------

## alamahant

There are some overlays

https://gpo.zugaina.org/net-analyzer/zenmap

 :Very Happy: 

----------

## Ant P.

Oh. Looks like I need to --sync....

----------

## Anon-E-moose

If you want zenmap back then modify the ebuild to add it back OR if you already have it installed with the zenmap option, then copy the ebuild from /var/db/pkg/net-analyzer/nmap/nmap*ebuild to your local repo.

----------

## Hu

 *steve_v wrote:*   

> This python 2.7 must die bollocks is, frankly, getting pretty infuriating.

 Indeed.  The deprecation came out of nowhere, and no one had time to prepare for this by updating their code to work with a newer supported Python.  If only there had been more time before Python 2.7 was declared end-of-life upstream...  :Smile: 

----------

## steve_v

 *Hu wrote:*   

>  *steve_v wrote:*   This python 2.7 must die bollocks is, frankly, getting pretty infuriating. Indeed.  The deprecation came out of nowhere, and no one had time to prepare for this by updating their code to work with a newer supported Python.  If only there had been more time before Python 2.7 was declared end-of-life upstream... 

 

As I am sure you are aware, the problem in this case is not python 2.7 per-se, it's the decision to eradicate pygtk and everything depending on it.

"X is old and unmaintained upstream" does not address the fact that there are many useful and functionally bug-free applications still using it. Particularly when several of those do not have alternatives.

There is an old adage which springs to mind here, one regarding the fixing of things which are not broken. This particular fix involves removing several applications that are still in common use, as far as I can see primarily in the name of housekeeping. What pressing real-world problem does banishing pygtk solve exactly, besides a tidier portage tree?

Procmail has been unmaintained upstream since 2001, it still works fine (and I still use it), and there's no mention of dropping it because it "no longer receives fixes". Why should pygtk be any different?

What's next, dropping GIMP as well? It uses pygtk... Forcing us to use the dog-slow and incomplete GTK3 port perhaps?

----------

## Hu

The problem is not Python 2.7 itself.  The problem is that many upstream projects took the EOL of Python 2.7 as a signal to begin removing their Python 2.7 compatibility code, such that all future releases of the relevant projects can only be run under Python 3.x.  If one of those projects needs to continue receiving updates in Gentoo, and no longer works under Python 2.7, then the Gentoo maintainers must choose between not updating it or removing its python_targets_python2_7 flag.  If they choose the latter, then every package that consumes the now-3.x-only package must itself lose 2.7 support.  For some packages, that means they are left with no supported Python targets, and must be removed outright.  That is why pygtk is different.  Its direct dependencies include dev-python/pycairo dev-python/pygobject dev-python/numpy.  Gentoo is already performing odd packaging tricks due to numpy removing 2.7 support, and that was only done because numpy was so widely used that directly dropping its 2.7 support would be a major logistical problem.

As noted in the news item reminding users of Python 2.7 EOL, Gentoo does not have the resources to maintain Python 2.7 support across all the packages that are now removing it.  If you want Python 2.7-only packages to stick around, convince the actively maintained Python packages to stop removing Python 2.7 support, so that the unmaintained ones can continue to rely on it.

----------

## Ionen

May want to keep an eye on the upstream issue (it's old but had some recent activity), this may get ported to python3 eventually and then zenmap USE could be re-added here.

Then again, as mentioned in it, porting away from pygtk is more of an issue than porting away from python2.7 itself.. so ndiff (which also need 2.7) may have more luck than zenmap.

----------

## asturm

 *steve_v wrote:*   

> What's next, dropping GIMP as well? It uses pygtk... Forcing us to use the dog-slow and incomplete GTK3 port perhaps?

 

30 days after GIMP receives a GTK3 based *release* it will be stabilised as far as bugs permit, then old versions will be wiped. And no amount of shouting from the sidelines is going to change that.

----------

## Ionen

gimp2's python+pygtk dependency is optional anyway, so if wanted to do away with it then would only remove/mask its python USE.

It was actually removed for a few days once (in ~testing, recall stable users never seen this), but complaints managed to bring it back. If gimp3 wasn't on the horizon it probably wouldn't have been reverted though.

Edit: After it releases, personally I'd see no "big" harm in keeping gimp2 around for as long as it gets upstream stability updates, just with USE=python removed again. I imagine users may need a while to migrate their workflow plus various tools that may not work with 3 yet (but personally awaiting removing gtk2 from my system so I'll migrate as soon as it releases  :Smile:  I even patched nvidia-drivers[tools] so it stops depending on it. Given don't need python with gimp, already removed pygtk long ago though)

----------

