# Fyi, four languages without a maintainer/port



## Alain De Vos (Aug 28, 2022)

There are 4 languages without a maintainer/port
1.wren
2.haxe
3.janet
4.squirrel
[What these languages are good for is another issue]


----------



## Phishfry (Aug 28, 2022)

Alain De Vos said:


> without a maintainer/port


Tag you are it. Consider it a field promotion.


----------



## getopt (Aug 28, 2022)

Don't we have enough ports in the tree without a dedicated maintainer?


----------



## Phishfry (Aug 28, 2022)

Do they pose a security risk is a worthy question.
Otherwise let them rot on vine?

A link to the ports would have been nice.
lang/wren
lang/haxe  <<< Is not a FreeBSD port
lang/janet
lang/squirrel




Alain De Vos said:


> Then there is also the "haxe" language and "kit" language.
> I wonder which language will survive ...


----------



## hbsd (Aug 28, 2022)

Phishfry said:


> Is not a FreeBSD port


Also this:


Phishfry said:


> lang/wren


----------



## zirias@ (Aug 28, 2022)

getopt said:


> Don't we have enough ports in the tree without a dedicated maintainer?


A whole lot. It's not pretty. I personally only want to maintain ports I'm using myself, it makes things a lot easier... ideally, we would find a maintainer for each and every port, except for those nobody ever uses


----------



## drhowarddrfine (Aug 28, 2022)

zirias@ said:


> ideally, we would find a maintainer for each and every port, except for those nobody ever uses



Such as the four listed above. 

Actually it gives fodder to those who like to diss FreeBSD.

I have heard of haxe before, though


----------



## Alain De Vos (Sep 1, 2022)

The language "gravity" is in the ports. No idea what it's good for. So many languages so little time.


----------



## bakul (Sep 1, 2022)

What is needed is a program that watches the original source sites for various ports and when there are updated sources, it tries to update a port using the existing port and stashes results in somewhere. Such changes often quite trivial so it makes sense to automate at least the grunge work. Over time it can be taught more tricks.


----------



## sidetone (Sep 1, 2022)

bakul said:


> What is needed is a program that watches the original source sites for various ports and when there are updated sources, it tries to update a port using the existing port and stashes results in somewhere. Such changes often quite trivial so it makes sense to automate at least the grunge work.


There's a few things that don't get updated, because they're forgotten about. We don't notice it until someone looks into it, and before that, it was assumed it's the latest and greatest in the Portstree.


Another one, would be an upgrade of the Portstree framework, where lld(1) is used to determine which library files are called on, and there's a list of dependencies in and which FreeBSD ports have those library files. So, that it can also be overridden or a particular version can be set. There's somewhat of one, but it's not automatic in such a way and it's basic.

Maybe also, other features, which aren't part of the Portstree framework, but are commonly ran on it less often than packages are built, or suggested for use to be ran on the portstree, such as checking headers and debugging tools, such as devel/deheader, devel/valgrind or devel/include-what-you-use. This may help BSDify software, to get rid of header includes in sourcecode which were left in, but the previous code that has once called on those headers has been otherwise cleaned up. Improvements that those bring about can be suggested for upstream from here, or if they don't want to do that, it can be forked.


----------



## zirias@ (Sep 2, 2022)

bakul said:


> What is needed is a program that watches the original source sites for various ports and when there are updated sources, it tries to update a port using the existing port and stashes results in somewhere.


The first part exists, it's called portscout. Updates are mailed to the maintainers (or to the ports mailing list for ports that don't have a maintainer).

The second part isn't worth the effort, I don't have statistics, but in my personal experience, the majority of port upgrades aren't "trivial" (only change the version variable an regenerate distinfo). And even those that are must be tested anyways.


----------



## Lamia (Sep 2, 2022)

zirias@ said:


> The first part exists, it's called portscout. Updates are mailed to the maintainers (or to the ports mailing list for ports that don't have a maintainer).


Nodding! 

I had a look at Haxe now. This thread is referenced in one of the issues. Porting it to FreeBSD may intend be easy going by this guide.


----------



## jbo (Sep 2, 2022)

Alain De Vos said:


> There are 4 languages without a maintainer/port
> 1.wren
> 2.haxe
> 3.janet
> ...


Alain De Vos No offsense - this is a serious question: Could you explain what your intention behind a post like this is?


----------



## Alain De Vos (Sep 2, 2022)

It was just something that came into my mind. But hey it opens other ideas.


----------



## SirDice (Sep 2, 2022)

I'll save you the trouble of reporting 'unmaintained' ports: Thread adopt-an-orphaned-port-project.36243


```
root@fbsd-test:~ # pkg rquery -e "%m == 'ports@FreeBSD.org'" %o | wc -l
    3611
```


