# How to get a port committed



## Tabs (Feb 14, 2017)

Hi all.. I have just submitted my first port (bug 217105) I know I need to be patient because committers are busy, I'm just curious if there are any additional steps once you have submitted the bug? I see new ports submitted in 2015 still sitting with a status of 'new'. Do I just need to cross my fingers that someone will pick it up?

Anyway, I had fun making the port, still learning C (slowly!) soon I'll hopefully be porting my own software.

Cheers


----------



## marino (Feb 14, 2017)

if you want to improve your chances, you should attach a log from `poudriere testport` or `synth test` proving that you have done a reasonable amount of QA.  This will almost certainly reveal one or more issues that the committers would have to kick the port back anyway.  Better that *you* discover the issues and fix them first.

Those logs automatically flag the new port as more mature than any port without them.  If you were a committer and you had to pick one of hundreds, would you pick an untested one or one with test logs provided?


----------



## Tabs (Feb 14, 2017)

marino@ said:


> if you want to improve your chances, you should attach a log from `poudriere testport` or `synth test` proving that you have done a reasonable amount of QA.  This will almost certainly reveal one or more issues that the committers would have to kick the port back anyway.  Better that *you* discover the issues and fix them first.
> 
> Those logs automatically flag the new port as more mature than any port without them.  If you were a committer and you had to pick one of hundreds, would you pick an untested one or one with test logs provided?



Thanks! Looking into it now.


----------



## tobik@ (Feb 14, 2017)

While you're at it best fix those ports-mgmt/portlint warnings too 

```
WARN: /usr/home/tobias/Downloads/memleax/pkg-plist: There are only 2 items in the plist.  Consider using PLIST_FILES instead of pkg-plist when installing less than 6 items.
WARN: /usr/home/tobias/Downloads/memleax/pkg-descr: includes lines that exceed 80 characters.
WARN: Makefile: [3]: whitespace before end of line.
FATAL: Makefile: [19]: use a tab (not space) after a variable name
FATAL: Makefile: [20]: use a tab (not space) after a variable name
FATAL: Makefile: [21]: use a tab (not space) after a variable name
FATAL: Makefile: [23]: use a tab (not space) after a variable name
FATAL: Makefile: [25]: use a tab (not space) after a variable name
WARN: Makefile: possible direct use of "CONFIGURE_ARGS= --prefix=/usr/local" found. if so, use ${PREFIX} or ${LOCALBASE}, as appropriate.
FATAL: Makefile: extra item "LICENSE" placed in the MAINTAINER section.
WARN: Makefile: COMMENT should begin with a capital, and end without a period
WARN: Makefile: COMMENT exceeds 70 characters limit.
FATAL: Makefile: extra item "ONLY_FOR_ARCHS" placed in the LICENSE section.
WARN: Makefile: "LIB_DEPENDS" has to appear earlier.
7 fatal errors and 7 warnings found.
```


----------



## abishai (Feb 14, 2017)

Usually, I'm crying in ports@ mailing list. But it's after fixing poudriere warnings.


----------



## marino (Feb 14, 2017)

abishai said:


> Usually, I'm crying in ports@ mailing list.


You'd better be careful about this.
If it's a standard PR that is less than 2-weeks old, you might get a private scolding.
If it's a new port like this, that looks like you're trying to cut the line.

Now "pinging" after a few weeks is okay, but simply calling for a committer especially as a way of short-cutting the time to commit can backfire.  We had a guy that would open a PR and IMMEDIATELY ask on the list to commit it.  That didn't go over well and I think he got talked to.


----------



## abishai (Feb 14, 2017)

Probably I'm very lucky, but I was very-very proud when something started to work, so the first thing I started is to poke people in mailing list. Commiter was a very kind person, he even gave me some tips how to install poudriere. Not sure I'd be with FreeBSD if got scolding in that time. Sorry if I gave bad advice 

But I think I waited a week or who.


----------



## marino (Feb 14, 2017)

guy I was talking about did it several times.  I doubt there would be any scolding for first time offense.
Nevertheless, I would say hold off a minimum of 2 weeks before pinging the main list.  Unless there's some issued CVE and you can point to a significant security fix that really needs to go ASAP.  My advice is to avoid look like you're trying to "get over".  Your new port probably isn't any more important than the other 400 new ports.  right?   

New ports PRs are different than existing port PRs too.  The 2-weeks really refers to the existing ports.  
I'd say befriend a committer and hopefully that connection will be the most effective way to streamline getting new ports into the tree.
Easier said than done, I know.


----------



## marino (Feb 14, 2017)

a good way to find them is search for "new port" or "[new port]" on all unassigned PRs.
generally some variation of "[new port]" is present in the PR title.


----------



## Tabs (Feb 15, 2017)

