How to get a port committed

Tabs

Tabs

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 :beer:
 
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?
 
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?
Click to expand...

Thanks! Looking into it now.
 
While you're at it best fix those ports-mgmt/portlint warnings too :)
Code: 
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 said:
Usually, I'm crying in ports@ mailing list.;)
Click to expand...
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.
 
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 :p

But I think I waited a week or who.
 
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.
 
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.
 
tobik@ said:
While you're at it best fix those ports-mgmt/portlint warnings too :)
Code: 
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.
Click to expand...
Whoops! :oops: 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!

Code: 
Scan of devel/memleax failed, it will not be considered.
There are no valid ports to build.  (Synth must exit)
 
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?
Click to expand...

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.
 
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.
 
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.
 
your choices are:
  1. inhibit the man page from getting installed in the stage directory (somehow)
  2. use the post-install target to remove (rm) the man page from the stage directory.
the latter is easier, the former is cleaner.
 
Done. Submitted the fixed .shar and the synth log.

Cheers for your help everyone, I really appreciate it!

.. It's kind of addictive actually :)
 
you might want to address this:
Code: 
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.
 
marino@ said:
you might want to address this:
Code: 
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.
Click to expand...

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

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

Thanks!
Click to expand...

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.
Click to expand...

https://en.wikipedia.org/wiki/Strip_(Unix)
 
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.
 
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)
 
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)
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top