Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 May 1999 05:24:46 -0700 (PDT)
From:      asami@cs.berkeley.edu (Satoshi Asami)
To:        ports@freebsd.org
Subject:   3-stable build running every day
Message-ID:  <199905031224.FAA97026@silvia.hip.berkeley.edu>

next in thread | raw e-mail | index | archive | help
Hi,

In anticipation of the ports freeze on May 10th, I've changed my
script so it will be running 3-stable builds every day.  Please check

http://bento.freebsd.org/~asami/errorlogs/3-latest/

once in a while.  The script starts at 5AM PST but it takes a
couple of hours to do the cvs updates and stuff so the actual build
won't start until around 7AM PST.

While I'm talking, here's the latest committers' guide, in case you
don't know what "errorlogs" or "ports freeze" mean.  You can also get
this file from

http://www.freebsd.org/~asami/cvsguide.txt

-PW
------
A Guide for FreeBSD Ports Committers

0. Importing a new port

0A. How do I import a new port?

    First, please read the section about repository copy.

    To import a new port, the easiest way is to use the "easy-import"
    script on freefall.  It will ask you some questions and import the
    port in the directory you specifies.  It will also add an entry to
    the modules file.  It was written by Joerg Wunsch ("joerg") so
    please send mail to him if you have questions about easy-import.

    One thing it *won't* do for you is add the port to the parent
    (category) Makefile.  You have to do that yourself.

0B. Any other things you need to know when I import a new port?

    Check the port, preferably to make sure it compiles and packages
    correctly.  This is the recommended sequence:

    	  make install
	  make package
	  make deinstall
	  pkg_add <package you built above>
	  make deinstall
	  make reinstall
	  make package

    The handbook's "porting" section contains more detailed
    instructions.

    Use portlint to check the syntax of the port.  You don't
    necessarily have to eliminate all warnings but make sure you have
    fixed the simple ones.

    If the port came from a submitter who hasn't contributed to the
    project before, add that person's name to the handbook's
    "additional contributors" section.

    Close the PR if the port came in as a PR.  To close a PR, just do
    an "edit-pr <PR#>" on freefall and change the "state" from "open"
    to "closed".  You will be asked to enter a message and then you're
    done.

1. Repository copy

1A. When do we need a repository copy?

    When you want to import a port that is related to any port that is
    in the tree in a separate directory, please send mail to the ports
    manager asking about it.  Here "related" means it is a different
    version or a slightly modified version.  Examples are
    print/ghostscript* (different versions) and x11-wm/windowmaker*
    (English-only and internationalized version).

    Another example is when a port is moved from one subdirectory to
    another, or when you want to change the name of a directory due to
    the authors calling their software by a different name even though
    it's a descendant of a port already in a tree.

1B. Why do we need a repository copy?

    To preserve the history of old ports.  To avoid excessive slowdown
    of CVS and to reclaim disk space, we periodically purge old files
    from the Attic.  This will cause old history to be lost if not
    preserved by a repository copy.

1C. When do we *not* need a repository copy?

    When there is no history to preserve.  If a port is imported into
    a wrong category and is moved immediately, it suffices to simple
    cvs remove the old one and cvs import new one.

1D. What do I need to do?

    Send mail to the ports manager, who will do a copy from the old
    location/name to the new location/name.  You will then get a
    notice, at which point you are expected to perform the following:

    @ cvs remove the old port (if necessary)
    @ adjust the parent (category) Makefile
    @ change modules
    @ if the port is depended by other ports, change their Makefiles'
      dependency lines
    @ if the port changed categories, modify the CATEGORIES line of
      the port's Makefile accordingly

2. Ports freeze

2A. What is a "ports freeze"?

    Before a release, it is necessary to restrict commits to the ports
    tree for a short period of time while the packages and the release
    itself are being built.  This is to ensure consistency among the
    various parts of the release, and is called the "ports freeze".

2B. How long is a ports freeze?

    Usually two to three days.

2C. What does it mean to me?

    During the ports freeze, you are not allowed to commit anything to
    the tree without an explicit approval from the ports manager.  An
    "explicit approval" here means either of the following:

    @ you asked the ports manager and got a reply saying "go ahead and
      commit it"
    @ the ports manager sent a mail to you or the mailing lists during
      the ports freeze pointing out that the port is broken and has to
      be fixed

    Note that you don't have implicit permission to fix a port during
    the freeze just because it's broken.

2D. How do I know when the ports freeze starts?

    The ports manager will send out warning messages to the ports and
    committers mailing lists announcing the start of the impending
    release, usually two or three weeks in advance.  The exact
    starting time will not be determined a few days before the actual
    release.  This is because the ports freeze has to be synchronized
    with the release, and it's usually not known until then when
    exactly the release will be rolled.

    When the freeze starts, there will be another announcement to the
    committers list, of course.

2E. How do I know when the ports freeze ends?

    A few hours after the release, the ports manager will send out a
    mail to the ports and committers mailing lists announcing the end
    of the ports freeze.  Note that the release being cut doesn't
    automatically end the freeze -- we have to make sure there won't
    be any last minute snafus that result in an immediate re-rolling
    of the release.

3. Misc.

3A. How do I know if my port is building correctly or not?

    First, go check "http://bento.freebsd.org/~asami/errorlogs/".
    There, you will find error logs from the latest package building
    runs on 3-stable and 4-current.

    However, just because the port doesn't show up there doesn't mean
    it's building correctly.  (One of the dependencies may have
    failed, for instance.)  Here are relevant directories on bento, so
    feel free to dig around.

 /a/asami/portbuild/3/errors        error logs from latest 3-stable run
                     /logs          all logs from latest 3-stable run
                     /packages      packages from latest 3-stable run
                     /bak/errors    error logs from last complete 3-stable run
	             /bak/logs      all logs from last complete 3-stable run
                     /bak/packages  packages from last complete 3-stable run
                   /4/errors        error logs from latest 4-current run
                     /logs          all logs from latest 4-current run
                     /packages      packages from latest 4-current run
                     /bak/errors    error logs from last complete 4-current run
	             /bak/logs      all logs from last complete 4-current run
                     /bak/packages  packages from last complete 4-current run

    Basically, if the port shows up in the packages dir, or it is in
    the "logs" dir but not in the "errors" dir, it means it built
    fine.  (The "errors" directories are where you get from the web
    page.)

3B. I added a new port.  Do I need to add it to the INDEX?

    No.  The ports manager will regenerate the INDEX and commit it
    every few days.

3C. Oh.  Are there any other files I'm not allowed to touch?

    Any file right under /usr/ports, or any file under a directory
    that starts with an uppercase letter (Mk, Tools, etc.).  In
    particular, the ports manager is very protective about bsd.port.mk
    so don't commit changes to it unless you want to face his
    wra(i)th. :)

-PW (aka your friendly ports wraith/wizard)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905031224.FAA97026>