Solved Maintainer duties

I wish to become a maintainer for a few ports I use and plan to use. I talked to the ports mailing list about it and have read the contribution documentation about ports. I see the steps clearly but have gotten lost when it comes to the actual changes I am supposed to make before starting the patch with diff. Here are the steps I have listed as duties.
1.submit patch with PR
2.build in poudriere
3.pass portlint
4.debug and upgrade
5.take maintainership
What are the actual changes that a port maintainer makes to the port before following all these steps and where in the order of it does it fall into? Thanks.
 
I'm a recent maintainer. Got my first port a few months ago (emulators/fs-uae). What I would recommend is to set up poudriere on your own system. That will allow you to extensively test the port before you submit the patch. Committers don't like to go back and forth with you in order to fix your patches. They prefer nice clean patches that work right away.

My workflow goes something like this:
  • Fetch a current checkout of the port in question to work with: svn co https://svn.freebsd.org/ports/head/category/port
  • Modify what needs to changed, Makefile, distinfo, pkg-plist, etc.
  • Test those changes with make config, make patch, make configure, etc. Until you're satisfied it builds correctly.
  • Run portlint(1), fix any issues that come up.
  • Copy your local port to poudriere and do a couple of poudiere testport runs. Make sure things like dependencies and pkg-plist are correct.
  • Make a package with poudriere. Install that package on a test system. Test your application, does it work correctly?
  • Make a patch: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/port-upgrading.html#svn-diff
  • Create a PR for it, attach the patch from the previous step
  • wait for a port commiter to pick it up. If you haven't gotten a response in a week or so, send a ping to ports@ mailing list.
  • If it's a good patch a bunch of automated processes will do various test builds with it.
  • If those are all good the committer will push that patch to the ports tree.

That's pretty much it. Maintainership is set by the MAINTAINER in the port's Makefile. You can do this while you're patching things. It needs to be a valid email address. Preferably the same one you used for bugzilla.
 
Last edited:
  1. Portsnap snapshot is make from SVN.
  2. At any given time, portsnap snapshot is hardly an exact copy of SVN revision.
  3. With SVN you can checkout different branches, e.g. quarterly.
  4. Use SVN or portsnap, not both, e.g. don't try to update SVN tree with portsnap, vice versa.
 
I'm a recent maintainer. Got my first port a few months ago (emulators/fs-uae). What I would recommend is to set up poudriere on your own system. That will allow you to extensively test the port before you submit the patch. Committers don't like to go back and forth with you in order to fix your patches. They prefer nice clean patches that work right away.

My workflow goes something like this:
  • Fetch a current checkout of the port in question to work with: svn co https://svn.freebsd.org/ports/head/category/port
  • Modify what needs to changed, Makefile, distfile, pkg-plist, etc.
  • Test those changes with make config, make patch, make configure, etc. Until you're satisfied it builds correctly.
  • Run portlint(1), fix any issues that come up.
  • Copy your local port to poudriere and do a couple of poudiere testport runs. Make sure things like dependencies and pkg-plist are correct.
  • Make a package with poudriere. Install that package on a test system. Test your application, does it work correctly?
  • Make a patch: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/port-upgrading.html#svn-diff
  • Create a PR for it, attach the patch from the previous step
  • wait for a port commiter to pick it up. If you haven't gotten a response in a week or so, send a ping to ports@ mailing list.
  • If it's a good patch a bunch of automated processes will do various test builds with it.
  • If those are all good the committer will push that patch to the ports tree.

That's pretty much it. Maintainership is set by the MAINTAINER in the port's Makefile. You can do this while you're patching things. It needs to be a valid email address. Preferably the same one you used for bugzilla.

What is distfile? I only see
pkg-descr, pkg-plist, and checksum file.
 
What is distfile? I only see
pkg-descr, pkg-plist, and checksum file.
Your reading into the matter is incomplete, you should start at the basics. First read the handbook, chapter: 4. Installing Applications: Packages and Ports, 4.5. Using the Ports Collection, where what a distfile is is described, then ports(7) (try those commands, see them in action), THEN porters handbook.

SirDice meant distinfo, wrote by mistake distfile instead.
 
Your reading into the matter is incomplete, you should start at the basics. First read the handbook, chapter: 4. Installing Applications: Packages and Ports, 4.5. Using the Ports Collection, where what a distfile is is described, then ports(7) (try those commands, see them in action), THEN porters handbook.

SirDice meant distinfo, wrote by mistake distfile instead.

I'm understanding how the process works now, but one more thing to complete my understanding please. And i promise I will continue reading through the documentation before asking questions. How do I attach the port to the PR I am submitting?
 
How do I attach the port to the PR I am submitting?
You don't attach the port. Use a title like "category/something: update to 1.2.3", then attach the svn-diff as a file ("Add an attachment" button at the bottom).
 
You don't attach the port. Use a title like "category/something: update to 1.2.3", then attach the svn-diff as a file ("Add an attachment" button at the bottom).

What changes do I need to make if I get the message "The first entry in CATEGORIES should be the directory where the port lives" when I issue make config, make patch, make configure? I looked in the Makefile and what was under category was correct.
 
