# Adopt an orphaned port project



## lme@ (Dec 10, 2012)

Since the ports tree is now open again, let's start the "Adopt an orphaned port" project.

*What is it?*

According to http://freshports.org/ we currently have 23,940 ports in our tree, that's really great! But: There are 4,751 unmaintained ports (approx. 20%), that need your love.

*What can I do?*

Adopt one or more ports!

You think it's a lot of work? That's not necessarily the case, the ports are already there and just need someone to track the latest upstream versions and someone who keeps the port in a good shape.

*How do I know which ports are unmaintained?*

That's pretty easy: If you want a list of all unmaintained ports, run
`# nawk -F"|" '$6 == "ports@FreeBSD.org" {print $2}' /usr/ports/INDEX-`uname -r | cut -d'.' -f1``

If you want to see which of your installed ports are unmaintained run

for PKGNG:
`# pkg query -e "%m == 'ports@FreeBSD.org'" %o`
for pkg_*:

```
#!/bin/sh

INDEX="/usr/ports/INDEX-$(uname -r | cut -d'.' -f1)"
MAINTAINER="ports@FreeBSD.org"

grep -h ORIGIN /var/db/pkg/*/+CONTENTS | cut -d: -f2 |
  nawk -v INDEX="$INDEX"  -v MAINTAINER="$MAINTAINER" \
    '{ installed_ports[$0] = 1 }
    END {
    	FS="|"
    	while (getline < INDEX) {
    		if ($6 == MAINTAINER) {
    	   		sub(/\/usr\/ports\//, "", $2)
    			unmaintained_ports[$2] = 1 
    		};
    	}
    		for (port in installed_ports) {
    			if (unmaintained_ports[port]) {
    				print port
    			}
    	}
    }' | sort
```


*What can I do then?*


Pick a port.
Take a look at the port's Makefile and pkg-descr.
See if a new version is available upstream.
Check if the WWW line in pkg-descr still points to a valid site.
Check for broken distfile mirrors, take a look at http://people.freebsd.org/~ehaupt/distilator/ports@FreeBSD.org-bad.html.
Find other mirrors, or mirror the distfiles yourself.
Remove the dead mirrors from the port's Makefile.
Try to update the port to the new version.
Add yourself as MAINTAINER in the Makefile.

If the updated port works, create a patchfile and send a problem report (PR) with send-pr(1) or via the web interface http://www.freebsd.org/send-pr.html.
All you need then is some patience until some committer grabs the PR and eventually commits it or asks you to re-work the patch, if there are some issues left.

*I'd really like to do that, but how do I actually do it?*

There's very good documentation for porters, the Porter's Handbook: http://www.freebsd.org/doc/en/books/porters-handbook/. Don't worry. It's called a book, but it's not a very thick book. Even so it explains porting very good. While it's recommended to read the whole book you can also pick the chapters first that you need to update the port. If you still have problems or questions then, there are many helpful people at the ports@FreeBSD.org mailing list.

*What benefits do I have?*

Actually there a several benefits:

You give something back to the community. That's the idea of open source.
You earn experience with Makefiles, diff(1), patch(1) and other useful tools.
You and everyone benefits from updated ports.
Your name gets added to the list of FreeBSD Contributors: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/index.html.
If you create enough PRs and maintain a bunch of ports, it's quite possible that you get punished with a ports commit bit! \o/


----------



## fonz (Dec 10, 2012)

Good initiative. I'm certainly going to have a look.

Fonz


----------



## gkontos (Dec 10, 2012)

Excellent me too wherever I can help.


----------



## vand777 (Dec 10, 2012)

Will have a look as well!


----------



## cpm@ (Dec 10, 2012)

@lme@

Thanks for your announcement. 

Good sticky!


----------



## jackp (Dec 11, 2012)

I've had my eye on a couple of neglected ports -- when things at work wind down for the holidays, I'll have a go at updating them.


----------



## gnumonk (Apr 18, 2013)

Thanks for sharing this info, I have seen some of them which I used daily using git, but I see those are poiting to old link or dead link. I will probably take those.

But I have a question, since most of the projects were moved to git, how to versioning them, I mean what will be on PORTVERSION?

--
gnumonk


----------



## TheDreamer (Jul 5, 2013)

