# Port:  MASTER_SITES what can I use?



## debguy (Feb 25, 2021)

I am trying to submit a new port from a new repository (not from any existing).  It was build using freeBSD 12.2 so linux is not involved.


----------



## debguy (Feb 25, 2021)

ditto


----------



## diizzy (Feb 25, 2021)

No, it should not live in distfiles only or in the tree itself. Unless you have a FreeBSD account and a very good reason just host it on gitlab, github some random webserver etc.

If we post a link do your project and what you're trying to accomplish we can most likely give you a few pointers.


----------



## debguy (Feb 26, 2021)

GitHub - johndhend/Motif
					

Contribute to johndhend/Motif development by creating an account on GitHub.




					github.com


----------



## debguy (Feb 26, 2021)

I did get a makesum.  (pkg-files posted on git)

But the porter's guide says "use svn add ." (I get the famous "not a working copy" error because there is no existing repository).  The guide also says "Please do not send the whole .tar.gz".  So I'm back asking again.


----------



## George (Feb 26, 2021)

I have a port on github. I do this:
1. Create a repo with the portname (e.g. myport). I put my source files in there.
2. I create a release. I tag it with the portversion (e.g. 1.0).
3. I use a Makefile like this:

```
# $FreeBSD$

PORTNAME=    myport
DISTVERSION=    1.0
CATEGORIES=    sysutils

MAINTAINER=    my.website@someplace.com
COMMENT=        Dummy port

LICENSE=    BSD2CLAUSE

RUN_DEPENDS=    sudo>0:security/sudo

USES=        gnome
USE_GNOME=    gtk30

USE_GITHUB=    yes
GH_ACCOUNT=    mygithubaccountname

PLIST_FILES=    bin/myfiles

do-install:
    ${INSTALL_PROGRAM} work/${PORTNAME}-${DISTVERSION}/${PORTNAME} ${STAGEDIR}${LOCALBASE}/bin

.include <bsd.port.mk>
```

So with github, if you create a release, there is no need to use MASTER_SITES.


----------



## Alexander88207 (Feb 26, 2021)

FreeBSD Porter's Handbook
					

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




					docs.freebsd.org


----------



## debguy (Feb 26, 2021)

Tools/scripts/addport won't work, no key please.

freebsd articles/committers-guide (not Handbook).  "Get mentor approval before committing each of these  changes!"

To create a new node  /usr/ports/x11-wm/Motif using SVN I have to have an ssh gpg key.  But if the node is already created I can submitt a .diff to the node (requires no or less keys and permissions).

I guess I'll send email to the maintainer's list.  I know they do not like mail that is not pertinent so I would do that as a last resort.  From what I understand so far.


----------



## debguy (Feb 26, 2021)

I don't see "submitting a .diff to freebsd bugzilla" as possible going forward.  The site is absolutely jammed with vastly spurious port requests that I'm sure maintainers have no intent of running down.  Even serious issues would be lost in the shuffle.

I should need a tester (ie, not me and on a tester list) and a way, if signed, to have freeBSD import from (github).  Why is because of what I already mentioned.  They cannot mentor every programmer and have 0 intent of checking through infinite bug lists for new submissions.


----------



## Alexander88207 (Feb 26, 2021)

debguy said:


> I don't see "submitting a .diff to freebsd bugzilla" as possible going forward.  The site is absolutely jammed with vastly spurious port requests that I'm sure maintainers have no intent of running down.  Even serious issues would be lost in the shuffle.



So far I have made only positive experiences and if something has not moved for a long time then I just left a ping.


----------



## debguy (Feb 27, 2021)

The "port maintainerss" did not offer mentoring, they gave me a URL to "old dead ports when to stop maintaining" and "here's a URL to the guide of Port Maintainers rule over everything in freeBSD".

FEELS LIKE UBUNTU.  (I know historically people fled debian and ubuntu because of tech terrorism by maintainers - when freeBSD became popular:  ubuntu maintainers suddently hopped over to freeBSD and began implementing their "maintainer style").

I'm not an impressionable person.  Your not telling me "Your the maintainer I'm not".  I know how much technology you people have intently destroyed, and how bad your work has been:  forced upgrades, dependency hell when not necessary, control of who gets to talk.  (though there has been good work too)


----------



## Jose (Feb 27, 2021)

debguy said:


> I don't see "submitting a .diff to freebsd bugzilla" as possible going forward.


Worked for me.



debguy said:


> The "port maintainerss" just told me to (expletive) OFF, did not offer mentoring...


I seriously doubt this. If it did happen, I suggest moderating your language and trying again.


----------



## diizzy (Feb 27, 2021)

First of all, thanks for contributing to the FreeBSD community 

While I'm not a ports committer I'm quite confident that I can explain the reasoning behind some decisions.

Submitting a patch does not require you have commit access, it does however require you to offer maintainership if it's a new port unless agreed upon by a maintainer team (edge cases). How to submit a patch is documented in Porter's Handbook and it refers to SVN because that's what the tree (FreeBSDs) still uses, it will eventually switch to git (a few months left) however. There's no hard requirement to use SVN however, you can use a VCS you prefer but it needs to be able to generate a patch/diff file (avoid .shar because it's pain to work with) but it is implied that you as a submitter know how to generate a patch using your preferred VCS.

Mentoring will usually be offered if you for a period of time (usually at least a few months) submit patches that are consistent. They don't need to be perfect all the time because we all do mistakes but the majority should at least work as intended and get accepted by a committer or maintainer if it's an existing port.

And with all due respect John, looking at your PR at bugzilla you need to dial down the agressiveness of your replies, it's not going to help and I think raised questions are vaild and please keep in mind that people can make mistakes (such as misreading about commit access).

I can't see anywhere were you're being told off, however "we" do not want "random forks" in the tree because it gets confusing, may cause compatibility issues such as packages clashing with eachother and they *usually *bitrot quickly (ie broken packages and a maintaince burden). While (open-)motif isn't dead it's not a very a active project looking at the commit history but unless your fork has breaking changes have you tried upstreaming your work as this is the preferred way to go instead of carrying forks or custom patches in tree?


----------