You don't attach the port. Use a title like "category/something: update to 1.2.3", then attach the svn-diff as a file ("Add an attachment" button at the bottom).
Also... I'm looking at the poudriere documentation and have another question. How do I do poudriere testport on the port I'm working with and not the original port from the ports tree? Do I somehow use local ports tree?
 
What changes do I need to make if I get the message "The first entry in CATEGORIES should be the directory where the port lives" when I issue make config, make patch, make configure? I looked in the Makefile and what was under category was correct.
Which category is it? If you provide the Makefile it would be easier to analyze the error.
 
Which category is it? If you provide the Makefile it would be easier to analyze the error.

I would but...
The uploaded file does not have an allowed extension. The following extensions are allowed: .zip, .txt, .pdf, .png, .jpg, .jpeg, .jpe, .gif, .conf, .cfg, .ini, .xml

Its x11/nvidia-settings
 
Damn! Change to:
CATEGORIES= x11

Sorry.
Im just practicing on this one. I think all it needs is a maintainer and that there arent any updates or patching needed. When I issue the commands "make config, make patch, and make configure" I get these results, even after i have changed the category in the makefile.

make config:
root@machine17:~/nvidia-settings # make config
===> No options to configure

make patch:
root@machine17:~/nvidia-settings # make patch
/!\ nvidia-settings-440.100: Makefile errors /!\

The first entry in CATEGORIES should be the directory where the port lives

*** Error code 1

Stop.
make: stopped in /root/nvidia-settings

make configure:
root@machine17:~/nvidia-settings # make configure
/!\ nvidia-settings-440.100: Makefile errors /!\

The first entry in CATEGORIES should be the directory where the port lives

*** Error code 1

Stop.
make: stopped in /root/nvidia-settings
 
Have you used the tabulator (tab) key after CATEGORIES= for space before x11?

I pulled a copy on disk, changed MAINTAINER, ran make patch , no errors.

How did you pull your copy?
 
Have you used the tabulator (tab) key after CATEGORIES= for space before x11?

I pulled a copy on disk, changed MAINTAINER, ran make patch , no errors.

How did you pull your copy?

I used the tab key after CATEGORIES=
PORTNAME= nvidia-settings
PORTVERSION= 440.100
CATEGORIES= x11
it looks like just a space there but I used tab. I used svn co like in the first reply. Ill double check everything but i'm pretty sure i'm not making any mistakes.
 
I'm a recent maintainer. Got my first port a few months ago (emulators/fs-uae). What I would recommend is to set up poudriere on your own system. That will allow you to extensively test the port before you submit the patch. Committers don't like to go back and forth with you in order to fix your patches. They prefer nice clean patches that work right away.

My workflow goes something like this:
  • Fetch a current checkout of the port in question to work with: svn co https://svn.freebsd.org/ports/head/category/port
  • Modify what needs to changed, Makefile, distinfo, pkg-plist, etc.
  • Test those changes with make config, make patch, make configure, etc. Until you're satisfied it builds correctly.
  • Run portlint(1), fix any issues that come up.
  • Copy your local port to poudriere and do a couple of poudiere testport runs. Make sure things like dependencies and pkg-plist are correct.
  • Make a package with poudriere. Install that package on a test system. Test your application, does it work correctly?
  • Make a patch: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/port-upgrading.html#svn-diff
  • Create a PR for it, attach the patch from the previous step
  • wait for a port commiter to pick it up. If you haven't gotten a response in a week or so, send a ping to ports@ mailing list.
  • If it's a good patch a bunch of automated processes will do various test builds with it.
  • If those are all good the committer will push that patch to the ports tree.

That's pretty much it. Maintainership is set by the MAINTAINER in the port's Makefile. You can do this while you're patching things. It needs to be a valid email address. Preferably the same one you used for bugzilla.

Okay! thanks for all the help. I understand the process a little better now. so once I have the package made with poudriere and everything is working fine, i just issue a diff command between the old and new directories in the original port skeleton? Not sure how to do this when looking at the documentation. Im a little confused about how it's explained. Would it be too much to ask to see an example of using diff with an actual port?
 
You can test your Makefile with portlint.
3.5. Checking the Port with portlint
Okay! thanks for all the help. I understand the process a little better now. so once I have the package made with poudriere and everything is working fine, i just issue a diff command between the old and new directories in the original port skeleton? Not sure how to do this when looking at the documentation. I'm a little confused about how it's explained. Would it be too much to ask to see an example of using diff with an actual port?
 
I used svn co like in the first reply. Ill double check everything but i'm pretty sure i'm not making any mistakes.
I replaced the Makefile of a fresh pulled in port image with your Makefile, changed CATEGORIES, set the environment to DEVELOPER, ran make patch, no errors were printed.

I suggest you delete the test port, fetch a fresh image, make your changes, test again.

i just issue a diff command between the old and new directories in the original port skeleton? Not sure how to do this ...

For the diff file (11.1. Using Subversion to Make Patches):


After what SirDice said about testing and chapters "3.4 Testing the port", "3.5 Checking the port with portlint":

svn status
svn update
svn diff > ../`make -VPKGNAME`.diff
 
Back
Top