tobik@ said:


> While you're at it best fix those ports-mgmt/portlint warnings too
> 
> ```
> WARN: /usr/home/tobias/Downloads/memleax/pkg-plist: There are only 2 items in the plist.  Consider using PLIST_FILES instead of pkg-plist when installing less than 6 items.
> ...


Whoops!  won't skip the portlint bit next time!

Fixed all that now, just need to get synth to do it's thing, my port must be bad because it won't even be considered!


```
Scan of devel/memleax failed, it will not be considered.
There are no valid ports to build.  (Synth must exit)
```


----------



## kafka0 (Feb 15, 2017)

marino@ said:


> if you want to improve your chances, you should attach a log from `poudriere testport` or `synth test` proving that you have done a reasonable amount of QA.  This will almost certainly reveal one or more issues that the committers would have to kick the port back anyway.  Better that *you* discover the issues and fix them first.
> 
> Those logs automatically flag the new port as more mature than any port without them.  If you were a committer and you had to pick one of hundreds, would you pick an untested one or one with test logs provided?



Thanks for the tip! I might have missed the information in the Porter's Handbook, but I believe it's not mentioned that poudriere not only makes the porter's life easier, but also improves tha chances of a new port of being noticed.


----------



## tobik@ (Feb 15, 2017)

Tabs said:


> Fixed all that now, just need to get synth to do it's thing, my port must be bad because it won't even be considered!


Not necessarily. Synth needs an entry for memleax in /usr/ports/devel/Makefile to consider it.


----------



## marino (Feb 15, 2017)

I should have mentioned that.  That only has to be done on FreeBSD ports which uses those makefiles as "switches" to hook ports into the tree.  On DPorts, all ports are considered hooked into the tree so no category makefiles are used.


----------



## Tabs (Feb 15, 2017)

Getting close now..!

Synth is failing because there is a additional man page in the staging dir, which I left off the pkg-plist intentionally because I didn't want it to be installed.. Once I've figured out how to not stage that man page I should be done.


----------



## marino (Feb 15, 2017)

your choices are:

inhibit the man page from getting installed in the stage directory (somehow)
use the post-install target to remove (rm) the man page from the stage directory.
the latter is easier, the former is cleaner.


----------



## Tabs (Feb 15, 2017)

Done. Submitted the fixed .shar and the synth log.

Cheers for your help everyone, I really appreciate it!

.. It's kind of addictive actually


----------



## marino (Feb 15, 2017)

you might want to address this:

```
Warning: 'bin/memleax' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
```

adding INSTALL_TARGET=install-strip to makefile might do it.
Otherwise you might have to set INSTALL to ${BSD_INSTALL_PROGRAM} 
there are hundreds of examples of this in ports.


----------



## Tabs (Feb 15, 2017)

marino@ said:


> you might want to address this:
> 
> ```
> Warning: 'bin/memleax' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
> ...



Should have spotted that.. Fixed it too with ${STRIP_CMD}. What is 'stripping'?

Thanks!


----------



## cpm@ (Feb 15, 2017)

Tabs said:


> Should have spotted that.. Fixed it too with ${STRIP_CMD}. What is 'stripping'?
> 
> Thanks!





> In Unix and Unix-like operating systems, the *strip* program removes inessential information from executable binary programs and object files, thus potentially resulting in better performance and sometimes significantly less disk space usage ('inessential information' means information that is not required for correct functioning of the binary in normal execution). This information may consist of debugging and symbol information; however the standard leaves the scope of changes up to the implementer.



https://en.wikipedia.org/wiki/Strip_(Unix)


----------



## marino (Feb 15, 2017)

stripping means removing debug symbols.  It can reduce the size of the executable by well more than 50%.
You would use STRIP_CMD when the install target doesn't exist and you didn't fix/override vendor makefile definitions of install.
STRIP_CMD is basically the last resort, not the first one.
The end result is the same though, so its acceptable.


----------



## marino (Feb 15, 2017)

in case people are wondering, if WITH_DEBUG or DEBUG_FLAGS are set, the binary is not stripped (and I assume the QA check doesn't complain because it's not supposed to be stripped at that point)


----------



## Tabs (Feb 15, 2017)

Got it  I've learned a lot doing my first port.


----------



## cpm@ (Feb 15, 2017)

marino@ said:


> in case people are wondering, if WITH_DEBUG or DEBUG_FLAGS are set, the binary is not stripped (and I assume the QA check doesn't complain because it's not supposed to be stripped at that point)



According to Mk/bsd.port.mk

WITH_DEBUG=yes changes ${STRIP_CMD} from /usr/bin/strip to /bin/true.  For ports that set INSTALL_TARGET to install-strip, it changes the target to install.


----------