What if the port has a MAINTAINER, but they seem to have vanished?

There's a port, which requires frequent updates. But hadn't been updated in years. The last PR where the maintainer responded was in August 2010, where he submitted a patch that updated it from 0.57 to 0.59.

None of the ports of this nature worked when I tried them, but I found that this port's upstream had an active community maintaining it. Though there appears to be a gap in activity from November 2010 to August 2012. So, I found the latest revision and got it working. I submitted a PR to update it to version 2.7, where I with with provide the distfiles since the current versions involve reading a discussion thread and checkout the specified CVS revision on Sourceforge. After about six weeks it was committed with maintainer-timeout.

Later the port stopped working, a 3.0 .tgz had been released during the time, but I needed to actually get revision 2.29 from CVS (v3.0.3) for things to work again. So, I submitted another PR, this one has been waiting for maintainer feedback for over two months now.  

Meanwhile, I've had to update again. But, how should I submit or why? Feel I might also be the only person on FreeBSD using this port.

The Dreamer.


----------



## kpa (Jul 5, 2013)

Which port is it? Ask on the freebsd-ports mailing list and request that the maintainer of the port is reset to ports@freebsd.org which means that the port does not have a maintainer. Or if you feel that you could do the maintainer's work yourself volunteer as the maintainer


----------



## wblock@ (Jul 5, 2013)

See the Porter's Handbook about a maintainer timeout.


----------



## kpa (Oct 31, 2013)

I bit the bullet:

http://www.freebsd.org/cgi/query-pr.cgi?pr=183497


----------



## trh411 (Oct 31, 2013)

Maybe it's just me, but I would like to know that a reasonable number of people are using (or at least have installed) a port before committing to maintain it. Priority should be given to maintain those ports most frequently installed/used, but are orphaned WRT being maintained, no?

Is this information available somewhere?


----------



## lme@ (Oct 31, 2013)

kpa said:
			
		

> I bit the bullet:
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=183497



And it's already committed, thanks and congratulations.


----------



## crashcoredump2 (Oct 18, 2014)

Is this still a thing?


----------



## fonz (Oct 18, 2014)

The being mentioned as a contributor thing never happened, but otherwise:

```
# find /usr/ports -name Makefile -exec grep MAINTAINER {} \; | grep -i ports@FreeBSD.org | wc -l
  4279
```
There are still over 4,000 unmaintained ports so if you feel like "adopting" one (or a few) of them, then you are by all means welcome.


----------



## lme@ (Oct 19, 2014)

I'll happily add everyone to the contributor list who maintains a port.


----------



## TheDreamer (Nov 10, 2014)

A while back, I had intended to adopt the orphaned ports that I was using that were facing deletion due to not STAGING, but I got busy and didn't get down to working on them (part of it was working through some issues in getting poudriere working.)

But, the port is now gone, and I'll probably just go find an alternative when the occasion to want to use something like it comes along.

Though back when I last posted, I had kind-of adopted one. It wasn't a true orphan, since it just had an absent maintainer. First time I updated it, it was eventually accepted on timeout. Second time I updated it, it timed out but never got acted on. While I was waiting for that to time out, there was a third update. And, after both had timed out, it was in need of another update,  except it felt like I was the only person trying to develop the update upstream (given how Mircosoft does rolling updates, not everybody is impacted by a change they make). There were other contributors to the bug report, and I wasn't the original submitter, but evidently the only one willing to dig into the source and try things. All along, the author reported that the issue didn't affect him yet, but later he declared it dead and that he's off to work on its successor, but nothing released yet.

I forget if the request to have it marked BROKEN or removed has timed out yet, and if it has happened. I guess it did. It doesn't say how long with 'maintainer timeout' before the first update got in, but the second update says '9 months', while for the final update as BROKEN the timeout was 'four weeks'. A little while later, portmgr@ changed it to use USES, and then a couple of days later it expired and was deleted.

To be a powerful being like portmgr@ must be fun, since ports will suddenly change behavior with no need to say anything. I'm currently dealing with a port that did what it's described to do. But, portmgr@ has updated it with just a comment of 'cleanup plist',  except that he also updated the port to the latest version and changed it so it no longer does what it's supposed to do nor provide a knob to control this unexplained change to the port.