----------



## SirDice (Sep 2, 2022)

The above count is for 'quarterly', this is based on 'latest':

```
root@fbsd-test:~ # pkg rquery -e "%m == 'ports@FreeBSD.org'" %o | wc -l
    3572
```


----------



## Alain De Vos (Sep 2, 2022)

Jokings aside games/xlennart is unmaintained.
Now to be honest the porters-handbook is above my head.
Maybe i just lack the necessary skills.
Or i have a reading problem.
Or i do not put enough effort.
But if you could improve the readability of the porters-handbook, as to explenation of the freebsd tooling, ie decrease the learning curve, maybe there would be more maintainers, no ? Or am i wrong?


----------



## zirias@ (Sep 2, 2022)

In my experience, the porters handbook is perfectly readable, IMHO an example for good documentation.

It _does_ presume some experience with building software and all the build systems around (especially classic `make` of course). This is always necessary for any packaging work, no matter for which OS. But you can get that experience by just starting to work on ports...


----------



## Lamia (Sep 2, 2022)

SirDice said:


> I'll save you the trouble of reporting 'unmaintained' ports: Thread adopt-an-orphaned-port-project.36243
> 
> 
> ```
> ...


Another valuable pointer; thanks SirDice. 

Adopting or creating a port is a different experience. It feels like those days I built an extension on Firefox. Then the next, next and I can go on and on.

My first port was committed two days ago (don't ask me its name yet). Two other (dependent) ports are being reviewed and should be committed in days. And the most difficult one is being thought of now. Some monies may be committed to it.


----------



## Alain De Vos (Sep 2, 2022)

I don't want to nag, but sometimes i want to build a freebsd-port, ie. some github clone with some of my own patches for myself alone to work on my own pc.  This is  a first step in 'growing'.
As i use poudriere as building system i have even problems with this.


----------



## getopt (Sep 2, 2022)

jbodenmann said:


> Alain De Vos No offsense - this is a serious question: *Could you explain what your intention behind a post like this is?*


and a poor answer:



Alain De Vos said:


> It was *just something* that came into my mind.


Do we really deserve it to spend our time on such threads?

Alain De Vos you wrote this under name "devosalain":








						Does it works on FreeBSD ? · Issue #10785 · HaxeFoundation/haxe
					

I could not find a freebsd package.




					github.com
				




What were your intentions there? What did you make out of the answer you got there?


----------



## Alain De Vos (Sep 2, 2022)

Do we really deserve it to spend our time on such threads?
Was this a question ?
[Note this post was first under Off-topic but it got moved ]

What did you make out of the answer you got there?
Offcourse i tried it but failed.


----------



## getopt (Sep 2, 2022)

Alain De Vos said:


> Offcourse i tried it but failed.


How did you try and how did you fail? Did I miss reading about it somewhere?


----------



## Lamia (Sep 2, 2022)

Thanks to several people in the thread and forum for their guidance. I can't name them all.


----------



## sidetone (Sep 2, 2022)

To find unmaintained ports, I do `psearch -m ports@freebsd.org`. There could be something I'm missing, but that's most of it AFAIK.


----------



## getopt (Sep 2, 2022)

sidetone said:


> I do `psearch -m ports@freebsd.org`. There could be something I'm missing, ...


You do not miss anything. ports-mgmt/psearch is using /usr/ports/INDEX-13 and therefore is fast.


----------



## mer (Sep 2, 2022)

So the title of the post is specifically about 4 languages that are unmaintained, but the thread has morphed into
"unmaintained ports".
I think is a general statement on "third party software".
Someone creates something you need like a window manager.  You start using it, it evolves eventually the creator stops "creating/maintaining it" because of time or interest.  What do you do because you use it?
I don't know the answer.  I think something that gets to "how many people actually use a given port" vs "is it maintained" is really needed.  A port without a maintainer that noone uses means nothing.  A port without a maintainer that 1K people use, needs a maintainer.

I know some of the WindowMaker apps I use report "no maintainer" and I'm not willing to step up, so I'm accepting that "at some point in the future they may disappear".

Yes, I know "mer blah blah blah blah"


----------



## zirias@ (Sep 2, 2022)

Lamia said:


> Thanks to several people in the thread and forum for their guidance. I can't name them all.


I'm one of those who happen to know what you're working on. I will of course respect your wish to not make it public unless it's fully done! What I can say is: this will be a pretty valuable addition to our ports tree, at least for (some!) desktop users.

You are one of those with little experience with make and other build systems, with packaging practices in general. And admittedly, this makes it a lot harder to start working on ports. But you also showed your willingness to learn and take advice, and this is the attitude it takes! I'm pretty sure you will make a great maintainer for your new ports. And rest assured, the more experienced crowd is always very willing to *give* advice and guide new ppl. So, I'll just take this opportunity to say in response:

Thank *you* for starting to work on FreeBSD ports! 

And mer, sure, this went off-topic. But I still don't really get the point of just naming a few eso-langs. There are lots of unmaintained FreeBSD ports. This is a great opportunity to remind everyone that FreeBSD (src, ports and doc) is a community project, and everyone's input is more than welcome! And also: everyone can learn to contribute, it's no rocket science


----------



## Alain De Vos (Sep 2, 2022)

There are other github clones i use:
-dub (in ports but old)








						GitHub - dlang/dub: Package and build management system for D
					

Package and build management system for D. Contribute to dlang/dub development by creating an account on GitHub.




					github.com
				



-glrnvim








						GitHub - beeender/glrnvim: glrnvim wraps nvim with your favourite terminal into a standalone, non-fancy but daily-usable neovim GUI.
					

glrnvim wraps nvim with your favourite terminal into a standalone, non-fancy but daily-usable neovim GUI. - GitHub - beeender/glrnvim: glrnvim wraps nvim with your favourite terminal into a standal...




					github.com
				



-gnvim








						GitHub - vhakulinen/gnvim: GUI for neovim, without any web bloat
					

GUI for neovim, without any web bloat. Contribute to vhakulinen/gnvim development by creating an account on GitHub.




					github.com
				



-sfwbar








						GitHub - LBCrion/sfwbar: Sway Floating Window Bar
					

Sway Floating Window Bar. Contribute to LBCrion/sfwbar development by creating an account on GitHub.




					github.com
				



-ping_exporter








						GitHub - czerwonk/ping_exporter: Prometheus exporter for ICMP echo requests using https://github.com/digineo/go-ping
					

Prometheus exporter for ICMP echo requests using https://github.com/digineo/go-ping - GitHub - czerwonk/ping_exporter: Prometheus exporter for ICMP echo requests using https://github.com/digineo/go...




					github.com
				



-cups_exporter








						GitHub - phin1x/cups_exporter: Prometheus exporter for CUPS server
					

Prometheus exporter for CUPS server. Contribute to phin1x/cups_exporter development by creating an account on GitHub.




					github.com
				



-postgres_exporter








						GitHub - prometheus-community/postgres_exporter: A PostgreSQL metric exporter for Prometheus
					

A PostgreSQL metric exporter for Prometheus. Contribute to prometheus-community/postgres_exporter development by creating an account on GitHub.




					github.com
				




In theory making a port for each of them should be strait forward.


----------



## bakul (Sep 3, 2022)

zirias@ said:


> The second part isn't worth the effort, I don't have statistics, but in my personal experience, the majority of port upgrades aren't "trivial" (only change the version variable an regenerate distinfo). And even those that are must be tested anyways.


They may not be regular enough to automate (easily) but at least the few I have tried have been relatively easy to fix. May be a better option may be to create a port helper program that automates as much of the repetitive work as possible. I play with this idea some and see if I can come up with something useful.

Testing seems to be completely port specific - some of them don't even have any tests.

portscout already does the first part so no need to repeat that work.


----------



## Chad Jacob Milios (Sep 9, 2022)

Alain De Vos said:


> Jokings aside games/xlennart is unmaintained.


That port is current with the latest distribution minor point release. The underlying software is unmaintained/defunct. This is a different situation entirely.

Tell us if you've experienced any problems with the current port running on a 13.1 or 12.3 release of FreeBSD, including the display manager you've chosen to use it with and perhaps briefly the combination of hardware used which may have a pertinent influence on your issue.

As the game is very old, arguably lame, a momentary satirical whimsy of its author, a knock off of a game over a quarter of a century old fitting the same description, ultimately just a gross triviality, please don't be surprised if no one responds or cares. I mean that in the most compassionate way.

On the other hand, XBill is an important part of open source history and heritage, in an ideal world its compatibility and function should be maintained, so to bring XLennart along with such efforts should not take much additional effort.

We are more concerned with FreeBSD ports which fall behind their active software projects' iterating versions, items 3 and 4 of your original post, or useful/popular open source software lacking a FreeBSD port altogether, a class that items 1 and 2 may fit. In either case while it is not ideal it is no catastrophe, as the Porter's Handbook is well written, the Portstree [and Framework] relatively well engineered and quite actively maintained, and individual members of our community often write or update many a port though Bugzilla without taking on the responsibility or obligation to become maintainer of a port to which they contribute.

I wonder if poorly managed ports aren't more detrimental than unmaintained ports. I for one feel I am guilty of lackluster maintenance of ports upon which my claim may possibly thwart or discourage others' adoption or collective maintenance, while I imagine one potentially who waits for my action, as I am prone to suffer arbitrary or sudden bouts of incarceration and all other sorts of work/life balance mismanagement. At any rate, I'm back on my task, at least for the time being, and I have always felt supported and assured by this amazing community.

I hope that instead of feeling pressured to either accept liability and obligation to _maintain_ a port, lest in frustration you otherwise leave us in defeat for potentially a more trendy [yet fleeting] open source distro of likely less well thought out architecture and engineering, rather you'd please feel our encouragement to *try* and simply _contribute_ to these ports. When one exhibits the courage to try publicly and yet fail miserably, orders of magnitude more attention and support will mobilize to their aid from the community.

I am living proof that one can make a successful career, maybe a legacy even, of pathetic failure _with_ public embarrassment as angels among us have lifted me to higher levels of productivity, greater freedom and responsibility, than I ever dreamed possible of attaining for myself, in such a manner I could not find among any other software development community on Earth. However you will not find a post or email of mine going back decades in which I stood apart to point out flaws with an aloof or dismissive delivery, nor made suggestions while trivializing the effort required, nor threw my arms up at an early stage of despair to ask for help in a defeated tone. (Not saying that's exactly what you've done but yet it may describe something close to how you're being perceived.)

If you will please tell us your overall *objective(s)*, not merely your narrow problem(s), then, no matter how trivial or meaningless it seems to be, I will certainly do my very best to help you (provided it shows that you've sought your own way somewhat deep into either the Porter's Handbook and/or a third-party project's README, with a certain level of perseverance only to find yourself well past your comfort zone). And so when, try as I might, _I too_ fail miserably to help you, as _I myself_ am woefully inept, *then*, I'm willing to bet upon it, a band of these heroes mightier than us shall materialize out of the woodwork as they or their ilk always have before, for a grateful me, in every single instance of my desperate need.


----------



## Alain De Vos (Sep 20, 2022)

A simple one, without maintainer,








						GitHub - stetre/moonfltk: Lua bindings for FLTK
					

Lua bindings for FLTK. Contribute to stetre/moonfltk development by creating an account on GitHub.




					github.com


----------



## sidetone (Sep 22, 2022)

bakul said:


> What is needed is a program that watches the original source sites for various ports and when there are updated sources, it tries to update a port using the existing port and stashes results in somewhere. Such changes often quite trivial so it makes sense to automate at least the grunge work.


Another way in which identifying when the last update to a port or different compared to a sourcetree would be helpful, even considering that it can't always automatically be done due to the need for testing is, it lets others including those who are coming to FreeBSD know which ports are not obsolete compared to sources. It will be a reference so they know what's newer, and will bring action and new users. It will make it easier on prospective users, and let them know, rather than them coming in having to investigate for a long time, then decide it doesn't have what they want and leave. This way, they can look at it before coming, then ask about that, and it would be quicker for them to decide or for an updated port to get implemented, then they come in. It will also let regular users know where the version they're using sits at. Otherwise, it takes investigation and deep diving by regular users, and for something they've been interested all along, it may take a long time to stumble upon years later.

Recent examples are Samba versions, Xaw3d, and Blender derivatives. Blender was actually very much up to date, and well put together, at the time it was heavily inquired about, but months before that, it may not have been. Either way, if Blender or a Blender derivative didn't have experimental features, they could see that, then go elsewhere or look into that.

It would be something like how checking a hardware list to see if a particular hardware works with FreeBSD, except for software availability and software versions.


----------



## bakul (Sep 23, 2022)

sidetone said:


> Another way in which identifying when the last update to a port or different compared to a sourcetree would be helpful, even considering that it can't always automatically be done due to the need for testing is, it lets others including those who are coming to FreeBSD know which ports are not obsolete compared to sources.


That information is already available via https://portscout.freebsd.org/ -- you have to click on the name of a maintainer to see the ports that need updating.

Or do you want something more?


----------



## sidetone (Sep 23, 2022)

It's lacking a bit. It shows when it was last updated, and assumes, because that was in the last few months, it doesn't take into account when upstream of a port changes the source location which often happens when it changes hands. Also, locations of the previous download source could be the one that wasn't an official mirror that goes stagnant, while the upstream got upgraded elsewhere, and sometimes the name changes. This may require manual intervention though.

There was one, but it needed testing for them to upgrade that. For example, Xaw3d which later became libXaw3d at a different upstream location as has it changed hands. That needs to be included there. However, that one could simply be dropped for libXaw3dxft, while this has an opportunity to become the default.

Also, that one needs to be searched by the maintainer, and then by the port. Which, it refers to FreshPorts, and Freshports doesn't have that function.

Also, Portscout has a function on the mailing lists. It would be something like that, but a bit more.


----------

