|FreeBSD is a registered trademark of the FreeBSD Foundation.|
<prompt>%</prompt> <userinput>gpg --full-gen-key</userinput>
gpg (GnuPG) 2.1.8; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Warning: using insecure memory!
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? <userinput>1</userinput>
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) <userinput>2048</userinput> <co xml:id="co-pgp-bits"/>
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) <userinput>3y</userinput> <co xml:id="co-pgp-expire"/>
Key expires at Wed Nov 4 17:20:20 2015 MST
Is this correct? (y/N) <userinput>y</userinput>
GnuPG needs to construct a user ID to identify your key.
Real name: <userinput><replaceable>Chucky Daemon</replaceable></userinput> <co xml:id="co-pgp-realname"/>
Email address: <userinput><replaceable>email@example.com</replaceable></userinput>
You selected this USER-ID:
"<replaceable>Chucky Daemon <firstname.lastname@example.org></replaceable>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? <userinput>o</userinput>
You need a Passphrase to protect your secret key.
|The FreeBSD <literal>doc/www</literal> repository switched from <acronym>CVS</acronym> to Subversion on May 19th, 2012. The first real <acronym>SVN</acronym> commit is <emphasis>r38821</emphasis>.|
|Files are added to a <acronym>SVN</acronym> repository with <command>svn add</command>. To add a file named <emphasis>foo</emphasis>, edit it, then:|
|Subversion does not require deleting the file before using <command>svn rm</command>, and indeed complains if that happens.|
|Due to the mergeinfo propagation issues described earlier, it is very important to never merge changes into a sparse working copy. Always use a full checkout of the branch being merged into. For instance, when merging from HEAD to 7, use a full checkout of stable/7:|
|Now, import the sources into the <filename>dist</filename> directory. Once the files are in place, <command>svn add</command> the new ones, then <command>svn commit</command> and tag the imported version. To save time and bandwidth, direct remote committing and tagging is possible:|
|All <filename>src</filename> commits go to FreeBSD-CURRENT first before being merged to FreeBSD-STABLE. The FreeBSD-STABLE branch must maintain <acronym>ABI</acronym> and <acronym>API</acronym> compatibility with earlier versions of that branch. Do not merge changes that break this compatibility.|
|When the mentor decides that a mentee has learned the ropes and is ready to commit on their own, the mentor announces it with a commit to <filename>conf/mentors</filename>. This file is in the <filename>svnadmin</filename> branch of each repository:|
Submitted by: John Smith <John.Smith@example.com>
Reviewed by: -arch
Approved by: <replaceable>abc</replaceable> (maintainer)
Obtained from: OpenBSD
MFC after: <replaceable>2 weeks</replaceable>
|If in Doubt...|
|Glen Barber <email>gjb@FreeBSD.org</email>, Konstantin Belousov <email>kib@FreeBSD.org</email>, Bryan Drewery <email>bdrewery@FreeBSD.org</email>, Marc Fonvieille <email>blackend@FreeBSD.org</email>, Xin Li <email>delphij@FreeBSD.org</email>, Colin Percival <email>cperciva@FreeBSD.org</email> Hiroki Sato <email>hrs@FreeBSD.org</email>, Gleb Smirnoff <email>glebius@FreeBSD.org</email>|
|This is another <quote>do not argue about it</quote> issue since it is the release engineer who is ultimately responsible (and gets beaten up) if a change turns out to be bad. Please respect this and give the release engineer your full cooperation when it comes to the FreeBSD-STABLE branch. The management of FreeBSD-STABLE may frequently seem to be overly conservative to the casual observer, but also bear in mind the fact that conservatism is supposed to be the hallmark of FreeBSD-STABLE and different rules apply there than in FreeBSD-CURRENT. There is also really no point in having FreeBSD-CURRENT be a testing ground if changes are merged over to FreeBSD-STABLE immediately. Changes need a chance to be tested by the FreeBSD-CURRENT developers, so allow some time to elapse before merging unless the FreeBSD-STABLE fix is critical, time sensitive or so obvious as to make further testing unnecessary (spelling fixes to manual pages, obvious bug/typo fixes, etc.) In other words, apply common sense.|
<prompt>%</prompt> <userinput>/usr/ports/Tools/scripts/mfh 380362</userinput>
Checked out revision 380443.
Updated to revision 380443.
--- Merging r380362 into '2015Q1':
--- Recording mergeinfo for merge of r380362 into '2015Q1':
--- Recording mergeinfo for merge of r380362 into '2015Q1/security':
--- Eliding mergeinfo from '2015Q1/security':
--- Recording mergeinfo for merge of r380362 into '2015Q1/security/rubygem-sshkit':
--- Eliding mergeinfo from '2015Q1/security/rubygem-sshkit':
--- 2015Q1/security/rubygem-sshkit/Makefile (revision 380443)
+++ 2015Q1/security/rubygem-sshkit/Makefile (working copy)
@@ -2,7 +2,7 @@
CATEGORIES= security rubygems
--- 2015Q1/security/rubygem-sshkit/distinfo (revision 380443)
+++ 2015Q1/security/rubygem-sshkit/distinfo (working copy)
@@ -1,2 +1,2 @@
-SHA256 (rubygem/sshkit-1.6.1.gem) = 8ca67e46bb4ea50fdb0553cda77552f3e41b17a5aa919877d93875dfa22c03a7
-SIZE (rubygem/sshkit-1.6.1.gem) = 135680
+SHA256 (rubygem/sshkit-1.7.0.gem) = 90effd1813363bae7355f4a45ebc8335a8ca74acc8d0933ba6ee6d40f281a2cf
+SIZE (rubygem/sshkit-1.7.0.gem) = 136192
--- 2015Q1 (revision 380443)
+++ 2015Q1 (working copy)
Property changes on: 2015Q1
Do you want to commit? (no = start a shell) [y/n]