Though ideally, there should be a different way entirely for the port to exist in its intended form without the kind of hops I'm going through to use it that way now.  (I'm thinking it should be like how all the sendmail-* slave ports got pulled into the master, so that other ports that depend on it don't keep trying to install the master on top of one of the slave ports, except that it's not a master/slave port problem.)

Meanwhile, I had intended this four-day weekend (due to taking Monday off before tomorrow's holiday) to clean up and submit a bunch of patches I needed to get various ports to build in poudriere, and perhaps see if some of the patches for a port I was updating are still applicable (because 'poudriere testport' catches the errors, where other methods don't) since the maintainer has reappeared and jumped it over the update I was working on. (Most of the errors are associated with enabling an option that isn't set by default, and some as simple as missing a @dir or two.)  Except that somewhere overnight my system died and one zpool didn't make it (the one that includes /home and /poudriere), I'm watching to see if `zdb -e -bcsvL` will recover it (current ETR is 2974+ hours.)

I never did get around to building a second FreeBSD server so that they could back each other up; the latest delay is that some of the drives for that build got used to replace drives that failed last summer in my main system. If I get things back up and running, think I should see about moving more essential services from this machine over to my two headless (SFF) servers. Some of them might make a good candidate to go on my tiny HAST volume, now that I got CARP stablized. ipfilter was getting in the way, someday I'll get around to pf conversion.

ipfilter because that's what we use at work on Solaris and the same files worked on FreeBSD when we had a few pop up in production and in our CFEngine system.  (Or I use, since Solaris and FreeBSD are dying breeds at work, and I'm the only one that hasn't quit or been reassigned.) Plus, the federal agency SLA customer that finally allowed FreeBSD into production use here is leaving us this month. We're going with mainly Ubuntu, with some RHEL for Oracle. We never got all our CFE policies to support Ubuntu, since FreeBSD took priority and most of that work was turned into that.  At the time, there was no official reason to support Ubuntu; there was almost a ban on it, because one group kept asking for it. As for my home CFE, I'm not sure why I'm dragging on having it manage my Ubuntu systems.

ETR is 2996+ now, 3019+ now, I probably should go find something else to do with the rest of my staycation instead.

The Dreamer


----------



## crashcoredump2 (Nov 13, 2014)

lme@ said:


> I'll happily add everyone to the contributor list who maintains a port.



Well, I'm not really looking to be added anywhere, but I'll happily pick up a port or two.


----------



## crashcoredump2 (Nov 13, 2014)

fonz said:


> The being mentioned as a contributor thing never happened,



That's the last thing I would worry about.



> There are still over 4,000 unmaintained ports so if you feel like "adopting" one (or a few) of them, then you are by all means welcome.



Great. I will pick something up then.


----------



## wblock@ (Nov 13, 2014)

Maintainers should all be on the contributor list.  I don't know if the ports group would want missing contributors entered as PRs, but it's worth contacting them, maybe on the freebsd-ports mailing list.


----------



## zirias@ (Nov 24, 2014)

I just discovered that devel/cc65 is unmaintained. I'm using its assembler and linker for cross-development to the C64. The version in ports is so old, it doesn't parse my linker configuration in a little C64 demo project correctly and my build fails. So I'd be quite interested in adopting this one.

The problem is: the upstream maintainer changed meanwhile and the project structure changed a lot. I'd probably have to rewrite the port from scratch. Okay, I'd give it a try, but there is another catch: the new maintainer doesn't do releases. There is just a GitHub repository. How would I ensure production quality taking the code from there? How would I create a meaningful version number? Would this even be accepted for the ports tree?


----------



## wblock@ (Nov 24, 2014)

There are some notes on GitHub use in the Porter's Handbook: https://www.freebsd.org/doc/en_US.I...e-distfiles.html#makefile-master_sites-github.  It is possible to make a port for a project that does not have releases.  Whether it will be accepted in ports probably depends on the project.


----------



## zirias@ (Nov 24, 2014)

Thanks for your reply. I already knew the technical aspects, because I created a port for my own GitHub project (mkd64), just to get used to it (and for a clean install).

That said, I could create a port for the new cc65 just for my personal use, but I'd prefer to share this effort. So, previously there were a versioning scheme and releases -- I guess the correct way now would be to set 
	
	



```
PORTEPOCH=1
```
 and derive the version number from the date of the Git commit I'm using as upstream?


----------



## wblock@ (Nov 24, 2014)

I did it once or twice but selective amnesia has hidden the horrible details from me.


----------



## zirias@ (Nov 24, 2014)

Okay then, I'm just giving it a try: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195350 -- we will see


----------



## morbit (Aug 16, 2016)

fonz said:


> The being mentioned as a contributor thing never happened



True, it's out of sync for a long time, yet if it has to be maintained by hand...


----------



## Sevendogs (Dec 18, 2016)

I am interested in adopting an unmaintained port but I have a question. I have read through the instructions but the port graphics/gpicview is at the latest upstream version, and the other attributes in the instructions pertaining to the port seem to be current. The only thing I can determine is that the author appears to be the same or in the same group that wrote LXDE and related ports, all of which appear to be unmaintained. What should I do at this point? Is this simply a matter of updating the maintainer to me and submitting a PR? Is there a bigger issue with the LXDE port and all of the related ports?

Forgive me is this question is a bit noobish: maintaining ports is not a development effort is it? I mean it does not involve coding on the port in question, other than modifying the Makefile or pkg-descr or other related files, correct? I see port maintenance as more of a configuration management function but wanted to ask. I was a developer for a little over 10 years but have gotten out of it and do not wish to get back into coding. Thanks in advance.


----------



## morbit (Dec 18, 2016)

If you are a port maintainer, you are expected to make everything to make this port work flawlessly. If there is no longer upstream/the upstream is not cooperating that might involve patches to the code itself. Usually (for simpler ports) it does not though. Still, look for them in port directory under `files/`. Most often it's just configuration stuff, as you've said [1].

If you know the ports framework you will do just fine. See Porter's Handbook too https://www.freebsd.org/doc/en/books/porters-handbook/.

[1] Though have a look at /usr/ports/graphics/gpicview/files/patch-main-win.c. That kind of things are needed sometimes too.


----------



## Phishfry (Dec 18, 2016)

Sevendogs said:


> Is there a bigger issue with the LXDE port and all of the related ports?


I believe LXDE is dead. The developers moved to a QT version.
Even if its not dead there is enough doubt to cause mayhem. Too bad as I liked thier spin on openbox.
https://sourceforge.net/p/lxde/mailman/message/35240277/
http://iwf1.com/lxde-not-dead-says-one-developers-actually-actively-developed/


----------



## Sevendogs (Dec 18, 2016)

Thanks for the reply morbit - I still need to read the porter's handbook but I was just interested in helping. I am not comfortable coding anymore so not sure I should jump in, plus I have never coded in C or C++ so have no experience there other than general code reading skills. I may just see if I can help out with documentation or something else. I like giving back to the community: I have been using open source for nearly 20 years and have worked as a tester and support staff for Linux during that time so would like to help FreeBSD in some capacity.


----------



## Sevendogs (Dec 18, 2016)

Phishfry said:


> I believe LXDE is dead. The developers moved to a QT version.
> Even if its not dead there is enough doubt to cause mayhem. Too bad as I liked thier spin on openbox.
> https://sourceforge.net/p/lxde/mailman/message/35240277/
> http://iwf1.com/lxde-not-dead-says-one-developers-actually-actively-developed/



I had feared that, not because of the DE itself but I really like graphics/gpicview as a quick little viewer because you can arrow through every graphic in a directory, plus you have to just hit "esc" to exit the app. Very keyboard friendly and easy to use. I can use graphics/feh but a script is needed for it to have the same functionality. Thanks for the information, appreciate it.


----------



## kpa (Dec 18, 2016)

Sevendogs said:


> Forgive me is this question is a bit noobish: maintaining ports is not a development effort is it? I mean it does not involve coding on the port in question, other than modifying the Makefile or pkg-descr or other related files, correct? I see port maintenance as more of a configuration management function but wanted to ask. I was a developer for a little over 10 years but have gotten out of it and do not wish to get back into coding. Thanks in advance.



It can vary wildly depending on what condition the upstream source is in terms of portability and assessing the portability for a completely new piece of software can be a real challenge. You can get a very good picture of how much FreeBSD local patching a port requires by looking at the files subdirectory of a port, everything named as patch-* is automatically applied to extracted pristine source.

Being a FreeBSD port maintainer can be almost like an unpaid full time job in some cases so be careful not to bite more than you can chew at first.


----------



## Sevendogs (Dec 18, 2016)

Thanks much for the advice kpa, appreciate it! I would like to contribute but already work close to 50 hours a week at my normal job so I'll see what the best way is for me to contribute.


----------



## Phishfry (Dec 18, 2016)

Sevendogs
I wanted to throw graphics/mirage out there as a good GTK based image viewer. It uses the arrow keys for image browsing as well.


----------



## Sevendogs (Dec 19, 2016)

Great Phishfry, thanks for the tip, will check it out.


----------



## rigoletto@ (Jan 25, 2017)

What are the precedents to have a port removed from the tree? Between those unmaintained ports may have many dead projects what probably would be more interesting to have them removed, after a careful look, than leave them unmaintained.


----------



## cpm@ (Jan 26, 2017)

lebarondemerde said:


> What are the precedents to have a port removed from the tree? Between those unmaintained ports may have many dead projects what probably would be more interesting to have them removed, after a careful look, than leave them unmaintained.



The FreeBSD Porter's Handbook provides the answer:

https://www.freebsd.org/doc/en/books/porters-handbook/dads-deprecated.html


----------



## azathoth (Jul 18, 2017)

You have me considering pharo 6 port!


----------



## azathoth (Jul 18, 2017)

When is naviserver and aolserver coming back?


----------



## Deleted member 30996 (Aug 5, 2017)

I'll have to study the Porters Handbook. There is no maintainer for multimedia/xmms and I use it so much I don't turn it off anymore.


----------



## rufwoof (Aug 6, 2017)

Sevendogs said:


> The only thing I can determine is that the author appears to be the same or in the same group that wrote LXDE and related ports, all of which appear to be unmaintained. What should I do at this point? Is this simply a matter of updating the maintainer to me and submitting a PR? Is there a bigger issue with the LXDE port and all of the related ports?


LXDE looks to still be maintained/alive


----------



## ldgc (Aug 7, 2017)

Trihexagonal said:


> I'll have to study the Porters Handbook. There is no maintainer for xmms and I use it so much I don't turn it off anymore.



I noticed an error on the xmms link.


----------



## Deleted member 30996 (Aug 7, 2017)

pensador_13 said:


> I noticed an error on the xmms link.



The link in the pkg-descr doc takes you to the correct site but most of the site links don't work and it's a dead project since they've moved on to audio/xmms2. That RockLight plugin that causes the Thinklight of a Thinkpad to flash to the beat of the music is just what I needed, too. 

Beings multimedia/xmms is no longer being developed, there won't be any upstream versions for a maintainer to work from should a vulnerability or other problem require a version bump from 1.2.11. So becoming a maintainer for it would be a moot point, from what I understand of the portion of the Porters Handbook I've read so far.

Best save the distfile to a USB if you want to keep it should problems arise and it be removed from the ports tree


----------



## getopt (Aug 7, 2017)

Trihexagonal said:


> xmms2


Trihexagonal
You are posting wrong links.
Do it like this: audio/xmms2
Look at the construction by marking my link and click on reply: It uses "port" instead of "url" and uses the category like "audio/xmms2".


----------



## ldgc (Aug 7, 2017)

Trihexagonal said:


> The link in the pkg-descr doc takes you to the correct site but most of the site links don't work and it's a dead project since they've moved on to xmms2. That RockLight plugin that causes the Thinklight of a Thinkpad to flash to the beat of the music is just what I needed.
> 
> Beings xmms is no longer being developed, there won't be any upstream versions for a maintainer to work from should a vulnerability or other problem require a version bump from 1.2.11. So becoming a maintainer for it would be a moot point, from what I understand of the portion of the Porters Handbook I've read so far.
> 
> Best save the distfile to a USB if you want to keep it should problems arise and it be removed from the ports tree



But when the word xmms is clicked on your post, it gives a error on freshports


----------



## Deleted member 30996 (Aug 7, 2017)

Fixed.


----------



## Deleted member 30996 (Aug 7, 2017)

No I do not. I am using the port tag, directory, slash and the port name which takes you to the correct freshports page.

From your link:



> Create a link to a ported program's page on Freshports. Requires category and port name separated by a slash.



Your own link to audio/xmms2 shows the same link mine does.


----------



## aragats (Nov 22, 2017)

lme@ said:


> All you need then is some patience until some committer grabs the PR and eventually commits it or asks you to re-work the patch, if there are some issues left.


Sorry, until what? I've submitted patches back in October 2016, and nothing has happened then with PR 207117.


----------



## azathoth (Nov 22, 2017)

azathoth said:


> When is naviserver and aolserver coming back?


aolserver naviserve rpsotgresql rockin


----------



## lme@ (Nov 23, 2017)

aragats said:


> Sorry, until what? I've submitted patches back in October 2016, and nothing has happened then with PR 207117.


Sorry that nobody took that PR and committed the simple patch. The patch is now committed, the PR closed. Thanks a lot!


----------



## aragats (Nov 27, 2017)

Thank you lme@ ! Perfectly works now!


----------



## conta (Oct 28, 2018)

I get error: 


```
# nawk -F"|" '$6 == "ports@FreeBSD.org" {print $2}' /usr/ports/INDEX-`uname -r | cut -d'.' -f1`
nawk: can't open file /usr/ports/INDEX-11
 source line number 1
```


----------



## yuripv (Oct 28, 2018)

conta said:


> I get error:
> 
> 
> ```
> ...



Do a `make fetchindex` in /usr/ports.


----------



## nunotex (Jul 9, 2019)

lme@ said:


> Actually there a several benefits:
> 
> ...
> 
> ...



I adopted 2 ports and ported 1:

https://www.freshports.org/search.php?stype=maintainer&method=match&query=ed.arrakis@gmail.com&num=10&orderby=category&orderbyupdown=asc&search=Search&format=html&branch=head

Why is not my name included in aditional contributors list?

Thanks,

Nuno


----------



## rigoletto@ (Jul 9, 2019)

IIRC that list is of very regular contributors, usually src contributors. I think they have some more access/privileges internally.


----------



## lme@ (Jul 17, 2019)

rigoletto@ said:


> IIRC that list is of very regular contributors, usually src contributors. I think they have some more access/privileges internally.


No, it's for all contributors. But there's nothing that adds a new contributor automatically. Someone has to add it manually. I'll add you, nunotex


----------



## lme@ (Jul 17, 2019)

nunotex said:


> I adopted 2 ports and ported 1:
> 
> https://www.freshports.org/search.php?stype=maintainer&method=match&query=ed.arrakis@gmail.com&num=10&orderby=category&orderbyupdown=asc&search=Search&format=html&branch=head
> 
> ...



I just added you to the list. The website will be re-built shortly.


----------



## SirDice (Jul 17, 2019)

lme@ said:


> Add yourself as MAINTAINER in the Makefile.


I'm seriously considering taking up emulators/mame (and by extension emulators/mess) but are there any rules regarding the maintainer name? Do I need to use my real name or would "SirDice" be acceptable too? I haven't been able to find anything in this respect.


----------



## acheron (Jul 17, 2019)

SirDice said:


> I'm seriously considering taking up emulators/mame (and by extension emulators/mess) but are there any rules regarding the maintainer name? Do I need to use my real name or would "SirDice" be acceptable too? I haven't been able to find anything in this respect.


You just need a valid email address.


----------



## SirDice (Jul 17, 2019)

acheron said:


> You just need a valid email address.


In my case they're both somewhat related. It's the choice between my own personal domain or my GMail account. I'm leaning towards GMail for this as the information is publicly visible and I'm probably going to get more spam as a result. I'm just going to let Google filter out most of that crap. 

Expect a patch some time soon (within a few days)


----------



## userxbw (Aug 12, 2019)

1. Some of these I use have not and do not really need to be updated they are so old yet still work. ie dockapps for wmaker. so there really is no need to purge them from the system on the grounds that no one is the maintainer of same said app.


----------



## chrcol (Nov 14, 2019)

Hi guys, what about ports that still have a maintainer listed, but have been orphaned?

Some high profile ports are been orphaned its scary.

pftop
ifstat
zfs-stats
mcrypt
mhash
and ruby-bdb

zfs-stats and pftop used for core freebsd features.
mcrypt and mhash depended on by lots of stuff.
ruby-bdb is needed by portupgrade a major ports maintainer tool.

When I ran the command to check for ports that have no maintainer, a lot of this list isn't there as they listed with a maintainer.  There is also ports been removed because they not the latest version anymore some of them with claims of "unsupported by upstream" when that is not true.  Would I be able to make new ports of old versions of software?

libunwind is another port, that is completely broken on clang 8.0 which is now the base compiler in FreeBSD, I fixed it locally to get it to compile (just had to update src tarball and distfiles file as the one in ports tree is 2 years old), but again it has a maintainer listed.


----------



## rigoletto@ (Nov 14, 2019)

You have two different situations: orphaned ports are maintained by ports@ (aka the pool) which means we maintain them as possible. The other situation are the abandoned ports, those are the ports with a maintainer listed but who in practice don't maintain anything (and we don't get the notice when there is an update because that goes to the maintainer) .

In regards to the orphaned situation you can open a bug report with patch adding you as maintainer, and if the port need update/fixed they should also be done in the patch.

In case of an abandoned port basically the same except you should tell the port looks unmaintained, and  the `maintainer` will be informed by e-mail to agree or not. If he/she don't tell anything in two weeks the port is yours (but this is not automatic/scripted), or if he/she say no and keep not maintaining the port, the port is also likely to be yours later. Sometimes there is some major blockers forbidding you to update the port.

Thank you.


----------



## a6h (Mar 2, 2021)

Even if you've contributed thousands of ports over the years,
why anyone in their right mind should give you the "KEY?!",
-- "Commit Bit", I suppose! -- when you have such attitude?


----------



## bobmc (Apr 29, 2021)

lme@ said:


> See if a new version is available upstream.


Short story: when adopting a port, where are the Makefiles and metafiles that must be patched.

Please tell me what is "upstream" and "repository".  I know what these terms mean but not where they are in FreeBSD land because there are svn and git possibilities.


----------



## zirias@ (Apr 29, 2021)

bobmc said:


> Please tell me what is "upstream"


In the context of distributing/packaging software, "upstream" is the original software project (and the files they release, for opensource typically tarballs with source).


bobmc said:


> there are svn and git possibilities.


No. The only place where svn is still available is older releases of FreeBSD src that are still supported and started on svn. Everything else (docs, FreeBSD 13 and newer, _and_ ports) is only available via git.


----------



## SirDice (Apr 29, 2021)

bobmc said:


> when adopting a port, where are the Makefiles and metafiles that must be patched.


In the ports tree. Pick a port (any port will do) and open the port's Makefile. They all have a MAINTAINER defined. If the MAINTAINER is set to ports@freebsd.org it's unmaintained, i.e. up for adoption. If you want to adopt such a port edit the Makefile change the MAINTAINER to your email address and submit it via a PR as a patch. If your patch is approved and committed, congratulations, you are now the proud owner of that port.


----------



## bobmc (Apr 29, 2021)

Thanks Zirias, SirDice.

Here are some URLs I collected. I already did a dry run to edit the makefile, compile the code, etc.  There are two steps remaining.
1. do it again with the upstream version
2. issue a PR with attached patch

What would be the directory layout for the upstream and working copy on the same FreeBSD machine? Is it created with 'git diff' or just 'diff'









						freebsd-ports/comms/picocom at main · freebsd/freebsd-ports
					

FreeBSD ports tree (read-only mirror). Contribute to freebsd/freebsd-ports development by creating an account on GitHub.




					github.com
				



https://www.freshports.org/


			https://bugs.freebsd.org/bugzilla/enter_bug.cgi[
		


GitHub - freebsd/freebsd-ports: FreeBSD ports tree (read-only mirror)





						ports - FreeBSD ports tree
					






					cgit.freebsd.org
				












						FreeBSD Porter's Handbook
					

Essential reading if you plan on providing a port of a third party piece of software




					docs.freebsd.org


----------



## SirDice (Apr 30, 2021)

bobmc said:


> What would be the directory layout for the upstream


That's entirely up to the project. But this question seems to infer you think you need to host that project yourself. That's not the case. Unless it's your own project of course.


----------



## bobmc (Apr 30, 2021)

SirDice said:


> That's entirely up to the project. But this question seems to infer you think you need to host that project yourself. That's not the case. Unless it's your own project of course.


I think it can be done by clone or branch the upstream to local, mark the upstream as remote origin, edit the local, and then make a diff.  But I need to study the tools some more.


----------



## SirDice (Apr 30, 2021)

bobmc said:


> I think it can be done by clone or branch the upstream to local, mark the upstream as remote origin, edit the local, and then make a diff.


I'm not sure you understand what 'upstream' means in this context. The 'upstream' is the original source. As a port maintainer you don't have to worry about that. Although it'll be good form if you liaise with the developers to get specific FreeBSD patches into their source in order to improve the original code. But how you do that will totally depend on the project itself. You don't always have access to their development source tree, sometimes all you have is a source tarball you downloaded from their website.


----------



## bobmc (Apr 30, 2021)

> I'm not sure you understand what 'upstream' means in this context.



I worked on a coding team using CVS and SVN.  Each developer branched from the latest release (usually). And later these branches were merged to create a new release.  This was simple enough.

But 'upstream' and 'downstream' and patches by email are strange for me.  But I can work with it given a little clarity.

This topic started with "See if a new version is available upstream."   This is too vague, I need to know the URL.  Likewise when 'repository" is mentioned.  I see many repos,  which one do I use and what is the URL.


----------



## debguy (May 12, 2021)

github is nice, now run by microsoft.  google is Allot cheaper to host projects.  as to DiY a git site, the bandwidth is of course the issue, and google has that.  that's what my shopping turned up.


----------



## debguy (May 13, 2021)

# Intel C++ Compiler  #  Android Studio

I would like to work on one of these.

Is this the right place to ask about "wanted ports" or only orphans here?

Is there an orphaned package that is more important than bleeding edge graphics?

I am unsure though if it Intel can be done without kernel hacking (which i am not fully read up on).  Intel released for ubuntu and that could mean reliance on linux kernel in awful ASM TLS GOT .gnu-tags ways, or not.

Android i like their speal of compiled from scratch open to public ... but I'm not so excited about doing VM work with an i5 4-cpu   Might be slow progress.

I saw "swift" in the orphan list.  I got and older 4.4.5 gcc to do that using Sun java instead of gcc's.  it's not orphaned for that is it?  Java not in gcc? (anyway doesn't apple do Swift?)

What would be an orphan or wanted port that, if compeleted, would "be wanted enough that admins would not refuse to deal with the eventual minor port file infractions", that is, I am not sent an automated email poudiere failed and admins refuse to answer mail?  What would they actually be interested in?


----------



## C. Adams (Sep 24, 2022)

So I'm trying to work myself up to try maintaining a port I use. However, it got depreciated before I managed to do so.






						FreshPorts -- multimedia/ccextractor: Closed caption extractor for MPEG and H264 files
					

CExtractor is a tool that produces subtitles from TV use. Global accessibility (all users, all content, all countries) is the goal.  WWW: https://www.ccextractor.org




					www.freshports.org
				




I'm now struggling on where to find the makefile as it isn't snatched anymore into my port tree. Can you provide advice on how to restore a port project?


----------



## T-Daemon (Sep 25, 2022)

C. Adams said:


> I'm now struggling on where to find the makefile as it isn't snatched anymore into my port tree.


You can get the files of the port from the FreeBSD git repositories web site. In case of the port in question, the last ports tree including the port would be the 2022Q2 quarterly ports tree. Open the files in a browser (choose 'plain', i.e. Makefile), save files. I suggest to get all files of the port, not only the Makefile, especially the patches under 'file'.

The ports location can be anywhere, a users home directory for example, as long as a updated ports tree is present to use its ports framework.



C. Adams said:


> Can you provide advice on how to restore a port project?


Open a review at https://reviews.freebsd.org, or less preferred by port committers (as I recall), a PR at https://bugs.freebsd.org. In either way there should be a patch attached, even if it's not complete or doesn't work as expected.

We have a port committer here in forums, zirias@, who maybe want to add to the said.

For documentation, I'm sure you are aware of the Porters Handbook, I mention it here just in case.


----------

