From owner-dev-commits-doc-all@freebsd.org Mon May 17 03:04:24 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0057163A1A2 for ; Mon, 17 May 2021 03:04:24 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fk3rR6PKbz3nFx; Mon, 17 May 2021 03:04:23 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B92CA2482C; Mon, 17 May 2021 03:04:23 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14H34N3T098913; Mon, 17 May 2021 03:04:23 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14H34Ngo098912; Mon, 17 May 2021 03:04:23 GMT (envelope-from git) Date: Mon, 17 May 2021 03:04:23 GMT Message-Id: <202105170304.14H34Ngo098912@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Guangyuan Yang Subject: git: 19ea7bbe35 - main - committers-guide: Correct some paths for consistency MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ygy X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 19ea7bbe3564ac8be2a8b5b6c4fc5300497cb161 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 03:04:24 -0000 The branch main has been updated by ygy: URL: https://cgit.FreeBSD.org/doc/commit/?id=19ea7bbe3564ac8be2a8b5b6c4fc5300497cb161 commit 19ea7bbe3564ac8be2a8b5b6c4fc5300497cb161 Author: Guangyuan Yang AuthorDate: 2021-05-17 03:03:37 +0000 Commit: Guangyuan Yang CommitDate: 2021-05-17 03:03:37 +0000 committers-guide: Correct some paths for consistency --- documentation/content/en/articles/committers-guide/_index.adoc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc index 26329f5f4b..54cf8bc241 100644 --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -2243,12 +2243,12 @@ Those who have been given commit rights to the FreeBSD repositories must follow [.filename]#doc/documentation/content/en/articles/contributors/contrib-additional.adoc# - _Remove_ the entry. Entries are sorted by first name. . Add a News Item + -[.filename]#website/data/en/news/news.toml# - Add an entry. Look for the other entries that announce new committers and follow the format. Use the date from the commit bit approval email from mailto:core@FreeBSD.org[core@FreeBSD.org]. +[.filename]#doc/website/data/en/news/news.toml# - Add an entry. Look for the other entries that announce new committers and follow the format. Use the date from the commit bit approval email from mailto:core@FreeBSD.org[core@FreeBSD.org]. . Add a PGP Key + -`{des}` has written a shell script ([.filename]#documentation/tools/addkey.sh#) to make this easier. See the https://cgit.freebsd.org/doc/plain/documentation/static/pgpkeys/README[README] file for more information. +`{des}` has written a shell script ([.filename]#doc/documentation/tools/addkey.sh#) to make this easier. See the https://cgit.freebsd.org/doc/plain/documentation/static/pgpkeys/README[README] file for more information. + -Use [.filename]#documentation/tools/checkkey.sh# to verify that keys meet minimal best-practices standards. +Use [.filename]#doc/documentation/tools/checkkey.sh# to verify that keys meet minimal best-practices standards. + After adding and checking a key, add both updated files to source control and then commit them. Entries in this file are sorted by last name. + @@ -2258,7 +2258,7 @@ It is very important to have a current PGP/GnuPG key in the repository. The key ====== . Update Mentor and Mentee Information + -[.filename]#base/head/share/misc/committers-repository.dot# - Add an entry to the current committers section, where _repository_ is `doc`, `ports`, or `src`, depending on the commit privileges granted. +[.filename]#src/share/misc/committers-.dot# - Add an entry to the current committers section, where _repository_ is `doc`, `ports`, or `src`, depending on the commit privileges granted. + Add an entry for each additional mentor/mentee relationship in the bottom section. . Generate a Kerberos Password From owner-dev-commits-doc-all@freebsd.org Mon May 17 05:07:43 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 26ED263C46A for ; Mon, 17 May 2021 05:07:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fk6Zl0JC1z4YG7; Mon, 17 May 2021 05:07:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E6A17259E2; Mon, 17 May 2021 05:07:42 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14H57gBI058636; Mon, 17 May 2021 05:07:42 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14H57gIc058635; Mon, 17 May 2021 05:07:42 GMT (envelope-from git) Date: Mon, 17 May 2021 05:07:42 GMT Message-Id: <202105170507.14H57gIc058635@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Guangyuan Yang Subject: git: 606237d31e - main - Add a news entry for Guangyuan Yang (ygy) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ygy X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 606237d31e9dee2f1032d4f8d0c360e1aadb1f33 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 05:07:43 -0000 The branch main has been updated by ygy: URL: https://cgit.FreeBSD.org/doc/commit/?id=606237d31e9dee2f1032d4f8d0c360e1aadb1f33 commit 606237d31e9dee2f1032d4f8d0c360e1aadb1f33 Author: Guangyuan Yang AuthorDate: 2021-05-17 05:07:07 +0000 Commit: Guangyuan Yang CommitDate: 2021-05-17 05:07:07 +0000 Add a news entry for Guangyuan Yang (ygy) --- website/data/en/news/news.toml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/website/data/en/news/news.toml b/website/data/en/news/news.toml index b6e6f01625..2ca9215c08 100644 --- a/website/data/en/news/news.toml +++ b/website/data/en/news/news.toml @@ -1,4 +1,9 @@ # Sort news by year, month and day + +[[news]] +date = "2021-05-17" +description = "Enhanced commit privileges: Guangyuan Yang (doc, ports)" + [[news]] date = "2021-05-06" title = "January-March 2021 Status Report" From owner-dev-commits-doc-all@freebsd.org Mon May 17 05:16:42 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4420963C758 for ; Mon, 17 May 2021 05:16:42 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fk6n61VvPz4Ygh; Mon, 17 May 2021 05:16:42 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 1CB612613E; Mon, 17 May 2021 05:16:42 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14H5GgED071504; Mon, 17 May 2021 05:16:42 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14H5GgTG071503; Mon, 17 May 2021 05:16:42 GMT (envelope-from git) Date: Mon, 17 May 2021 05:16:42 GMT Message-Id: <202105170516.14H5GgTG071503@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Guangyuan Yang Subject: git: 48cffed67b - main - zh-cn: Update news items MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ygy X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 48cffed67be205d578432434cc205e9baeed7101 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 05:16:42 -0000 The branch main has been updated by ygy: URL: https://cgit.FreeBSD.org/doc/commit/?id=48cffed67be205d578432434cc205e9baeed7101 commit 48cffed67be205d578432434cc205e9baeed7101 Author: Guangyuan Yang AuthorDate: 2021-05-17 05:15:48 +0000 Commit: Guangyuan Yang CommitDate: 2021-05-17 05:15:48 +0000 zh-cn: Update news items MFen: 9f29b29e6a -> 606237d31e --- website/data/zh-cn/news/news.toml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/website/data/zh-cn/news/news.toml b/website/data/zh-cn/news/news.toml index fe8da42cca..c5c7929303 100644 --- a/website/data/zh-cn/news/news.toml +++ b/website/data/zh-cn/news/news.toml @@ -2,7 +2,16 @@ # $FreeBSD$ # Tracked File: website/data/en/news/news.toml -# Original Commit: 9f29b29e6ae3b2835b30146a49d933234988104d +# Original Commit: 606237d31e9dee2f1032d4f8d0c360e1aadb1f33 + +[[news]] +date = "2021-05-17" +description = "commit 权限提升: 杨光远 (doc, ports)" + +[[news]] +date = "2021-05-06" +title = "2021 年一季度开发进度报告" +description = "2021 年一季度开发进度报告 现已发布。" [[news]] date = "2021-04-29" From owner-dev-commits-doc-all@freebsd.org Mon May 17 10:19:42 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 59A77642EB1 for ; Mon, 17 May 2021 10:19:42 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkFVk20n1z3pTX for ; Mon, 17 May 2021 10:19:42 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1621246782; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zXBbd1bzwF7HMeMwbo/Rqmv6nCR5DP/4Qs/WOneVOkI=; b=uvVyA1Wf/MWHJsCtP6k0irI3bqXhBGK1bHh4Ym2Upe+8eiUdivIV9wCDHhBoToaY/8Ngct WSRuaMMC3X70mhmSaQg2SMU2KrO7ayBQ9m+1VITpTqJx+2jFXunP8nxT0VGnvjpHazszp/ mQ1JRc0CXxlDloAuR4KqNTeKdjAEDG8VUz1ASBMGcLGxzfgMI03O8JgOtWNR57ajLeITjX ys6voUduSn1KJmkaloiOF6BJfP4IXnxBLHhJmv5cPbixy32pkGBGpFdBWNBXYzCRyUUien Rf6MhDOhlS7XGwDvPHGpoAiUi+xX3IAQLtlWWVQtbhxNwASIJxeOpvFn2cLQzA== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 2EFB0BEB4; Mon, 17 May 2021 10:19:42 +0000 (UTC) Date: Mon, 17 May 2021 12:19:39 +0200 From: Daniel Ebdrup Jensen To: dev-commits-doc-all@FreeBSD.org Subject: Re: git: 3f63c74021 - main - Homogenize all PGP keys to follow the same syntax Message-ID: <20210517101939.d73svm4gzox2e4sn@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , dev-commits-doc-all@FreeBSD.org References: <202105162040.14GKeRfJ089059@gitrepo.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="apu4o6mnc4eu7z3o" Content-Disposition: inline In-Reply-To: <202105162040.14GKeRfJ089059@gitrepo.freebsd.org> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1621246782; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zXBbd1bzwF7HMeMwbo/Rqmv6nCR5DP/4Qs/WOneVOkI=; b=pAKKDshCVb2Lchblr6FUel40S9Pfl8WxeqfWrJ22Kid0pQ4Y9ygOaYK9uAk1sMDek1qf/v y/9+TEHAcxHvOV7J5AiP5gLe28VYTH7i7dx0JfXw6FYC3J2GN4HnVYQNWMgJERmvNDynVn 53X90t4uYv2G/oyrOxR3Q4IqQqDJ8X9uWhUmxDc7pygiU0tL1gcX9v7jdNRhu2CHsv/mC5 lnmmAYlq2scBCTKnTWU9c9jT8/XCpdwNnPbh1PXUrFAXHzA8q2qlDRe39Je9kDr2iffnP/ qqw3cXPoqZH1mKlU24NrRAtzUJfgEVD5W3DeyEtge0pdAasfmd/etYSgKhjyAg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1621246782; a=rsa-sha256; cv=none; b=tPRFNXumEL0aQCDCTdUi74Cm7k2Ua2T00sE3C2WwWq0hk1VZMcMShUKbItBitBuUznj1z9 nSJsz0jV40zbF1VYXRDrYXin5U44tCNQtg3KaRpswAs2rFEaGP6AVxE4Ix9VsC5MUGtZjx 2cEl063rWCU7HrOU9UyWko/hu/VvHUAy5T+FLSMKrotVX+Bw7AMThwPpyq6n9mLWfiJj6F sRPXJntgZr1u0wbmw1nu6xyNVneX6SF7NptG2JAKoJ30VeoxC5RcsYf6Q0FmpduLv3l/MI ELA5BDDvMjIIV+heqdgqop2ixTwUoL1T6lng4QS7eIbPl1BSdnDTNx8kQXjUzw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 10:19:42 -0000 --apu4o6mnc4eu7z3o Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Sun, May 16, 2021 at 08:40:27PM +0000, Sergio Carlavilla Delgado wrote: >The branch main has been updated by carlavilla: > >URL: https://cgit.FreeBSD.org/doc/commit/?id=3f63c740214b40d44e826da8c93ebbd1afac3b1e > >commit 3f63c740214b40d44e826da8c93ebbd1afac3b1e >Author: Sergio Carlavilla Delgado >AuthorDate: 2021-05-16 20:38:14 +0000 >Commit: Sergio Carlavilla Delgado >CommitDate: 2021-05-16 20:40:12 +0000 > > Homogenize all PGP keys to follow the same syntax [SNIP] Hi Sergio, I think this commit has broken the PGP keyring [1]. So far as I know, it's used by quite a lot of people, to keep their local PGP keyrings up-to-date with the project related keys. Yours, Daniel Ebdrup Jensen 1: https://docs.freebsd.org/pgpkeyring.txt --apu4o6mnc4eu7z3o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmCiQztfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87pOtwgAi1dCBNenyu+qu2+YkW2N8S3jJLGi28bNoUw1BSFnuSTL6pQoU3Z6+Ilr u5iwWVCc60bwFqB3zXFIepB10nzZ1il4OyvVODhFizaphe81+1OPmk39cld/k67Y yPbay8h7wlaxxML87O3hr33QFA/FKnHmqgnDzwQ2Di2YST5e2eYGlIFY1584zo7b WZ9FFGevZrombX5+OMalR9z3kYT+kfSU6UtAWAa6aezHck54MFTphkX46cZc7no7 MnVGWwgZ6ZUBYQI5KWDaUrWMdE5hEuib/9Wh7/2TI18BPFIRwefWbSusOFio6tz+ ok7RRVdKonnki3KoTfBXnd8fwfVW+g== =CXRR -----END PGP SIGNATURE----- --apu4o6mnc4eu7z3o-- From owner-dev-commits-doc-all@freebsd.org Mon May 17 10:23:56 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DAE926435E4 for ; Mon, 17 May 2021 10:23:56 +0000 (UTC) (envelope-from carlavilla@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkFbc5hkPz3qwX; Mon, 17 May 2021 10:23:56 +0000 (UTC) (envelope-from carlavilla@freebsd.org) Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: carlavilla) by smtp.freebsd.org (Postfix) with ESMTPSA id A4C91259A2; Mon, 17 May 2021 10:23:56 +0000 (UTC) (envelope-from carlavilla@freebsd.org) Received: by mail-ej1-f48.google.com with SMTP id et19so1316607ejc.4; Mon, 17 May 2021 03:23:56 -0700 (PDT) X-Gm-Message-State: AOAM531Um/7K/UZCKNuvZNNbCwlNgOuNtIAWrLL4Y42G0O3WhLFoHfSy /UWLIRdEG2u6pkBOGAnqWtOUqsyaJHxgu1X2w7w= X-Google-Smtp-Source: ABdhPJx0v7w0sFWZnD4AT57UD1tRzA1hoj31GHGPsqpBaVHAAagSh8sDAydxMJK2sgYiFrnPNakrUEVY8QBH7F48j3s= X-Received: by 2002:a17:906:2dcd:: with SMTP id h13mr16366464eji.41.1621247035578; Mon, 17 May 2021 03:23:55 -0700 (PDT) MIME-Version: 1.0 References: <202105162040.14GKeRfJ089059@gitrepo.freebsd.org> <20210517101939.d73svm4gzox2e4sn@nerd-thinkpad.local> In-Reply-To: <20210517101939.d73svm4gzox2e4sn@nerd-thinkpad.local> From: Sergio Carlavilla Date: Mon, 17 May 2021 12:23:41 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: git: 3f63c74021 - main - Homogenize all PGP keys to follow the same syntax To: Daniel Ebdrup Jensen , dev-commits-doc-all@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 10:23:56 -0000 On Mon, 17 May 2021 at 12:20, Daniel Ebdrup Jensen wrote: > On Sun, May 16, 2021 at 08:40:27PM +0000, Sergio Carlavilla Delgado wrote= : > >The branch main has been updated by carlavilla: > > > >URL: > https://cgit.FreeBSD.org/doc/commit/?id=3D3f63c740214b40d44e826da8c93ebbd= 1afac3b1e > > > >commit 3f63c740214b40d44e826da8c93ebbd1afac3b1e > >Author: Sergio Carlavilla Delgado > >AuthorDate: 2021-05-16 20:38:14 +0000 > >Commit: Sergio Carlavilla Delgado > >CommitDate: 2021-05-16 20:40:12 +0000 > > > > Homogenize all PGP keys to follow the same syntax > [SNIP] > > Hi Sergio, > > I think this commit has broken the PGP keyring [1]. > > So far as I know, it's used by quite a lot of people, to keep their > local PGP keyrings up-to-date with the project related keys. > > Yours, > Daniel Ebdrup Jensen > > 1: https://docs.freebsd.org/pgpkeyring.txt > Hi, I creates an script yes, but I don=E2=80=99t updated yet the document. What you=E2=80=99re seeing in this link it=E2=80=99s a redirect to the old = txt file. I=E2=80=99ll update the document this night. Thanks for the report. From owner-dev-commits-doc-all@freebsd.org Mon May 17 16:25:13 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8AD9164C92B for ; Mon, 17 May 2021 16:25:13 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkPcT3JKhz4V6l; Mon, 17 May 2021 16:25:13 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 59AB97170; Mon, 17 May 2021 16:25:13 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14HGPDeW066336; Mon, 17 May 2021 16:25:13 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14HGPDM0066335; Mon, 17 May 2021 16:25:13 GMT (envelope-from git) Date: Mon, 17 May 2021 16:25:13 GMT Message-Id: <202105171625.14HGPDM0066335@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Marc Fonvieille Subject: git: 81b1f9c9cb - main - en/books/design-44bsd: Fix imagedir path for both PDF and epub formats MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: blackend X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 81b1f9c9cbb532406521f68f75eeb8fe2dd216cd Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 16:25:13 -0000 The branch main has been updated by blackend: URL: https://cgit.FreeBSD.org/doc/commit/?id=81b1f9c9cbb532406521f68f75eeb8fe2dd216cd commit 81b1f9c9cbb532406521f68f75eeb8fe2dd216cd Author: Marc Fonvieille AuthorDate: 2021-05-17 16:24:11 +0000 Commit: Marc Fonvieille CommitDate: 2021-05-17 16:24:11 +0000 en/books/design-44bsd: Fix imagedir path for both PDF and epub formats --- documentation/content/en/books/design-44bsd/_index.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/documentation/content/en/books/design-44bsd/_index.adoc b/documentation/content/en/books/design-44bsd/_index.adoc index 61ba60b671..800409ae10 100644 --- a/documentation/content/en/books/design-44bsd/_index.adoc +++ b/documentation/content/en/books/design-44bsd/_index.adoc @@ -47,7 +47,7 @@ include::../../../../shared/releases.adoc[] include::../../../../shared/en/mailing-lists.adoc[] include::../../../../shared/en/teams.adoc[] include::../../../../shared/en/urls.adoc[] -:imagesdir: ../../../static/images/books/design-44bsd/ +:imagesdir: ../../../../static/images/books/design-44bsd/ endif::[] ifeval::["{backend}" == "epub3"] @@ -57,7 +57,7 @@ include::../../../../shared/releases.adoc[] include::../../../../shared/en/mailing-lists.adoc[] include::../../../../shared/en/teams.adoc[] include::../../../../shared/en/urls.adoc[] -:imagesdir: ../../../static/images/books/design-44bsd/ +:imagesdir: ../../../../static/images/books/design-44bsd/ endif::[] ''' From owner-dev-commits-doc-all@freebsd.org Mon May 17 16:34:31 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 41B5D64CA41 for ; Mon, 17 May 2021 16:34:31 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkPqC1RRzz4Wdl; Mon, 17 May 2021 16:34:31 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 18B3B75A8; Mon, 17 May 2021 16:34:31 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14HGYVN2079424; Mon, 17 May 2021 16:34:31 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14HGYUlD079423; Mon, 17 May 2021 16:34:30 GMT (envelope-from git) Date: Mon, 17 May 2021 16:34:30 GMT Message-Id: <202105171634.14HGYUlD079423@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Marc Fonvieille Subject: git: e32b7be5fe - main - images/books/design-44bsd/portsstatus.png: add a non-interlaced PNG To prevent the error: "PNG uses unsupported interlace method; install prawn-gmagick gem to add support" during PDF build. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: blackend X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: e32b7be5fe4298cb7e0552f6d9c22ea7ea748c1c Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 16:34:31 -0000 The branch main has been updated by blackend: URL: https://cgit.FreeBSD.org/doc/commit/?id=e32b7be5fe4298cb7e0552f6d9c22ea7ea748c1c commit e32b7be5fe4298cb7e0552f6d9c22ea7ea748c1c Author: Marc Fonvieille AuthorDate: 2021-05-17 16:31:52 +0000 Commit: Marc Fonvieille CommitDate: 2021-05-17 16:31:52 +0000 images/books/design-44bsd/portsstatus.png: add a non-interlaced PNG To prevent the error: "PNG uses unsupported interlace method; install prawn-gmagick gem to add support" during PDF build. --- .../static/images/books/dev-model/portsstatus.png | Bin 4647 -> 11895 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/documentation/static/images/books/dev-model/portsstatus.png b/documentation/static/images/books/dev-model/portsstatus.png index 8cd6c37138..542f24e232 100644 Binary files a/documentation/static/images/books/dev-model/portsstatus.png and b/documentation/static/images/books/dev-model/portsstatus.png differ From owner-dev-commits-doc-all@freebsd.org Mon May 17 16:56:39 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 231B064D992 for ; Mon, 17 May 2021 16:56:39 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkQJl0T27z4bRH; Mon, 17 May 2021 16:56:39 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E83C67C03; Mon, 17 May 2021 16:56:38 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14HGucGj006645; Mon, 17 May 2021 16:56:38 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14HGucf4006644; Mon, 17 May 2021 16:56:38 GMT (envelope-from git) Date: Mon, 17 May 2021 16:56:38 GMT Message-Id: <202105171656.14HGucf4006644@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Glen Barber Subject: git: e623fd791c - main - releng: comment the upcoming release section MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: gjb X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: e623fd791cdb178a1e0214289480c4baad61b7e5 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 16:56:39 -0000 The branch main has been updated by gjb: URL: https://cgit.FreeBSD.org/doc/commit/?id=e623fd791cdb178a1e0214289480c4baad61b7e5 commit e623fd791cdb178a1e0214289480c4baad61b7e5 Author: Glen Barber AuthorDate: 2021-05-17 16:55:26 +0000 Commit: Glen Barber CommitDate: 2021-05-17 16:55:26 +0000 releng: comment the upcoming release section The 12.3 and other upcoming releases have yet to be scheduled, pending discussion within various teams. Comment the section for now and update the commented date regarding the lack of a schedule. Spotted by: brd Sponsored by: Rubicon Communications, LLC ("Netgate") --- website/content/en/releng/_index.adoc | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/website/content/en/releng/_index.adoc b/website/content/en/releng/_index.adoc index 9a213a5597..111f52a92e 100644 --- a/website/content/en/releng/_index.adoc +++ b/website/content/en/releng/_index.adoc @@ -21,21 +21,23 @@ This page contains documentation about the FreeBSD release engineering process. General information about committing to -STABLE. //// +//// [[schedule]] == Upcoming Release Schedule Note: Release dates are approximate and may be subject to schedule slippage. - -//// -As of 2019-11-04, the next release has not yet been announced. //// +As of 2021-05-17, the next release has not yet been announced. + +//// [.tblbasic] [cols=",,",options="header",] |=== |Date |Event |Information |March 2021 |FreeBSD 13.0 |link:../releases/13.0R/schedule/[Target Schedule] |=== +//// [[freeze]] == Code-Freeze Status From owner-dev-commits-doc-all@freebsd.org Mon May 17 17:06:36 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4159D64DB35 for ; Mon, 17 May 2021 17:06:36 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FkQXD1LZHz4cdh; Mon, 17 May 2021 17:06:36 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 177327DA2; Mon, 17 May 2021 17:06:36 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14HH6ZDx021219; Mon, 17 May 2021 17:06:35 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14HH6Z0g021218; Mon, 17 May 2021 17:06:35 GMT (envelope-from git) Date: Mon, 17 May 2021 17:06:35 GMT Message-Id: <202105171706.14HH6Z0g021218@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Glen Barber Subject: git: d9e11c39f7 - main - releng: add the section header back after the previous commit MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: gjb X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: d9e11c39f75b553423268b75a4db26ebdd0c23e1 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 17:06:36 -0000 The branch main has been updated by gjb: URL: https://cgit.FreeBSD.org/doc/commit/?id=d9e11c39f75b553423268b75a4db26ebdd0c23e1 commit d9e11c39f75b553423268b75a4db26ebdd0c23e1 Author: Glen Barber AuthorDate: 2021-05-17 17:06:19 +0000 Commit: Glen Barber CommitDate: 2021-05-17 17:06:19 +0000 releng: add the section header back after the previous commit Sponsored by: Rubicon Communications, LLC ("Netgate") --- website/content/en/releng/_index.adoc | 2 -- 1 file changed, 2 deletions(-) diff --git a/website/content/en/releng/_index.adoc b/website/content/en/releng/_index.adoc index 111f52a92e..4dda8fff50 100644 --- a/website/content/en/releng/_index.adoc +++ b/website/content/en/releng/_index.adoc @@ -21,12 +21,10 @@ This page contains documentation about the FreeBSD release engineering process. General information about committing to -STABLE. //// -//// [[schedule]] == Upcoming Release Schedule Note: Release dates are approximate and may be subject to schedule slippage. -//// As of 2021-05-17, the next release has not yet been announced. From owner-dev-commits-doc-all@freebsd.org Tue May 18 02:57:32 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F32EC63B313 for ; Tue, 18 May 2021 02:57:31 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fkgf36Q25z3tjp; Tue, 18 May 2021 02:57:31 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BFA1B17A2C; Tue, 18 May 2021 02:57:31 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14I2vVf2005771; Tue, 18 May 2021 02:57:31 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14I2vVZk005770; Tue, 18 May 2021 02:57:31 GMT (envelope-from git) Date: Tue, 18 May 2021 02:57:31 GMT Message-Id: <202105180257.14I2vVZk005770@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Guangyuan Yang Subject: git: 4dfd464b71 - main - zh-cn: Fix a table misalignment in porters-handbook MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ygy X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 4dfd464b71c9192303ebaa477cd072784394db8f Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 02:57:32 -0000 The branch main has been updated by ygy: URL: https://cgit.FreeBSD.org/doc/commit/?id=4dfd464b71c9192303ebaa477cd072784394db8f commit 4dfd464b71c9192303ebaa477cd072784394db8f Author: Guangyuan Yang AuthorDate: 2021-05-18 02:52:09 +0000 Commit: Guangyuan Yang CommitDate: 2021-05-18 02:54:02 +0000 zh-cn: Fix a table misalignment in porters-handbook Reported by: xxxxxliil --- documentation/content/zh-cn/books/porters-handbook/makefile/chapter.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/documentation/content/zh-cn/books/porters-handbook/makefile/chapter.adoc b/documentation/content/zh-cn/books/porters-handbook/makefile/chapter.adoc index 79ae2463bd..53c4a17bfd 100644 --- a/documentation/content/zh-cn/books/porters-handbook/makefile/chapter.adoc +++ b/documentation/content/zh-cn/books/porters-handbook/makefile/chapter.adoc @@ -536,6 +536,7 @@ _-compiled.specifics_ 部分应该通过 `PKGNAMESUFFIX` 变量来设置。 |[.filename]#ports-mgmt# |用于管理、 安装和开发 FreeBSD ports 和预编译包的 port。 +| |[.filename]#portuguese# |葡萄牙语语言支持。 From owner-dev-commits-doc-all@freebsd.org Tue May 18 04:02:46 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 24DA563D3DD for ; Tue, 18 May 2021 04:02:46 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fkj5L0b6bz4Zvg; Tue, 18 May 2021 04:02:46 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id F0B0318BE4; Tue, 18 May 2021 04:02:45 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14I42jnd099689; Tue, 18 May 2021 04:02:45 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14I42jjW099688; Tue, 18 May 2021 04:02:45 GMT (envelope-from git) Date: Tue, 18 May 2021 04:02:45 GMT Message-Id: <202105180402.14I42jjW099688@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Guangyuan Yang Subject: git: 369bb8f3ad - main - de: Fix a table misalignment in porters-handbook MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ygy X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 369bb8f3ad7fd17fbddfb7be534f2d6acfce262f Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 04:02:46 -0000 The branch main has been updated by ygy: URL: https://cgit.FreeBSD.org/doc/commit/?id=369bb8f3ad7fd17fbddfb7be534f2d6acfce262f commit 369bb8f3ad7fd17fbddfb7be534f2d6acfce262f Author: Guangyuan Yang AuthorDate: 2021-05-18 04:02:21 +0000 Commit: Guangyuan Yang CommitDate: 2021-05-18 04:02:21 +0000 de: Fix a table misalignment in porters-handbook Reported by: xxxxxliil --- documentation/content/de/books/porters-handbook/makefile/chapter.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/documentation/content/de/books/porters-handbook/makefile/chapter.adoc b/documentation/content/de/books/porters-handbook/makefile/chapter.adoc index ed20f1af55..31bcd2eafc 100644 --- a/documentation/content/de/books/porters-handbook/makefile/chapter.adoc +++ b/documentation/content/de/books/porters-handbook/makefile/chapter.adoc @@ -529,6 +529,7 @@ Für nicht-virtuelle Kategorien finden Sie eine einzeilige Beschreibung in der V |[.filename]#ports-mgmt# |Hilfsprogramme für das Installieren und Entwickeln von FreeBSD Ports und Paketen. +| |[.filename]#portuguese# |Portugiesische Sprachunterstützung. From owner-dev-commits-doc-all@freebsd.org Tue May 18 04:06:25 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8DF6263D899 for ; Tue, 18 May 2021 04:06:25 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fkj9Y3fTzz4bhS; Tue, 18 May 2021 04:06:25 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 659EA189C9; Tue, 18 May 2021 04:06:25 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14I46Puv000143; Tue, 18 May 2021 04:06:25 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14I46PMj000142; Tue, 18 May 2021 04:06:25 GMT (envelope-from git) Date: Tue, 18 May 2021 04:06:25 GMT Message-Id: <202105180406.14I46PMj000142@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Guangyuan Yang Subject: git: 30e953b67b - main - zh-tw: Fix a table misalignment in porters-handbook MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ygy X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 30e953b67b2605c8a572774785e9bcac245745f2 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 04:06:25 -0000 The branch main has been updated by ygy: URL: https://cgit.FreeBSD.org/doc/commit/?id=30e953b67b2605c8a572774785e9bcac245745f2 commit 30e953b67b2605c8a572774785e9bcac245745f2 Author: Guangyuan Yang AuthorDate: 2021-05-18 04:05:06 +0000 Commit: Guangyuan Yang CommitDate: 2021-05-18 04:05:06 +0000 zh-tw: Fix a table misalignment in porters-handbook Reported by: xxxxxliil --- .../content/zh-tw/books/porters-handbook/makefiles/chapter.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/documentation/content/zh-tw/books/porters-handbook/makefiles/chapter.adoc b/documentation/content/zh-tw/books/porters-handbook/makefiles/chapter.adoc index 1ef7a4d813..e8f473d59a 100644 --- a/documentation/content/zh-tw/books/porters-handbook/makefiles/chapter.adoc +++ b/documentation/content/zh-tw/books/porters-handbook/makefiles/chapter.adoc @@ -816,6 +816,7 @@ For non-virtual categories, there is a one-line description in `COMMENT` in that |[.filename]#ports-mgmt# |Ports for managing, installing and developing FreeBSD ports and packages. +| |[.filename]#portuguese# |Portuguese language support. From owner-dev-commits-doc-all@freebsd.org Tue May 18 11:07:45 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4A482649224 for ; Tue, 18 May 2021 11:07:45 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FktWj1jdWz4vmg; Tue, 18 May 2021 11:07:45 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 231771E5AC; Tue, 18 May 2021 11:07:45 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14IB7j5e057974; Tue, 18 May 2021 11:07:45 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14IB7j7j057973; Tue, 18 May 2021 11:07:45 GMT (envelope-from git) Date: Tue, 18 May 2021 11:07:45 GMT Message-Id: <202105181107.14IB7j7j057973@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Ryusuke SUZUKI Subject: git: 50357aac15 - main - 2bbfb011a2 -> 606237d31e MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ryusuke X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 50357aac15f5f88d3ac7ba9ab1c9acb3382906d9 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 11:07:45 -0000 The branch main has been updated by ryusuke: URL: https://cgit.FreeBSD.org/doc/commit/?id=50357aac15f5f88d3ac7ba9ab1c9acb3382906d9 commit 50357aac15f5f88d3ac7ba9ab1c9acb3382906d9 Author: Ryusuke SUZUKI AuthorDate: 2021-05-18 11:07:27 +0000 Commit: Ryusuke SUZUKI CommitDate: 2021-05-18 11:07:27 +0000 2bbfb011a2 -> 606237d31e --- website/data/ja/news/news.toml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/website/data/ja/news/news.toml b/website/data/ja/news/news.toml index 87a09559d4..46d5aa075b 100644 --- a/website/data/ja/news/news.toml +++ b/website/data/ja/news/news.toml @@ -1,5 +1,9 @@ # Sort news by year, month and day +[[news]] +date = "2021-05-17" +description = "コミット権限の拡大: Guangyuan Yang (doc, ports)" + [[news]] date = "2021-05-06" title = "開発進捗レポート (2021 年 1 月 - 3 月) 公開" From owner-dev-commits-doc-all@freebsd.org Tue May 18 11:17:16 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 119CD6497AB for ; Tue, 18 May 2021 11:17:16 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fktkg6rG6z3DVN; Tue, 18 May 2021 11:17:15 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D306E1E69E; Tue, 18 May 2021 11:17:15 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14IBHFks070845; Tue, 18 May 2021 11:17:15 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14IBHF8d070844; Tue, 18 May 2021 11:17:15 GMT (envelope-from git) Date: Tue, 18 May 2021 11:17:15 GMT Message-Id: <202105181117.14IBHF8d070844@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Marc Fonvieille Subject: git: cca9f9bba5 - main - books/porters-handbook/: fix some rendering. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: blackend X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: cca9f9bba56dd108030cff2d5b8fa4fce1406cb6 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 11:17:16 -0000 The branch main has been updated by blackend: URL: https://cgit.FreeBSD.org/doc/commit/?id=cca9f9bba56dd108030cff2d5b8fa4fce1406cb6 commit cca9f9bba56dd108030cff2d5b8fa4fce1406cb6 Author: Marc Fonvieille AuthorDate: 2021-05-17 17:11:50 +0000 Commit: Marc Fonvieille CommitDate: 2021-05-18 11:15:49 +0000 books/porters-handbook/: fix some rendering. --- .../content/en/books/porters-handbook/makefiles/_index.adoc | 5 ----- 1 file changed, 5 deletions(-) diff --git a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc index db5b8a9a03..4412e0d22c 100644 --- a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc +++ b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc @@ -1768,15 +1768,10 @@ GL_COMMIT= 9c1669ce60c3f4f5eb43df874d7314483fb3f8a6 It will have `MASTER_SITES` set to "`https://gitlab.example.com`" and `WRKSRC` to `${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6`. [TIP] -**** - `20170906` is the date of the commit referenced in `GL_COMMIT`, not the date the [.filename]#Makefile# is edited, or the date the commit to the FreeBSD ports tree is made. -**** [NOTE] -**** ``GL_SITE``'s protocol, port and webroot can all be modified in the same variable. -**** ==== From owner-dev-commits-doc-all@freebsd.org Tue May 18 15:01:41 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3AD7564F2BE for ; Tue, 18 May 2021 15:01:41 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fkzjd1G6sz4h5p; Tue, 18 May 2021 15:01:41 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 1464D21463; Tue, 18 May 2021 15:01:41 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14IF1ff3076444; Tue, 18 May 2021 15:01:41 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14IF1f7k076443; Tue, 18 May 2021 15:01:41 GMT (envelope-from git) Date: Tue, 18 May 2021 15:01:41 GMT Message-Id: <202105181501.14IF1f7k076443@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Wolfram Schneider Subject: git: 585385f822 - main - the FreeBSD location for perl is /usr/local/bin/perl MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: wosch X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 585385f822f78f3fc9a3b106044035a4f03fa7f2 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 15:01:41 -0000 The branch main has been updated by wosch: URL: https://cgit.FreeBSD.org/doc/commit/?id=585385f822f78f3fc9a3b106044035a4f03fa7f2 commit 585385f822f78f3fc9a3b106044035a4f03fa7f2 Author: Wolfram Schneider AuthorDate: 2021-05-18 15:00:31 +0000 Commit: Wolfram Schneider CommitDate: 2021-05-18 15:00:31 +0000 the FreeBSD location for perl is /usr/local/bin/perl --- website/content/en/cgi/man.cgi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/content/en/cgi/man.cgi b/website/content/en/cgi/man.cgi index 20bf377262..edeb46dfeb 100755 --- a/website/content/en/cgi/man.cgi +++ b/website/content/en/cgi/man.cgi @@ -1,4 +1,4 @@ -#!/usr/bin/perl -T +#!/usr/local/bin/perl -T # # Copyright (c) 1996-2020 Wolfram Schneider # All rights reserved. From owner-dev-commits-doc-all@freebsd.org Wed May 19 12:07:29 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 32D7463FFDE for ; Wed, 19 May 2021 12:07:29 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FlWp90rrMz3HmQ; Wed, 19 May 2021 12:07:29 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0686012925; Wed, 19 May 2021 12:07:29 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14JC7SI1055111; Wed, 19 May 2021 12:07:28 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14JC7SJk055110; Wed, 19 May 2021 12:07:28 GMT (envelope-from git) Date: Wed, 19 May 2021 12:07:28 GMT Message-Id: <202105191207.14JC7SJk055110@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Ryusuke SUZUKI Subject: git: 57c5ed0e5c - main - a640b8413e -> eab1c5d1f6, 989d921f5d -> bfb255f05f MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ryusuke X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 57c5ed0e5c4e2612ed923a0d88f389ab4ab8faef Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 12:07:29 -0000 The branch main has been updated by ryusuke: URL: https://cgit.FreeBSD.org/doc/commit/?id=57c5ed0e5c4e2612ed923a0d88f389ab4ab8faef commit 57c5ed0e5c4e2612ed923a0d88f389ab4ab8faef Author: Ryusuke SUZUKI AuthorDate: 2021-05-19 12:07:12 +0000 Commit: Ryusuke SUZUKI CommitDate: 2021-05-19 12:07:12 +0000 a640b8413e -> eab1c5d1f6, 989d921f5d -> bfb255f05f --- documentation/content/ja/books/handbook/multimedia/_index.adoc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/documentation/content/ja/books/handbook/multimedia/_index.adoc b/documentation/content/ja/books/handbook/multimedia/_index.adoc index 572015fb00..0f1d17fc5d 100644 --- a/documentation/content/ja/books/handbook/multimedia/_index.adoc +++ b/documentation/content/ja/books/handbook/multimedia/_index.adoc @@ -3,6 +3,8 @@ title: 第7章 マルチメディア part: パートII. 日々の生活 prev: books/handbook/desktop next: books/handbook/kernelconfig +description: FreeBSD は数多くの種類のサウンドカードに対応しており、FreeBSD システムで原音に忠実な出力を楽しむことができます。 +tags: ["multimedia", "sound card", "MP3", "MythTV", "scanner", "SANE"] --- [[multimedia]] @@ -221,7 +223,7 @@ package:audio/virtual_oss[] を使うには、 カーネルに `cuse` が読み [source,shell] .... -# sysrc -f /boot/loader.conf cuse_load=yes +# echo 'cuse_load=yes' >> /boot/loader.conf .... package:audio/virtual_oss[] でヘッドホンをサウンドシンクとして使うには、 Blueooth オーディオデバイスに接続後、 仮想デバイスを作成する必要があります。 From owner-dev-commits-doc-all@freebsd.org Wed May 19 16:23:33 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8063A645D7A for ; Wed, 19 May 2021 16:23:33 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FldTd2z6Vz3FNX; Wed, 19 May 2021 16:23:33 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4D18D16019; Wed, 19 May 2021 16:23:33 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14JGNXAQ001578; Wed, 19 May 2021 16:23:33 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14JGNX1O001577; Wed, 19 May 2021 16:23:33 GMT (envelope-from git) Date: Wed, 19 May 2021 16:23:33 GMT Message-Id: <202105191623.14JGNX1O001577@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Marc Fonvieille Subject: git: 9a65351f44 - main - en/articles/*: Set includes paths according to the backend used for the build. This fixes the PDF versions. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: blackend X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 9a65351f44af15851938802714d383df539bf4c8 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 16:23:33 -0000 The branch main has been updated by blackend: URL: https://cgit.FreeBSD.org/doc/commit/?id=9a65351f44af15851938802714d383df539bf4c8 commit 9a65351f44af15851938802714d383df539bf4c8 Author: Marc Fonvieille AuthorDate: 2021-05-19 16:14:49 +0000 Commit: Marc Fonvieille CommitDate: 2021-05-19 16:22:44 +0000 en/articles/*: Set includes paths according to the backend used for the build. This fixes the PDF versions. --- .../en/articles/building-products/_index.adoc | 10 ++++++-- .../en/articles/committers-guide/_index.adoc | 16 ++++++++++++ .../content/en/articles/contributing/_index.adoc | 12 +++++++++ .../content/en/articles/contributors/_index.adoc | 12 +++++++++ .../en/articles/filtering-bridges/_index.adoc | 10 ++++++++ .../en/articles/freebsd-questions/_index.adoc | 12 +++++++++ .../en/articles/freebsd-update-server/_index.adoc | 12 +++++++++ .../content/en/articles/geom-class/_index.adoc | 10 ++++++++ .../en/articles/gjournal-desktop/_index.adoc | 14 ++++++++++ documentation/content/en/articles/hubs/_index.adoc | 14 ++++++++++ .../content/en/articles/ipsec-must/_index.adoc | 10 ++++++++ .../content/en/articles/leap-seconds/_index.adoc | 10 ++++++++ .../en/articles/linux-emulation/_index.adoc | 10 ++++++++ .../content/en/articles/linux-users/_index.adoc | 10 ++++++++ .../en/articles/mailing-list-faq/_index.adoc | 14 ++++++++++ .../content/en/articles/nanobsd/_index.adoc | 12 +++++++++ documentation/content/en/articles/pam/_index.adoc | 30 ++++++++++++++++++++++ .../content/en/articles/pgpkeys/_index.adoc | 12 +++++++++ .../en/articles/port-mentor-guidelines/_index.adoc | 10 ++++++++ .../content/en/articles/pr-guidelines/_index.adoc | 12 +++++++++ .../en/articles/problem-reports/_index.adoc | 12 +++++++++ .../content/en/articles/rc-scripting/_index.adoc | 10 ++++++++ .../content/en/articles/releng/_index.adoc | 14 ++++++++-- .../content/en/articles/remote-install/_index.adoc | 12 +++++++++ .../content/en/articles/serial-uart/_index.adoc | 13 ++++++++++ .../content/en/articles/vinum/_index.adoc | 3 ++- 26 files changed, 311 insertions(+), 5 deletions(-) diff --git a/documentation/content/en/articles/building-products/_index.adoc b/documentation/content/en/articles/building-products/_index.adoc index 8998e863f0..cf50b55302 100644 --- a/documentation/content/en/articles/building-products/_index.adoc +++ b/documentation/content/en/articles/building-products/_index.adoc @@ -20,19 +20,25 @@ tags: ["FreeBSD", "FreeBSD as base for your product"] :source-highlighter: rouge :experimental: + +ifeval::["{backend}" == "html5"] include::shared/releases.adoc[] include::shared/en/mailing-lists.adoc[] include::shared/en/urls.adoc[] - -ifeval::["{backend}" == "html5"] :imagesdir: ../../../images/articles/building-products/ endif::[] ifeval::["{backend}" == "pdf"] +include::../../../../shared/releases.adoc[] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] :imagesdir: ../../../../static/images/articles/building-products/ endif::[] ifeval::["{backend}" == "epub3"] +include::../../../../shared/releases.adoc[] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] :imagesdir: ../../../../static/images/articles/building-products/ endif::[] diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc index 54cf8bc241..e1ea6a26d6 100644 --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -19,10 +19,26 @@ tags: ["FreeBSD Committer's Guide", "Guide", "Community"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] include::shared/en/teams.adoc[lines=16..-1] include::shared/en/mailing-lists.adoc[] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/teams.adoc[lines=16..-1] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/teams.adoc[lines=16..-1] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/contributing/_index.adoc b/documentation/content/en/articles/contributing/_index.adoc index 280ae8cb6a..2f4c6e20a5 100644 --- a/documentation/content/en/articles/contributing/_index.adoc +++ b/documentation/content/en/articles/contributing/_index.adoc @@ -20,8 +20,20 @@ tags: ["Contributing", "FreeBSD", "Non-Programmer Tasks", "Programmer Tasks"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/en/mailing-lists.adoc[] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/contributors/_index.adoc b/documentation/content/en/articles/contributors/_index.adoc index 7921971d75..a3f7fd0652 100644 --- a/documentation/content/en/articles/contributors/_index.adoc +++ b/documentation/content/en/articles/contributors/_index.adoc @@ -15,8 +15,20 @@ tags: ["Contributors", "FreeBSD", "individuals", "organizations"] :experimental: :sectnumlevels: 6 +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/filtering-bridges/_index.adoc b/documentation/content/en/articles/filtering-bridges/_index.adoc index f8033f08f4..c729c8f934 100644 --- a/documentation/content/en/articles/filtering-bridges/_index.adoc +++ b/documentation/content/en/articles/filtering-bridges/_index.adoc @@ -18,7 +18,17 @@ tags: ["network", "filtering", "bridges", "FreeBSD"] :experimental: :sectnumlevels: 6 +ifeval::["{backend}" == "html5"] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/freebsd-questions/_index.adoc b/documentation/content/en/articles/freebsd-questions/_index.adoc index d8c5f3b7bf..1edcd2ecf0 100644 --- a/documentation/content/en/articles/freebsd-questions/_index.adoc +++ b/documentation/content/en/articles/freebsd-questions/_index.adoc @@ -18,8 +18,20 @@ tags: ["questions", "mailing", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/en/mailing-lists.adoc[] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/freebsd-update-server/_index.adoc b/documentation/content/en/articles/freebsd-update-server/_index.adoc index 90a3702717..dab8525828 100644 --- a/documentation/content/en/articles/freebsd-update-server/_index.adoc +++ b/documentation/content/en/articles/freebsd-update-server/_index.adoc @@ -19,8 +19,20 @@ tags: ["FreeBSD", "Update", "Server", "internal"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/geom-class/_index.adoc b/documentation/content/en/articles/geom-class/_index.adoc index 77cff44e57..3d836c51f3 100644 --- a/documentation/content/en/articles/geom-class/_index.adoc +++ b/documentation/content/en/articles/geom-class/_index.adoc @@ -18,7 +18,17 @@ tags: ["GEOM", "kernel", "modules", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/gjournal-desktop/_index.adoc b/documentation/content/en/articles/gjournal-desktop/_index.adoc index be46c41b91..c39fa2d3a1 100644 --- a/documentation/content/en/articles/gjournal-desktop/_index.adoc +++ b/documentation/content/en/articles/gjournal-desktop/_index.adoc @@ -18,9 +18,23 @@ tags: ["UFS", "Journaling" , "Desktop", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] include::shared/en/mailing-lists.adoc[] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] ifeval::["{backend}" == "html5"] :imagesdir: ../../../images/articles/gjournal-desktop/ diff --git a/documentation/content/en/articles/hubs/_index.adoc b/documentation/content/en/articles/hubs/_index.adoc index e79fdf9ba2..fa28584e38 100644 --- a/documentation/content/en/articles/hubs/_index.adoc +++ b/documentation/content/en/articles/hubs/_index.adoc @@ -24,9 +24,23 @@ tags: ["Mirroring", "FreeBSD", "Hub"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/en/mailing-lists.adoc[] include::shared/en/urls.adoc[] include::shared/releases.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +include::../../../../shared/releases.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +include::../../../../shared/releases.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/ipsec-must/_index.adoc b/documentation/content/en/articles/ipsec-must/_index.adoc index 816eccce4f..7e2cbef7db 100644 --- a/documentation/content/en/articles/ipsec-must/_index.adoc +++ b/documentation/content/en/articles/ipsec-must/_index.adoc @@ -18,7 +18,17 @@ tags: ["IPsec", "verification", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/leap-seconds/_index.adoc b/documentation/content/en/articles/leap-seconds/_index.adoc index b2909b28cc..1a2ac552bb 100644 --- a/documentation/content/en/articles/leap-seconds/_index.adoc +++ b/documentation/content/en/articles/leap-seconds/_index.adoc @@ -14,7 +14,17 @@ tags: ["Leap Seconds", "Support", "Verification", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/en/urls.adoc[] +endif::[] ''' diff --git a/documentation/content/en/articles/linux-emulation/_index.adoc b/documentation/content/en/articles/linux-emulation/_index.adoc index 449654c254..6512d55b80 100644 --- a/documentation/content/en/articles/linux-emulation/_index.adoc +++ b/documentation/content/en/articles/linux-emulation/_index.adoc @@ -18,7 +18,17 @@ tags: ["Emulation", "Linuxulator", "kernel", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/linux-users/_index.adoc b/documentation/content/en/articles/linux-users/_index.adoc index 7bfa62206f..aa2e76682a 100644 --- a/documentation/content/en/articles/linux-users/_index.adoc +++ b/documentation/content/en/articles/linux-users/_index.adoc @@ -18,7 +18,17 @@ tags: ["Quickstart", "guide", "Linux", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/mailing-list-faq/_index.adoc b/documentation/content/en/articles/mailing-list-faq/_index.adoc index 23f86fcd23..5f3322f29f 100644 --- a/documentation/content/en/articles/mailing-list-faq/_index.adoc +++ b/documentation/content/en/articles/mailing-list-faq/_index.adoc @@ -17,9 +17,23 @@ tags: ["FAQ", "Mailing Lists", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] include::shared/en/mailing-lists.adoc[] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/nanobsd/_index.adoc b/documentation/content/en/articles/nanobsd/_index.adoc index f7ca27afa6..b819e0ee10 100644 --- a/documentation/content/en/articles/nanobsd/_index.adoc +++ b/documentation/content/en/articles/nanobsd/_index.adoc @@ -18,8 +18,20 @@ tags: ["nanobsd", "guide", "embedded", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/pam/_index.adoc b/documentation/content/en/articles/pam/_index.adoc index e425d941a1..bbea5aa3d2 100644 --- a/documentation/content/en/articles/pam/_index.adoc +++ b/documentation/content/en/articles/pam/_index.adoc @@ -584,7 +584,17 @@ the one presented in <> is a good starting point, but should no [.programlisting] .... +ifeval::["{backend}" == "html5"] include::static/source/articles/pam/su.c[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../static/source/articles/pam/su.c[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../static/source/articles/pam/su.c[] +endif::[] .... :sectnums!: @@ -598,7 +608,17 @@ It should build and run with most PAM implementations, but takes advantage of Op [.programlisting] .... +ifeval::["{backend}" == "html5"] include::static/source/articles/pam/pam_unix.c[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../static/source/articles/pam/pam_unix.c[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../static/source/articles/pam/pam_unix.c[] +endif::[] .... :sectnums!: @@ -613,7 +633,17 @@ Even if you are not using OpenPAM, feel free to download the source code and ada [.programlisting] .... +ifeval::["{backend}" == "html5"] include::static/source/articles/pam/converse.c[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../static/source/articles/pam/converse.c[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../static/source/articles/pam/converse.c[] +endif::[] .... :sectnums!: diff --git a/documentation/content/en/articles/pgpkeys/_index.adoc b/documentation/content/en/articles/pgpkeys/_index.adoc index 4921806f61..d7d7698fb1 100644 --- a/documentation/content/en/articles/pgpkeys/_index.adoc +++ b/documentation/content/en/articles/pgpkeys/_index.adoc @@ -14,8 +14,20 @@ tags: ["OpenPGP", "Developers", "Officers", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] include::shared/en/teams.adoc[lines=16..-1] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/teams.adoc[lines=16..-1] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/teams.adoc[lines=16..-1] +endif::[] ''' diff --git a/documentation/content/en/articles/port-mentor-guidelines/_index.adoc b/documentation/content/en/articles/port-mentor-guidelines/_index.adoc index aa414b7db9..0d1c2b72b1 100644 --- a/documentation/content/en/articles/port-mentor-guidelines/_index.adoc +++ b/documentation/content/en/articles/port-mentor-guidelines/_index.adoc @@ -17,7 +17,17 @@ tags: ["port", "mentor", "mentee", "guidelines", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/en/urls.adoc[] +endif::[] ''' diff --git a/documentation/content/en/articles/pr-guidelines/_index.adoc b/documentation/content/en/articles/pr-guidelines/_index.adoc index c82135ef00..787caf1a3e 100644 --- a/documentation/content/en/articles/pr-guidelines/_index.adoc +++ b/documentation/content/en/articles/pr-guidelines/_index.adoc @@ -18,8 +18,20 @@ tags: ["PR", "guideline", "bugs", "maintenance", "BugZilla", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/en/mailing-lists.adoc[] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/problem-reports/_index.adoc b/documentation/content/en/articles/problem-reports/_index.adoc index c474d7786f..d92d95945e 100644 --- a/documentation/content/en/articles/problem-reports/_index.adoc +++ b/documentation/content/en/articles/problem-reports/_index.adoc @@ -18,8 +18,20 @@ tags: ["formulate", "submit", "FreeBSD", "PR"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/en/mailing-lists.adoc[] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/rc-scripting/_index.adoc b/documentation/content/en/articles/rc-scripting/_index.adoc index 35ee3f3f30..4d12be53b5 100644 --- a/documentation/content/en/articles/rc-scripting/_index.adoc +++ b/documentation/content/en/articles/rc-scripting/_index.adoc @@ -19,7 +19,17 @@ tags: ["rc.d", "scripting", "guide", "tutorial", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/releng/_index.adoc b/documentation/content/en/articles/releng/_index.adoc index 4d53c368e4..8ed11ec631 100644 --- a/documentation/content/en/articles/releng/_index.adoc +++ b/documentation/content/en/articles/releng/_index.adoc @@ -20,21 +20,31 @@ tags: ["Release", "Engineering", "Historical", "FreeBSD"] :experimental: :xrefstyle: full + +ifeval::["{backend}" == "html5"] include::shared/releases.adoc[] include::shared/authors.adoc[] include::shared/en/teams.adoc[lines=16..-1] include::shared/en/mailing-lists.adoc[] include::shared/en/urls.adoc[] - -ifeval::["{backend}" == "html5"] :imagesdir: ../../../images/articles/releng/ endif::[] ifeval::["{backend}" == "pdf"] +include::../../../../shared/releases.adoc[] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/teams.adoc[lines=16..-1] +include::../../../../shared/en/mailing-lists.adoc[] +include::../../../../shared/en/urls.adoc[] :imagesdir: ../../../../static/images/articles/releng/ endif::[] ifeval::["{backend}" == "epub3"] +include::shared/releases.adoc[] +include::shared/authors.adoc[] +include::shared/en/teams.adoc[lines=16..-1] +include::shared/en/mailing-lists.adoc[] +include::shared/en/urls.adoc[] :imagesdir: ../../../../static/images/articles/releng/ endif::[] diff --git a/documentation/content/en/articles/remote-install/_index.adoc b/documentation/content/en/articles/remote-install/_index.adoc index 8baa70f1ab..5d6a8b5e4a 100644 --- a/documentation/content/en/articles/remote-install/_index.adoc +++ b/documentation/content/en/articles/remote-install/_index.adoc @@ -19,8 +19,20 @@ tags: ["Remote", "Installation", "FreeBSD"] :source-highlighter: rouge :experimental: +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/serial-uart/_index.adoc b/documentation/content/en/articles/serial-uart/_index.adoc index 6e4f646700..084f4493d6 100644 --- a/documentation/content/en/articles/serial-uart/_index.adoc +++ b/documentation/content/en/articles/serial-uart/_index.adoc @@ -18,8 +18,21 @@ tags: ["Serial", "hardware", "UART", "Tutorial", "FreeBSD"] :source-highlighter: rouge :experimental: + +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] include::shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/en/urls.adoc[] +endif::[] [.abstract-title] Abstract diff --git a/documentation/content/en/articles/vinum/_index.adoc b/documentation/content/en/articles/vinum/_index.adoc index d6a662b7c4..6b2db7cf8f 100644 --- a/documentation/content/en/articles/vinum/_index.adoc +++ b/documentation/content/en/articles/vinum/_index.adoc @@ -16,13 +16,14 @@ tags: ["vinum", "Volume Manager", "FreeBSD"] :source-highlighter: rouge :experimental: -include::shared/en/urls.adoc[] ifeval::["{backend}" == "html5"] +include::shared/en/urls.adoc[] :imagesdir: ../../../images/articles/vinum/ endif::[] ifeval::["{backend}" == "pdf"] +include::../../../../shared/en/urls.adoc[] :imagesdir: ../../../../static/images/articles/vinum/ endif::[] From owner-dev-commits-doc-all@freebsd.org Wed May 19 16:35:28 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0FA2F646559 for ; Wed, 19 May 2021 16:35:28 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FldlM72Wxz3L51; Wed, 19 May 2021 16:35:27 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D605115DFF; Wed, 19 May 2021 16:35:27 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14JGZRnD014773; Wed, 19 May 2021 16:35:27 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14JGZR6f014772; Wed, 19 May 2021 16:35:27 GMT (envelope-from git) Date: Wed, 19 May 2021 16:35:27 GMT Message-Id: <202105191635.14JGZR6f014772@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Ceri Davies Subject: git: 67939f99b1 - main - Correct marginally incorrect markup. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ceri X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 67939f99b13a98f42603325996f8577716194b90 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 16:35:28 -0000 The branch main has been updated by ceri: URL: https://cgit.FreeBSD.org/doc/commit/?id=67939f99b13a98f42603325996f8577716194b90 commit 67939f99b13a98f42603325996f8577716194b90 Author: Ceri Davies AuthorDate: 2021-05-19 16:14:05 +0000 Commit: Ceri Davies CommitDate: 2021-05-19 16:35:07 +0000 Correct marginally incorrect markup. The markup previously used was not causing issues with a HTML build, but was generating errors when trying to build other formats (specifically PDF) as the intermediate output was not parsable by the asciidoctor backends. Approved by: blackend (mentor) --- documentation/content/en/books/porters-handbook/makefiles/_index.adoc | 2 +- documentation/content/en/books/porters-handbook/special/_index.adoc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc index 4412e0d22c..0a85939535 100644 --- a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc +++ b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc @@ -1765,7 +1765,7 @@ GL_PROJECT= bar GL_COMMIT= 9c1669ce60c3f4f5eb43df874d7314483fb3f8a6 .... -It will have `MASTER_SITES` set to "`https://gitlab.example.com`" and `WRKSRC` to `${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6`. +It will have `MASTER_SITES` set to `"https://gitlab.example.com"` and `WRKSRC` to `${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6`. [TIP] `20170906` is the date of the commit referenced in `GL_COMMIT`, not the date the [.filename]#Makefile# is edited, or the date the commit to the FreeBSD ports tree is made. diff --git a/documentation/content/en/books/porters-handbook/special/_index.adoc b/documentation/content/en/books/porters-handbook/special/_index.adoc index 0d2c570408..0e3951e091 100644 --- a/documentation/content/en/books/porters-handbook/special/_index.adoc +++ b/documentation/content/en/books/porters-handbook/special/_index.adoc @@ -4224,7 +4224,7 @@ in their [.filename]#rc.conf.local#, and a variable substitution using ":=" woul [IMPORTANT] ==== -Ports _must not_ start and stop their services when installing and deinstalling. Do not abuse the [.filename]#plist# keywords described in crossref:plist[plist-keywords-base-exec,`@preexec command,@postexec command,@preunexec command,@postunexec command`] by running commands that modify the currently running system, including starting or stopping services. +Ports _must not_ start and stop their services when installing and deinstalling. Do not abuse the [.filename]#plist# keywords described in crossref:plist[plist-keywords-base-exec, "the @preexec command,@postexec command,@preunexec command,@postunexec command section"] by running commands that modify the currently running system, including starting or stopping services. ==== [[rc-scripts-checklist]] From owner-dev-commits-doc-all@freebsd.org Thu May 20 06:00:45 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2A8AA635AD9 for ; Thu, 20 May 2021 06:00:45 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FlzcX71Tnz3pSN; Thu, 20 May 2021 06:00:44 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D0E2C20B50; Thu, 20 May 2021 06:00:44 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14K60ijb088915; Thu, 20 May 2021 06:00:44 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14K60iuV088914; Thu, 20 May 2021 06:00:44 GMT (envelope-from git) Date: Thu, 20 May 2021 06:00:44 GMT Message-Id: <202105200600.14K60iuV088914@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Philip Paeps Subject: git: 169ced0379 - main - Regenerate ssh-keys.asc MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: philip X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 169ced03796970dda19d6d52c85850f41d7d558a Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2021 06:00:45 -0000 The branch main has been updated by philip (ports, src committer): URL: https://cgit.FreeBSD.org/doc/commit/?id=169ced03796970dda19d6d52c85850f41d7d558a commit 169ced03796970dda19d6d52c85850f41d7d558a Author: Philip Paeps AuthorDate: 2021-05-20 05:59:44 +0000 Commit: Philip Paeps CommitDate: 2021-05-20 05:59:44 +0000 Regenerate ssh-keys.asc Includes several new machines installed for general developer use and reflects the repo.freebsd.org CNAME pointing to gitrepo.freebsd.org instead of svnrepo.freebsd.org. --- website/content/en/internal/ssh-keys.asc | 248 ++++++++++++++++++------------- 1 file changed, 145 insertions(+), 103 deletions(-) diff --git a/website/content/en/internal/ssh-keys.asc b/website/content/en/internal/ssh-keys.asc index 87a706311b..b28036ee95 100644 --- a/website/content/en/internal/ssh-keys.asc +++ b/website/content/en/internal/ssh-keys.asc @@ -31,63 +31,84 @@ SSH2 Fingerprints: 256 SHA256:Yyv9QPQxXDK5kznFpO62mG7U7r0RumeBj1KrkVGO77U ftp-master.freebsd.org (ECDSA) 256 SHA256:o/nrui+CA9cbglTmkGL20x3qdUviCfGw2dULROh2uIM ftp-master.freebsd.org (ED25519) 2048 SHA256:SdckbUqwisIe1b7ZxPe+tuOrwjph64fAudbF0saTDyg ftp-master.freebsd.org (RSA) -256 SHA256:seWO5D27ySURcx4bknTNKlC1mgai0whP443PAKEvvZA gitrepo.freebsd.org (ECDSA) -256 SHA256:lNR6i4BEOaaUhmDHBA1WJsO7H3KtvjE2r5q4sOxtIWo gitrepo.freebsd.org (ED25519) -2048 SHA256:f453CUEFXEJAXlKeEHV+ajJfeEfx9MdKQUD7lIscnQI gitrepo.freebsd.org (RSA) 256 SHA256:/UlirUAsGiitupxmtsn7f9b7zCWd0vCs4Yo/tpVWP9w git.freebsd.org (ECDSA) 256 SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE git.freebsd.org (ED25519) 2048 SHA256:jBe6FQGoH4HjvrIVM23dcnLZk9kmpdezR/CvQzm7rJM git.freebsd.org (RSA) -256 SHA256:ZLqzUfFKUVKYLF/wIuqaeLRTSkKMJWTHEc1tEi34B8g svnrepo.freebsd.org (ECDSA) -256 SHA256:ur2dmqEPCovUvbeZ8CC2kf8pO1KpZ555xhQPPjoSIOE svnrepo.freebsd.org (ED25519) -2048 SHA256:ZaUUjV+hewLaa+lkC+ZUvpDPh7xPYz1ivLuILe6L908 svnrepo.freebsd.org (RSA) -256 SHA256:m4EQJhqCnvcFu0EEloKikUFKqKx5WtOJIf2c9BUAuqw universe13a.freebsd.org (ECDSA) -256 SHA256:y46krcSF6v9g8M16DNgfL68KCAOISnwKPqhN4I/MPNo universe13a.freebsd.org (ED25519) -2048 SHA256:wadP2hSl5ZXY9gns2Fo/D4svHueTg9VTiM5F32ktwhQ universe13a.freebsd.org (RSA) -256 SHA256:jtv0bDiCaXf+++QRcLSyfckLq1H0ZOM5sdkOYIT9RZw universe13b.freebsd.org (ECDSA) -256 SHA256:/Fe5u51QPrBRnWXnMFfcAmN6C5jLRrEQd8y/KOqCAZU universe13b.freebsd.org (ED25519) -2048 SHA256:76fXuTv9IIjPxwX3cptSUjCMh+zgvojgRdGGDWSYCV8 universe13b.freebsd.org (RSA) -256 SHA256:quD9nCKHxG0f4dT22FyTha7Kc6nHUzGnnSqWK2Fnw08 universe12a.freebsd.org (ECDSA) -256 SHA256:KaY5Ogg4krEhU4h6h0x+dsEFoSY0AENkdaEzq/iTCHw universe12a.freebsd.org (ED25519) -2048 SHA256:nPreqBjXdpCV3Lwnl8UQdApvIHqzL+cRb9srAjyp4lc universe12a.freebsd.org (RSA) -256 SHA256:Zy/f6xwe+tA+lasb+LacvON/Uupvtaq4asAimIJtQPQ universe12b.freebsd.org (ECDSA) -256 SHA256:T9zC8DxTMba7sJJDwpg1pDBflo4Kc8KHZOtKtGk9/TE universe12b.freebsd.org (ED25519) -2048 SHA256:SRvf39r0WMEwAyeVIVbyF6UtE0rdvSPFcx7msSP1vTA universe12b.freebsd.org (RSA) -256 SHA256:jQD0EFEqoIlegV6mw22alIi0nC/UevQofwDRDgZMsqI universe11a.freebsd.org (ECDSA) -256 SHA256:PO4fM6yAkw7g9Cpnva0eWNsl/0Ag8VWzMqyZqro0YQU universe11a.freebsd.org (ED25519) -2048 SHA256:uRgH0GbsxsOOkqNGzJwTPL0XTlpf3Uayalp257eywhE universe11a.freebsd.org (RSA) -256 SHA256:IXpCXFF670kUWQbBs9hi3UKVp1eU7RsFNQeRADcLRMQ universe11b.freebsd.org (ECDSA) -256 SHA256:32PqUgMltFHeurb8/czzayzylEbiqN47c1KxcpMpDJk universe11b.freebsd.org (ED25519) -2048 SHA256:5CZX2V+bnv6fE8iTppmhg8i5epFp+P1wAmMG8tiuHmE universe11b.freebsd.org (RSA) -256 SHA256:bLirYHYdBwPEhbiP6j+KRuzic6ckXz9J+HFff5DZtBM ref13-amd64.freebsd.org (ECDSA) -256 SHA256:nifytshIwj3oG955DqlZ4rSPq1uLggU/ftSbABSMHXM ref13-amd64.freebsd.org (ED25519) -2048 SHA256:66GbjczNX7m8VNEswzI/hG4bvRenUyp2s/7tbUAVTZY ref13-amd64.freebsd.org (RSA) -256 SHA256:gpbLVKxGu9XSlu/nqUg3nc1242zMSvXr6sLsHwoigbM ref12-amd64.freebsd.org (ECDSA) -256 SHA256:dZy9tn0p1kCylbko0RlpUlm9l0H2LKgtTNVbGRAo1O8 ref12-amd64.freebsd.org (ED25519) -2048 SHA256:Q9+l5csoqo8l2wrwhilUqtOPXZtpGzCnuWggyGVKWiw ref12-amd64.freebsd.org (RSA) +256 SHA256:seWO5D27ySURcx4bknTNKlC1mgai0whP443PAKEvvZA gitrepo.freebsd.org (ECDSA) +256 SHA256:lNR6i4BEOaaUhmDHBA1WJsO7H3KtvjE2r5q4sOxtIWo gitrepo.freebsd.org (ED25519) +2048 SHA256:f453CUEFXEJAXlKeEHV+ajJfeEfx9MdKQUD7lIscnQI gitrepo.freebsd.org (RSA) 256 SHA256:RpfdSbz75lbVWHHVi8PnGSCFmAWDlju3V1ufvkhSnJ4 ref11-amd64.freebsd.org (ECDSA) 256 SHA256:MDlHVEhoxZuyRU0BsCKcdjlFlNYkJHYsQVvHO3uXDVw ref11-amd64.freebsd.org (ED25519) 2048 SHA256:ggAnWDk9zLOHaphIRHHN84Aa3OUOUO1KyGzMfgP5H4c ref11-amd64.freebsd.org (RSA) -256 SHA256:KpyVL0Sa2/T03mYxUWqql1mBHDdQtuM19ZitS9wiIYQ ref13-i386.freebsd.org (ECDSA) -256 SHA256:qUU/gYbAWSuDT6iI4dvUAAWAvlwOZz5nIZh5W7drjag ref13-i386.freebsd.org (ED25519) -2048 SHA256:VbAWcaatC2l/chl4VCwLVXWn+xkCw5kldCHVX38Iv2k ref13-i386.freebsd.org (RSA) -256 SHA256:qP9AwVoTZL1Jn/f5nLMyWNjYDP+sB+vIiCjqUTIbwQI ref12-i386.freebsd.org (ECDSA) -256 SHA256:8qH74LKHD6DaJsnQXTe0GbKmPzvTFYMNg6GESDaQbxs ref12-i386.freebsd.org (ED25519) -2048 SHA256:DY22SgUqgjUAjoze279gWreUb/wWA23AJVvFJf8YIVk ref12-i386.freebsd.org (RSA) 256 SHA256:8ok/yxm8WnN+iz+SvvDa8RK/4B8kzErATTiEbFn0bXI ref11-i386.freebsd.org (ECDSA) 256 SHA256:oMIR+aOOSiaCvapWx6aqsQlNyut4MEpwihQ2qGu+j6c ref11-i386.freebsd.org (ED25519) 2048 SHA256:PkamMuNmm2d7+hHdB03sZrZKrU5lgeT6Pf3aIAer0tY ref11-i386.freebsd.org (RSA) -256 SHA256:6IhBwa1sxBkigFIx5bE05K5pDdiGFRc2xZa7Z8lPlcw ref13-aarch64.freebsd.org (ECDSA) -256 SHA256:u922CTs6XEb/b9v0C6B8zrMBcAgQjO73/A+Q2C0l9G8 ref13-aarch64.freebsd.org (ED25519) -2048 SHA256:zOSdx13S2T72EY276qF99pWLS7aCMwBQ/yWtb//TCjY ref13-aarch64.freebsd.org (RSA) -256 SHA256:IpBHxpU8yu3Y28aCC6qW/AKchKvT5ZKvcLOWuwwqRek ref12-aarch64.freebsd.org (ECDSA) -256 SHA256:CNiyxKQtLONfgYZ3SjyuNFmXw7JyJuw1l7CU/JUqOpI ref12-aarch64.freebsd.org (ED25519) -2048 SHA256:XoSCoE+5srYqya2fo4VlwcEpR41A01aM82QFBMZUmaE ref12-aarch64.freebsd.org (RSA) -256 SHA256:FC5CEybjSWIrAKLuqYIqugoWzn5rTRJnSjENr/+Xj/o ref13-ppc64.freebsd.org (ECDSA) -256 SHA256:Yi1+3wfM075YF5urhecY1Anpcmj3ZhvFxa+2IA4syAA ref13-ppc64.freebsd.org (ED25519) -2048 SHA256:oHSyxOYnUI3sgSodROSd28z5hNalnd2QIglWKOYJ+ho ref13-ppc64.freebsd.org (RSA) +256 SHA256:3DBX0e5a1HfOBQ3FKK5DQ+qjJLxr0EqT0/QB0wM4M+4 ref12-aarch64.freebsd.org (ECDSA) +256 SHA256:vTrjIWamhz2jZckB5PzQVO6YzFZMob3y3hm9X1TNgB0 ref12-aarch64.freebsd.org (ED25519) +2048 SHA256:THGg51XxLVWs0ZBJsH5l+MMkp7Urcr5A8vT28axCWPY ref12-aarch64.freebsd.org (RSA) +256 SHA256:gpbLVKxGu9XSlu/nqUg3nc1242zMSvXr6sLsHwoigbM ref12-amd64.freebsd.org (ECDSA) +256 SHA256:dZy9tn0p1kCylbko0RlpUlm9l0H2LKgtTNVbGRAo1O8 ref12-amd64.freebsd.org (ED25519) +2048 SHA256:Q9+l5csoqo8l2wrwhilUqtOPXZtpGzCnuWggyGVKWiw ref12-amd64.freebsd.org (RSA) +256 SHA256:qP9AwVoTZL1Jn/f5nLMyWNjYDP+sB+vIiCjqUTIbwQI ref12-i386.freebsd.org (ECDSA) +256 SHA256:8qH74LKHD6DaJsnQXTe0GbKmPzvTFYMNg6GESDaQbxs ref12-i386.freebsd.org (ED25519) +2048 SHA256:DY22SgUqgjUAjoze279gWreUb/wWA23AJVvFJf8YIVk ref12-i386.freebsd.org (RSA) 256 SHA256:ZBjmxfK6wrXk7XGCCRk2I3Jnwhdjo4+OfcsTwspXJZ8 ref12-ppc64.freebsd.org (ECDSA) 256 SHA256:WvDKXdnHR/qsH6mhBYTZbxMOfOjMdwS1tR9VxyOdX2g ref12-ppc64.freebsd.org (ED25519) 2048 SHA256:jYNF2WNC06MLMI6WmubWPg1tpVdfUGZtS7Bx4MxQGIY ref12-ppc64.freebsd.org (RSA) +256 SHA256:GKebvFsZ98NIJ5e43fSqp0F+UaL3paNOPdrdD7P2UGU ref13-aarch64.freebsd.org (ECDSA) +256 SHA256:yYLigfvobM3rdf4JgSyQueM3gu6oNu9axvsuomcU6Zc ref13-aarch64.freebsd.org (ED25519) +2048 SHA256:w3JCQsy3N0owBBBZCunGN/kuxSTNJYyTPk7OEdbMtTs ref13-aarch64.freebsd.org (RSA) +256 SHA256:bLirYHYdBwPEhbiP6j+KRuzic6ckXz9J+HFff5DZtBM ref13-amd64.freebsd.org (ECDSA) +256 SHA256:nifytshIwj3oG955DqlZ4rSPq1uLggU/ftSbABSMHXM ref13-amd64.freebsd.org (ED25519) +2048 SHA256:66GbjczNX7m8VNEswzI/hG4bvRenUyp2s/7tbUAVTZY ref13-amd64.freebsd.org (RSA) +256 SHA256:KpyVL0Sa2/T03mYxUWqql1mBHDdQtuM19ZitS9wiIYQ ref13-i386.freebsd.org (ECDSA) +256 SHA256:qUU/gYbAWSuDT6iI4dvUAAWAvlwOZz5nIZh5W7drjag ref13-i386.freebsd.org (ED25519) +2048 SHA256:VbAWcaatC2l/chl4VCwLVXWn+xkCw5kldCHVX38Iv2k ref13-i386.freebsd.org (RSA) +256 SHA256:FC5CEybjSWIrAKLuqYIqugoWzn5rTRJnSjENr/+Xj/o ref13-ppc64.freebsd.org (ECDSA) +256 SHA256:Yi1+3wfM075YF5urhecY1Anpcmj3ZhvFxa+2IA4syAA ref13-ppc64.freebsd.org (ED25519) +2048 SHA256:oHSyxOYnUI3sgSodROSd28z5hNalnd2QIglWKOYJ+ho ref13-ppc64.freebsd.org (RSA) +256 SHA256:xSoIeq7uzyfo9vmMaD0Bw63QC9QjqvDiunYVlqZLDQY ref14-aarch64.freebsd.org (ECDSA) +256 SHA256:Mn/kYwY39DO86cT2oIXtnJsZazHeStsb0XtPqe/MPGE ref14-aarch64.freebsd.org (ED25519) +2048 SHA256:ZSOf/WoUAs7K0WlxbmGq9iM7qjNXGxfcVf0wcEfBeWU ref14-aarch64.freebsd.org (RSA) +256 SHA256:C9ps7zToGjdmT4zYAcFM6sIxB/HwO+NpESurqd+Yh5Y ref14-amd64.freebsd.org (ECDSA) +256 SHA256:6J1GXkL6hH2syITOuOhy2v1qs16ruIq5HOJcyySTOKE ref14-amd64.freebsd.org (ED25519) +2048 SHA256:7QY6LyEGDPRsW/5KwH1WjPhvOtSF+y1MnxCqeSzIuUk ref14-amd64.freebsd.org (RSA) +256 SHA256:7PT25eP02oEEdX5UcRAtmL33M0qKP6tVLtNZx563J3E ref14-i386.freebsd.org (ECDSA) +256 SHA256:vNLi0iUWV6zv4z7m/PPULUYAM45m+0lUd/Hh6QPiLt4 ref14-i386.freebsd.org (ED25519) +2048 SHA256:lM9T5ANVyerbavvMiXSby/b9iTkwnWpx2CRv2URyyDM ref14-i386.freebsd.org (RSA) +256 SHA256:c8rJGo78Vnatm64lHWthKurevVPoU/9axT5vcn31o78 ref14-ppc64.freebsd.org (ECDSA) +256 SHA256:ScpkiCFhl/idrFe85MJSs9/i6kQRexeyvalNSrdG9X4 ref14-ppc64.freebsd.org (ED25519) +2048 SHA256:UnQ/QsUzXpvNoCt0VqZZ0T0b5Elwq22JMjp7id49au8 ref14-ppc64.freebsd.org (RSA) +256 SHA256:seWO5D27ySURcx4bknTNKlC1mgai0whP443PAKEvvZA repo.freebsd.org (ECDSA) +256 SHA256:lNR6i4BEOaaUhmDHBA1WJsO7H3KtvjE2r5q4sOxtIWo repo.freebsd.org (ED25519) +2048 SHA256:f453CUEFXEJAXlKeEHV+ajJfeEfx9MdKQUD7lIscnQI repo.freebsd.org (RSA) +256 SHA256:ZLqzUfFKUVKYLF/wIuqaeLRTSkKMJWTHEc1tEi34B8g svnrepo.freebsd.org (ECDSA) +256 SHA256:ur2dmqEPCovUvbeZ8CC2kf8pO1KpZ555xhQPPjoSIOE svnrepo.freebsd.org (ED25519) +2048 SHA256:ZaUUjV+hewLaa+lkC+ZUvpDPh7xPYz1ivLuILe6L908 svnrepo.freebsd.org (RSA) +256 SHA256:jQD0EFEqoIlegV6mw22alIi0nC/UevQofwDRDgZMsqI universe11a.freebsd.org (ECDSA) +256 SHA256:PO4fM6yAkw7g9Cpnva0eWNsl/0Ag8VWzMqyZqro0YQU universe11a.freebsd.org (ED25519) +2048 SHA256:uRgH0GbsxsOOkqNGzJwTPL0XTlpf3Uayalp257eywhE universe11a.freebsd.org (RSA) +256 SHA256:IXpCXFF670kUWQbBs9hi3UKVp1eU7RsFNQeRADcLRMQ universe11b.freebsd.org (ECDSA) +256 SHA256:32PqUgMltFHeurb8/czzayzylEbiqN47c1KxcpMpDJk universe11b.freebsd.org (ED25519) +2048 SHA256:5CZX2V+bnv6fE8iTppmhg8i5epFp+P1wAmMG8tiuHmE universe11b.freebsd.org (RSA) +256 SHA256:quD9nCKHxG0f4dT22FyTha7Kc6nHUzGnnSqWK2Fnw08 universe12a.freebsd.org (ECDSA) +256 SHA256:KaY5Ogg4krEhU4h6h0x+dsEFoSY0AENkdaEzq/iTCHw universe12a.freebsd.org (ED25519) +2048 SHA256:nPreqBjXdpCV3Lwnl8UQdApvIHqzL+cRb9srAjyp4lc universe12a.freebsd.org (RSA) +256 SHA256:Zy/f6xwe+tA+lasb+LacvON/Uupvtaq4asAimIJtQPQ universe12b.freebsd.org (ECDSA) +256 SHA256:T9zC8DxTMba7sJJDwpg1pDBflo4Kc8KHZOtKtGk9/TE universe12b.freebsd.org (ED25519) +2048 SHA256:SRvf39r0WMEwAyeVIVbyF6UtE0rdvSPFcx7msSP1vTA universe12b.freebsd.org (RSA) +256 SHA256:m4EQJhqCnvcFu0EEloKikUFKqKx5WtOJIf2c9BUAuqw universe13a.freebsd.org (ECDSA) +256 SHA256:y46krcSF6v9g8M16DNgfL68KCAOISnwKPqhN4I/MPNo universe13a.freebsd.org (ED25519) +2048 SHA256:wadP2hSl5ZXY9gns2Fo/D4svHueTg9VTiM5F32ktwhQ universe13a.freebsd.org (RSA) +256 SHA256:jtv0bDiCaXf+++QRcLSyfckLq1H0ZOM5sdkOYIT9RZw universe13b.freebsd.org (ECDSA) +256 SHA256:/Fe5u51QPrBRnWXnMFfcAmN6C5jLRrEQd8y/KOqCAZU universe13b.freebsd.org (ED25519) +2048 SHA256:76fXuTv9IIjPxwX3cptSUjCMh+zgvojgRdGGDWSYCV8 universe13b.freebsd.org (RSA) +256 SHA256:S69QAGkXKVGSvnSOPV9B0CIbZjgY8cu85bYkgB/jBr4 universe14a.freebsd.org (ECDSA) +256 SHA256:yCTDgjNTnlqoOLL/3SBx4XbWFZ/QFzu1hMh+YF+IC50 universe14a.freebsd.org (ED25519) +2048 SHA256:W5vXQDtmcNWCmsZ03BWJdnZ4BNrguUNF8jelhOZcKo4 universe14a.freebsd.org (RSA) +256 SHA256:oMShp4W6AUA2Q0qW/htRwNRc2gLS3wiNQprCbENdXLk universe14b.freebsd.org (ECDSA) +256 SHA256:TXAmHIfOHbonpP1A0pX7GY9I6bBTmiT/Ff10oQB+wzA universe14b.freebsd.org (ED25519) +2048 SHA256:4HMkE1guWmQb4VtSNkvIXicmt1RImT2I1PJTweqckRE universe14b.freebsd.org (RSA) SSH2 Public keys: @@ -97,76 +118,97 @@ freefall.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA6FpCVgwrxcHE5pGAP+RuSKG ftp-master.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOF/1layYPl2Xxoty53KVP21vK2U8wwIp5taR8mGZFaLhScAf6wVBbuJW92CGm0M2NbKEmjeNd2t8ILblbpcZdc= ftp-master.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILEPoBCvdm2KYeEn3pnzOUIL+czYJWTcZYDnnvNXnAcs ftp-master.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDUIDl/0RTnpFARlIEK9ZrHGMC0/30NnYG6Rb88WrCRQCQ9URZPkbTXgJTEgedSBvfpM1AJasIu0Z6QeXDhuNOFJhaM7I33zh07zDojd/LxxPuMUeZVGZSKbx6Kb08tw7QmA3Y02FtpiVleKn5TDgVaFCiKnbkmXvo23iyUt7hoaWYRvbSkeLisvAAzGfke1UGxdHoTZD6i+02nucbnVKO/MYeD2/pRMP6jny6w1egtuskCLnIcTm+RSsEzcgFU4SSR3EY7MGlWX/UD7G6OQUJeHCGwF/oj1lbbdiopH+iZrkQAKGwrStkNU5UJtQ8pYDq8TH9n3Yk7k/A8Tsuf308b -gitrepo.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNT/cpTTWUX3PpuQu43piaqwUgk38rxRf+ln/F7I8mHE+vTA/LjoHxB1Eh9aFa2c7ljcI8GMG3eIUU43Wu3aEmk= -gitrepo.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMRzBZvmnnwNjamH8E5JH8q0BDAgYLgUcFg2I/tFbhf/ -gitrepo.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC46OH12yjSpw+xLiS1Tr+5ZXawxOnR7gwibd+2joF+rvqPlEZ3BxvbP4In6MP56IP1nrPjPhmbRypqlh4i1U+u3t1Otqi1ZhEJOF5+Lyc6prB59x4DyIY/PKIh65VphAaD0RzKfJCRWJvCD84R3KY5GDa9RtIuHmduT9RF4tzs5FZJr+iEGJe88zpPKvlsbWGXH2IYbRUU+VylxMTXMxl1OOMl2PIICMZjmyZgb0TXAh3IAWViFZwsYStzeLvtv8Zb2mQj+w5YFTSgw75+DJZSntS5SU+AMciJ8qQxrDAL3tT8Z1OUWJ1jfnB8SIn6E0G+gYwLGTisEYCi/JUGnYyR git.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBLiVy+zbrShZ9n/C9RWogS5oCS11AtCfzMzFv8qgz5HVw91N3BaveAzoJYYpBaE59vmIEw4jjxYYErEMKS6ryxE= git.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFciKTKq2B4Kt5sE19CHdDhUMxyBhqddc0p0cUtac/MF git.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDOhoJVHBKNSE8rvbY4bgdTJ0C4gwgjWGk6iwhYVGEqtCuaf7y9hMgTL6u0D23Gscl3t67b1cSm4kcdZgvDMxYTFMmtXal/5amk7uD5FZSf6TxZKh9m702t9c7fpb3sxzqzyos0WiclYZZCfDq9jai9fxW8hzQKdaa+mmHXWW9NlJazyCcjvHLdB1XH2/cuqfNmnGqF3iU6GK1S2nIP2uvdpWq1FNS6e91aiDPKrboqCEqZFmk9bdU0xLMhQFUU5fuMi4aINid/mpC2+zfJ5uFkOXEPWNZUAxOqnuz092YsQMs0/hEHoTugz7kmKWfHf9R1uHpzR45lkwRQOOFM8QkF -svnrepo.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCYpIsNWM5NsKhXiwPe48FXLXSYteifAYPQMLpSwiQeklv1bnQuMFnb/ASeXipdyoxJBMMEyFSqQ8HJS80F7Ehc= -svnrepo.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOzU38317JG+B+diNuTTXI6tSP/eyiyHsTAZimN97yqJ -svnrepo.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAvnPw8T77uwTMJJTakmWoSA89AtZRi/X5zAFCmfuG9QlofyRa23ktqP0fOxMmFARXRvbVr3pozEl/AP14CZbTxWZYwHAphZd0EcEYgDiW/N75t/ilywWHPXp/IiYQLLL3xeHxNyTNEiodcCLCVUufPyFGfaeBrUw2r3PKNZ7ZwW0UofbbSytJHsk8UVxpjS3RFjxB3daRjrMc/df7xIBPr61bhfxKR+C42K8qX9TqATTFoV9ngNafcfiPRzB9OLZ8sJwLjaV1Tc1lDjUr0nSbcRMr690yQ96O7e+eklze6ocSiglbqtpenPN430Ru0YnDP23u/k2CLHPo3hszHfmCDw== -universe13a.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHG3qzKk5L5OsG358PbFrlv4H9sU8tDcmYTHO3mvAXV41a8dYiais/6vQ1HTQ+Qt4/CCDQzUtBhN3lOASQZTQWM= -universe13a.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIA+nCS3awdGD0ikkuB1U6XK1D9E7JgGj3yBT6BHPG9je -universe13a.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8RZWtfyVkFfdnw5lDFstHyHk4Avrbherew2ff8rRsOOv2TRgH6uyNoQ7aY39lwJEVDjgHlf09pIU0+51akKL4m+Fhe0eHLzTIASuqa5dD1A6+1jlvwDEEO3o9f+rEdPp92dz2aWfc5BPbSq4DO0S9s8eca4sATY1EPuEas/wZ/S0r2v+QRIg2UIngGQ4EjzvobET3wnMds05iO0nLkGoCF84uX3Fg1i4Qyf33Z1+XYQ0aZ6REO1dBrmZhaXXulmb7xzzUwsA5FmsCPVPji5IPvHRnAoGC0EW+WK0vG0JQnM/bu3SqJi3Lxne9li64c+SAasvXs8Qm5tlpBUJCs87Z -universe13b.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOvWMX3Rp8ANOxAHGM/bvRtZdDTJzhxkaaev5Q8FhkVK9VGXuxcet8+gAEj6P3h8Y5kqEqMvvqPHQeDYtdOV/eM= -universe13b.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINmnwPp9p9aDNdl01rFHOlcuOJ1yqfjYlM95cLK9bP/t -universe13b.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDSqVoh2uDijYLWZAlzg++k1A/H+biWbyURcngKKo12IPOax9hqUicJ66z6pSGyBnhpAqek8bkXcFdyiRF0RnI76vpxiMuiAyxs9rWMfm+4c5MbKOSyaFQhnf7GCXBNWKOQi4gmyh3LvDhCv5/OlEVYryUNanO1OVLOz2hSaRLJopX5c3fDZnm4tflgY8vwkkEEW8gn7uFUYVFqBU5Sx6GgwpMEuEt/opiwEihVQTykVvX0HI4yF+47q25wMfAsSTr0lel2Fs/7beUt3htcL4QuKScIJ98AK2gseCx1rd8xDBn2AHDrnSLjYJ2A9lonljFaSLUs8AuvijAh4micwiDR -universe12a.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBPzA+9uEO99A0pmZE7psusNdP6MJEwA/5DpqSxN1Bv01TNQj4nvEWabXrkQEfxBAEaecLm6YlBJM8HeVtQQp0zo= -universe12a.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIN+0tCdZhNnE89jHIhN3dgpHnGjzcj637NoFcbO6KsFq -universe12a.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDuGfcl5ECKd1FSaMfP9X0qqhpk2/BnTxXzlydFrNoFWkiFOzWM9RGbZNWXb0Ei+GZoAjMb/jrxRONabY0GaLrt+xlNMIkNeITh4+8GhmAJPtZ9PF9IbmIO1evSFe9JKZ53TjLt7Hj13WMJspR5JsJv1b/t1T8UZ4MAPYiHjq3zz2b4K5rq25K46c93gAsNGAw9+qUoQt/RTFzs+LUeLduLHSMYvurB6fkEWC4UGQBqt65bo/9XRocFwTCnEagJsL1Bski4KsKDbwxeEtpESh2SxLF2YbsN1txIdUOrZY9rOiL4Qc64gpkNNJI3ZKwWsPHPuNqxZZJqHt/3nSVYC1ld -universe12b.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMnSryIFNHS7BKCUGq1XwG/ct+Ftgr/tWmgVi4APPQ2J1BB3YSPCHm7hCQbG9NP5KSPcNFG/IqDsiQ2rLQwERQE= -universe12b.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMn2KgjqlbpaEMyi4d8/IU6AbODIyGpZ3485VpBuDoz1 -universe12b.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDA0dd5CsnBIeIeSFtlvG+G0VOuaDAv5X/i/QYHB90V9PTwPAItd3HSuZSbELFI74KCyRK/BEWQD5A2Ci3PeestxuqoAXUTp0X0UTfYNJ3li1kO7hIn2tpqY4eAEZhhL9eaoC3KgNU+doBVPgqHhxPUCwtdYtPStiMx0gqJRSbabb94bkoPM29p3g0gtPpXtuT27mWAVJbfj2LT2f99MTt2taGKKTjVbRresJGPKMt3avPFjHiVEj9v+Upps08nQahSkqlHH/84yaeh/RRfrw59wXDRyOexu4EHqCTUIO4VHpjJrjPg3GSJvh6O+tpslY+9mApcIpXb7dlLZEHhqinn -universe11a.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJc4KVr+j8znE7W0VNnZipLYdu7vPFEDrd1YywkxLopjpni6UhowPtuT6/tr0Twq2Z1hk+i+XDxpzGMim9ya/NQ= -universe11a.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIG+/U6rFvdNzuWJNde5PvNstCjmvzkuA2PnNNkIFDXxm -universe11a.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYnMgYvNWLpkHAKT8dnPmmsYb8TiSzW3wgGes6hd6BIXZoTRWgZPMIQI0iL7SjbLlH26z2IFfflWUxsNKF+wXx8EgXrO4q5bu9xnYAAk7LynXA+5saP6+UTr0UOYWODuZ/823uWVvJffUdDM08grfIOvZRaN3/kRKCKJW8Csw3NVsgzu4AZ45111FGnqgNgSVeXJy9vDKaQRL2eHs5YVFOeyznFxTWc1O1qWYtzIiJLiRjvvAPZqcYxb9YDcrXGXnjO1JehbyQfEDg1fSo7fXR8XE9N6k1prTkAdlk687ixTJTrFJmNNxrNQbdsP4coSihofyy2H+gsdee+AHpaLMj -universe11b.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFn2GTTzn2QYUsrX/o79vra4tEBKMm09ugvKZFzX30mvRxPoIbAwwmEQmae11OcsraGpgsB36dLXSmd5JKjOzLA= -universe11b.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIdRjv1Ye9VDaLgr5mAiZ6h5nii6hmygJHw4ptHJ7ulU -universe11b.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCpyA+VIN7LZdVgZRiQ8yUBNToK4/x9Vp+k363Cbmg5LHLjIMXuFspTs7CVFcl+Gkr9WeFetE3GpanZ0yc5j3ek+MKVoFQ4siRS10SlGlFeGljMF2CdWrIO2sAh9TlUOk2gLBdv8Z64d2Mhlg19jxNbDBHXPIkOo9flbrT3ePLZRPCZMKLeUAhrWCVpN79fA1nZjuDxN3M5Q1pD1FXAC5WzbbZIz4u8Fw9rsXlGQISOlyzswxMxaU8/YonA7uDG+MsB3e/OvuK+XqWManm+YGr3LsfQ/euidJFkCBRd3o7njMAfLPGJo0pHP8EgzLCtsK+3WTUzusSG9btehKu06zOj -ref13-amd64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIe9tOpEFGq5mCSDBvmdPdSIoCjdgrE5m6TjqlpEealvRAmeYwCc8J/1CLqbFKLBnkXB1cWONIPMkt0NZx9K4r8= -ref13-amd64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMDOCWhcEc5GA2ir8faERZy3qAD5I84Xi/XuP1vCWBmU -ref13-amd64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC6CdIW6T9e5vC1b04xZyJnnAxI9tpIrzdS/RKjFUhKaKMBeVygRXKmIlzDk1KrkNeU5jF15CQWvecO93PxcYiOEsWImpz4yq/zAZoS2HCXlqLJUCRG5pWS+Sf2mxfB10mu94MWvAjoWLgT01W1CSUuR/GN7+71NTW2qjcTfzplcGA2Ci8PYzvU/EVzNmISR/Zz7A+0yjZejggXkDIOc9/2WoF8NMwW564L65Xhr9P+WIDwsJ+wZ4Q4Qyqxxx4ndDidnn99hrxTinazEneSl6SzRbVqLU9Ye7DJ7+1ENzV/fS+fXsRz0L8bE7kwgbLD9vnQNv9Zvw6tsePXK2GMA8m1 -ref12-amd64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDqhaAKH5Smj3LP2EkW708ceko9YzekxWL6T1mJRyBAbdSREtnfU1WJvZBTsLN1FG49So67L7XvuDL7NWPUyzUA= -ref12-amd64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFOv2r3fQyL2bwqMwsmMbzDDO2jG9zsKzb1KUd4OTcIa -ref12-amd64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDJmnQW+IUN+aEung7ZYTeUAR9jz+WoL860rlG0fKh0D9GCxp8LF1tULGwTkBkiJoGBBcUmSO+Ku18r63CqmpIqvvlipIC75sT288SNhg4c5qWzdvPGpALgprQRy6V5itwqS+NPnUGmEnEk29DtCjQB7bSZcSrteLRzxEwHxEiwRPCi2HNV5l0TmQZjWZBJa406/89coPuiDNzYYbMljn9mF6T4jsx3VFXi5lbAOHbOWK4InROp4QJKdENMFhUsLBmNMS0qeIwkQp2hwywfeyXsMkE8DmqmnDhYsHtWDR+tSUzV/zLTfSJ+LlQ7ZxiOp20izpmqsmxrnUtyWO1hbLOz +gitrepo.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNT/cpTTWUX3PpuQu43piaqwUgk38rxRf+ln/F7I8mHE+vTA/LjoHxB1Eh9aFa2c7ljcI8GMG3eIUU43Wu3aEmk= +gitrepo.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMRzBZvmnnwNjamH8E5JH8q0BDAgYLgUcFg2I/tFbhf/ +gitrepo.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC46OH12yjSpw+xLiS1Tr+5ZXawxOnR7gwibd+2joF+rvqPlEZ3BxvbP4In6MP56IP1nrPjPhmbRypqlh4i1U+u3t1Otqi1ZhEJOF5+Lyc6prB59x4DyIY/PKIh65VphAaD0RzKfJCRWJvCD84R3KY5GDa9RtIuHmduT9RF4tzs5FZJr+iEGJe88zpPKvlsbWGXH2IYbRUU+VylxMTXMxl1OOMl2PIICMZjmyZgb0TXAh3IAWViFZwsYStzeLvtv8Zb2mQj+w5YFTSgw75+DJZSntS5SU+AMciJ8qQxrDAL3tT8Z1OUWJ1jfnB8SIn6E0G+gYwLGTisEYCi/JUGnYyR ref11-amd64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBH9n3MbXvjZRGunm88lQP5vVcJS1h7oOdcejatTk3rn0NllZG3dHnDovJqb7l+EsXQpBXpEcuusbiYdoxWEXEOY= ref11-amd64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHKgVYs6jK+rTfI/4zestSaulSgzaX76Is95HXdIl9rv ref11-amd64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfLVI8U07yhxjozVpwrhfT/9t2dpkbOHAgNFG8KijCrlm8ghnH/kRJJSPcZBPfEk/XRZiqcmiMKVhqvLbW55pZOpPx5Rs9KThp+vJtJNZHB5j3HAR5Zm+0t/iOUDSYuXmTZzlDXG/8CePOnVuuau4FcPkbrAIAv4yB8F9Ft9sk6aEg8GsFuWTft5tBivwjmKhHUOvILJLrtWGVKJf+4uMwUcGacaNaBmfnAnyuGKacnqmJCmXKf1ts9gSz14pJB2IS/k4oSkxkuzNWhyQ4IiQPeDrlIEzA72zTVkSFEJg4mYlZrIyizE0CgDneWiHT+EkoKM+JhaLK+mje0fBn2JkT -ref13-i386.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBPnA+dqe29PIhie3o9Cm7W5H0Db33G/kNR/mU1lOhZ1PExUmSiTahC9OolJ8i2sZgDl6nBkWchyYB/8GntEgl7w= -ref13-i386.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIO3lBiAPIQXqY+eueGBPenx+qcVb87Y6+xY+yK2X+2gw -ref13-i386.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDi+m/0q/zzBA7nB7UvnxQGxumvdBHtXNJk/hAX3QJAdcD5t2ATtKG1LLvUlttRu52Mq2DB2nHkYNzQfz2aPCdCcD6VdqT6RVMklGx2IWCqgaeS/GX9Em8tmIDbR9wkOWmHbMtzKQNro4TqKZeobF/+Kpu4arJYjAZd6LhR8n66zlmp43bjUg0pp0BXqSiNmy+uUQt3AhmkrLZlkwHwVKUrLgva9H+QhnpsdTolQhxIUXwWiMyj+QkkwC3szAuMBeCsusaqrtLv22OEBkwAQfQ2Ca8IxrDg47eg5W1KHxrQoudFpeXtxljWEPot3RmIQsF1/HshtR0znNuf9Ap0Bbzh -ref12-i386.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAI3m6meSVi+HN2MqIT/Sqxvic7LvbUOYqWfhVGrXSEzIpNBc9mkkVmKlS0dh28+xVjZImE310qSCelRQk3bE7o= -ref12-i386.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHtYmeh6vuhvl6xekwEuUTPKjCa365vJIF7i75vdiI1U -ref12-i386.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCr9o1guTOxzR4LWRBiSv7LfKHHNgpACfQWUcJ5wRmOkljDLmqVJ7B/6EMGfsrpjLaSa7NKs/4lOew3vtIkFCFZbq98Q5k39qDLD5+vhuy3ZMxNdrIyyMuKbVXdU9xSpyC0GwXp0tDptj5quYsGA2Hto8QyzRmgAtX+5SDkyf7l3pwpQ8jmR7OCoF4WEZStIAJmKkSllTcRR39mr2TSgyGZnqrA/XAqLEFcb0Gd/mgnm0JPPzOGrmg+Z3QnSNTcC9B1qzdJXNZ9C4xJap8H3yETC6hbdT0pcOazIqtQsyjazZBYNwMMBrxGvzuz/EB9UZ49nA7fa+uIwbEGAVkrTl53 ref11-i386.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBC5nu60Y/brV+Vok+v9lBUhPnKEnAnGuGM+wWpmHqPgaWL8h3PC7ni+u5YJnhKafpgMKu2oveF/0H21wOhYhLlY= ref11-i386.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICtKsIZnUf5yogKN9YwQF1vfcLjw3IkS+TCz4dH0FEHm ref11-i386.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC54ZJA0+mujijdR4EQCQyY/59sbkM1reRBIgb9mSQaax5tnF9UAilH7IXFnq1/aHSP7t3g5pzmLKsNNJEWz7POAQuKgaIekAdZJr5dxTEwYpj4PzLQzTt1+2T8NzYdWg0gbmDSSRtmPyUKxeiQJZqkGH+6xm4Ye3Lh4pNmiyguHXbNzSaWzo9mQ4g60OBDEYg2u363VpIcOEgI5nL+AqmVkfz6avuTg0rcUfcOFpxG+ZEemuGgXeSaQZ/Uj/gMXZ9c0EoV7ddcnT3CYv27y5GM0Onx02WwoNb4QMxQ57cJ0Cq6MJ5gsGGBPc62EzFFkH6c2K8QRskGONokrrw2AB/t -ref13-aarch64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBC7L1o/tsRSvoXGH/VW+yVKXH6xln3+Qp2MfrQP736wI7k0XzvwEZKB5YG0PmEMHuxQ1E3kWj0K+y6g7mrgjopQ= -ref13-aarch64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIISe4LDsCbBSFFuK7VHQFO7H+WZWOjSjIpzwbyb/PaNs -ref13-aarch64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDXF3jFYs+HOilfwPNJwSq9KHXoNixIpjslkKRvcfcNQarMiLy9TMlHLBcDxQsC9ufssWHgE7FeQLvq+1Eha2XWAX4vzi0NauoEatmYXTzSX2AdfecuduLNFWMv4HwTV45YatDS63tHQJswXh3x18KTTNNJ2AHH/B31F5ZKlKW5y6vklAIqAuDWqC2+7BLAzBkJIFC8tBISN4aUpQ8hgNEp9fRCFvXM69kx8z+9MK/EVYj1c708n7tn3xaadd2E3QRqwPP+wZarclWAI8kj9ZAe3QaiDlDIWxN49vxeeysL6B2qN9EmoW1ND8OR1w/dQ54WbG96TSp2lgVtyyJo87k3 -ref12-aarch64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBFS3D/n6/ZqwaGOuuOD1LoGcUyZYF7nb/7PxhXq5nh+jB362wzHrHSDkyaodvN0BMRYPnGu3dVDFBD74W2q2EE= -ref12-aarch64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGkrCKGgsCrI1NF+ur1deRxasUKjx0sehxp9dyAaC/tI -ref12-aarch64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCx9YVXlr6tEnN3cB8D03nXr7qmZVrATQSjMxWWZV73OB8xn/NOcbryrn6p1ThSm94VA0KaynoiCQNCrsdItPsZl3HMoO/f0HVpjjdsUEKutD2QxXjHQs39R1WVk66wo5tc48TEkXOgFdfSvFSxDOM8Jg95mACK292ob8arjrNsqKsVGMed7xJIkVOhgLTqpUmaeBFEgaCtoGGroenX2r8A+io3Z0yRpLmpci5qUsa3v0NXWQBq5wRPwwzpRrOd49cI7PTGqcz9aElcDNHcoL2dxS0tyNLmQAIlvU4GuguaetmdDf1wTaw8OLYYL8cjMmYSd6m8hKB0J1P2b/tb8aqt -ref13-ppc64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBLozAs6F6u2ukhKYHCfYKhwI4HAYtDgVU0q0rMieIRaQcsxhN/9jGO6SvLat+iXeHYrwLMD3plgrdcfrso9NJKE= -ref13-ppc64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBYwfwnMSb2jSQn2HDHN8oiiPjaBRK9BnrmvdA12hGpu -ref13-ppc64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClVWjb0QvgK2+rXGBaNJCQiJQtPJHpwGfiQ6Ah0LXEQmdteyojATcueZKW6VnPeuwPfk3bjYFIA14aKWe558RAY218W63UcoivOJhzt4JXxCAPums10mgNCT8PQdEn+hbArUVpXuDm/nNtRyVs034+2g1dD8vK75AWqmGQ12rba8O+e+Ycp+ckAj5Fk95CZdUtM8QtR7svtR5+pkWg61khWTFmL5Qv3Pe++jjse3HeJyfFakWHvIsNYQ6E027BfyRDi7IvYZXHSC4jrAwUg2LWSMLBTKjCog06SzzNi69iuacZJzfC0fFl3EFaeGOwwfOOt1KR46h5XeI54tEXQ389 +ref12-aarch64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOCEhEkf3c5Ug4NRE9cYdzRNi+Z2Wb+w1LwldabQRwzod0oCCr5Z87xMK2uNsPcKXteDweXp3bvwUxRyLV/wm4s= +ref12-aarch64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILiewXMolPeurtCHi56IhuvaFoZ74dkClEV/CveaN9g+ +ref12-aarch64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVhusLfR8w4nKz9rP2vr5cEA7zhq8os/MTxGZ0J9HjaR3cDAXa5xil88AeRVDU9nmAkp05LhGnzEGBJ9/JMPZQpl2JDS1BymdzfPquqi+RiROH8st35xrVYnjzya6XQNeMyShZmkXnmf/VZcnR6R/NaCwr5CJPcJTrYNQdTkEt0vQzuwtdQicFUnbvp1B4xaxRiq/2q3RSdjteZrp/aynt90Ce9lZOzgCrd+hlCBuD96X5GqzNwAN8invqjnxdGuu/HTvBw1cC3nPb0QgOUDkKomB0SukauEJdeXUuLwZ2nMdeEI+CuH5+IrP9GTFbqA6bpnqmlNkqWTdJySTvNh6/ +ref12-amd64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDqhaAKH5Smj3LP2EkW708ceko9YzekxWL6T1mJRyBAbdSREtnfU1WJvZBTsLN1FG49So67L7XvuDL7NWPUyzUA= +ref12-amd64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFOv2r3fQyL2bwqMwsmMbzDDO2jG9zsKzb1KUd4OTcIa +ref12-amd64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDJmnQW+IUN+aEung7ZYTeUAR9jz+WoL860rlG0fKh0D9GCxp8LF1tULGwTkBkiJoGBBcUmSO+Ku18r63CqmpIqvvlipIC75sT288SNhg4c5qWzdvPGpALgprQRy6V5itwqS+NPnUGmEnEk29DtCjQB7bSZcSrteLRzxEwHxEiwRPCi2HNV5l0TmQZjWZBJa406/89coPuiDNzYYbMljn9mF6T4jsx3VFXi5lbAOHbOWK4InROp4QJKdENMFhUsLBmNMS0qeIwkQp2hwywfeyXsMkE8DmqmnDhYsHtWDR+tSUzV/zLTfSJ+LlQ7ZxiOp20izpmqsmxrnUtyWO1hbLOz +ref12-i386.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAI3m6meSVi+HN2MqIT/Sqxvic7LvbUOYqWfhVGrXSEzIpNBc9mkkVmKlS0dh28+xVjZImE310qSCelRQk3bE7o= +ref12-i386.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHtYmeh6vuhvl6xekwEuUTPKjCa365vJIF7i75vdiI1U +ref12-i386.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCr9o1guTOxzR4LWRBiSv7LfKHHNgpACfQWUcJ5wRmOkljDLmqVJ7B/6EMGfsrpjLaSa7NKs/4lOew3vtIkFCFZbq98Q5k39qDLD5+vhuy3ZMxNdrIyyMuKbVXdU9xSpyC0GwXp0tDptj5quYsGA2Hto8QyzRmgAtX+5SDkyf7l3pwpQ8jmR7OCoF4WEZStIAJmKkSllTcRR39mr2TSgyGZnqrA/XAqLEFcb0Gd/mgnm0JPPzOGrmg+Z3QnSNTcC9B1qzdJXNZ9C4xJap8H3yETC6hbdT0pcOazIqtQsyjazZBYNwMMBrxGvzuz/EB9UZ49nA7fa+uIwbEGAVkrTl53 ref12-ppc64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBiJCSUhpdPCWmXSEy5GUl1nJjbgvH5MveYaf4PqssLWJXrw/AAZQzGne3MsXpAyeqkTqzkPRG88mwTgfdSMJlA= ref12-ppc64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOX2lbs+hnB1tbFrZZlorfC7B+pdU3NMzkT2E5qa+5Ld ref12-ppc64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDtcHMSUaMFiLRSv7VnCl2Wfn8D0pqIDShdgu6Q+0ix7mvllseJEaQezmxKdtOCjmVBuRmmAyuQcgZnRuV26rM7CuXMNUtFuSYGCMKe5OiD1JINHx3qv1qpDQbBoLKCg3l8q1bcBfB//NsJAWpy19+xEz5dumErVUWWb46aU95s3RMaPoXnncxfd7JB9geaW8JhBuYZRamc36QqKnBiSaCsHe0bNyBqZ5uokF8Je2Gj+gD/KB2T2aJP4T6n1VekpkEy3A/oxbJXqa3/zCgbeNq6HOt+7zJv5OOpaeusL0VMKcUV1mRcI2ppYKrrOkk8dNUfn7wuyWAmNnNscf2HxRIt +ref13-aarch64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBLp2GKbM3ulD7C16TXEsemIw01+GvTsdk2p5JxpDbXMeGdywnv6NOEaF8v96sGnZDT/e6IXnCDH5wD6UgfwuWvc= +ref13-aarch64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINbqfHDrwl84zR7vC9wurDy09fL1Rz/K9jRzRbH6PqX+ +ref13-aarch64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDIWsyIP6DnkVTU7zq7/Aeg2OVhrYekERVO3aTuOGvW831cSizDii4lFvrPKGtR6eT3fXDK5P1l4L5Af9UT1BRiRY87bvASxz0jhuFufGTx6jvbtp2lRIAkRXZ410tAxoQXR3FUysAjwjw2QUmB/albeksLZDLYMN59I4118AvXxi3RNJvHKiUD+ssdJ2NVgh0BUh/7MeRs/QTLKmwOUCU9Ug7RByj0lENSB6A4OeVfcgI+px7uO0lPgrQDv8jEHkWxwTs/WpUOW+ovbWBGgIDPrNGcw/G/a+8XTlOeqGZRibGZK6px94SSI8RvDKNMQXjTswsuDWdR6CQaUkwCu3Cn +ref13-amd64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIe9tOpEFGq5mCSDBvmdPdSIoCjdgrE5m6TjqlpEealvRAmeYwCc8J/1CLqbFKLBnkXB1cWONIPMkt0NZx9K4r8= +ref13-amd64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMDOCWhcEc5GA2ir8faERZy3qAD5I84Xi/XuP1vCWBmU +ref13-amd64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC6CdIW6T9e5vC1b04xZyJnnAxI9tpIrzdS/RKjFUhKaKMBeVygRXKmIlzDk1KrkNeU5jF15CQWvecO93PxcYiOEsWImpz4yq/zAZoS2HCXlqLJUCRG5pWS+Sf2mxfB10mu94MWvAjoWLgT01W1CSUuR/GN7+71NTW2qjcTfzplcGA2Ci8PYzvU/EVzNmISR/Zz7A+0yjZejggXkDIOc9/2WoF8NMwW564L65Xhr9P+WIDwsJ+wZ4Q4Qyqxxx4ndDidnn99hrxTinazEneSl6SzRbVqLU9Ye7DJ7+1ENzV/fS+fXsRz0L8bE7kwgbLD9vnQNv9Zvw6tsePXK2GMA8m1 +ref13-i386.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBPnA+dqe29PIhie3o9Cm7W5H0Db33G/kNR/mU1lOhZ1PExUmSiTahC9OolJ8i2sZgDl6nBkWchyYB/8GntEgl7w= +ref13-i386.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIO3lBiAPIQXqY+eueGBPenx+qcVb87Y6+xY+yK2X+2gw +ref13-i386.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDi+m/0q/zzBA7nB7UvnxQGxumvdBHtXNJk/hAX3QJAdcD5t2ATtKG1LLvUlttRu52Mq2DB2nHkYNzQfz2aPCdCcD6VdqT6RVMklGx2IWCqgaeS/GX9Em8tmIDbR9wkOWmHbMtzKQNro4TqKZeobF/+Kpu4arJYjAZd6LhR8n66zlmp43bjUg0pp0BXqSiNmy+uUQt3AhmkrLZlkwHwVKUrLgva9H+QhnpsdTolQhxIUXwWiMyj+QkkwC3szAuMBeCsusaqrtLv22OEBkwAQfQ2Ca8IxrDg47eg5W1KHxrQoudFpeXtxljWEPot3RmIQsF1/HshtR0znNuf9Ap0Bbzh +ref13-ppc64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBLozAs6F6u2ukhKYHCfYKhwI4HAYtDgVU0q0rMieIRaQcsxhN/9jGO6SvLat+iXeHYrwLMD3plgrdcfrso9NJKE= +ref13-ppc64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBYwfwnMSb2jSQn2HDHN8oiiPjaBRK9BnrmvdA12hGpu +ref13-ppc64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClVWjb0QvgK2+rXGBaNJCQiJQtPJHpwGfiQ6Ah0LXEQmdteyojATcueZKW6VnPeuwPfk3bjYFIA14aKWe558RAY218W63UcoivOJhzt4JXxCAPums10mgNCT8PQdEn+hbArUVpXuDm/nNtRyVs034+2g1dD8vK75AWqmGQ12rba8O+e+Ycp+ckAj5Fk95CZdUtM8QtR7svtR5+pkWg61khWTFmL5Qv3Pe++jjse3HeJyfFakWHvIsNYQ6E027BfyRDi7IvYZXHSC4jrAwUg2LWSMLBTKjCog06SzzNi69iuacZJzfC0fFl3EFaeGOwwfOOt1KR46h5XeI54tEXQ389 +ref14-aarch64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDa6TbdzaoSJn54qlYmle3jrrsqEb7CLm0KXsFU+DtCQKOeuYxX2XVLVCyYIabeXFElPZcumY42nyog/ef+3Hsw= +ref14-aarch64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICDgwcnOOPToHDQfGk/AqRen4qUsCpRIU9OlvS0pOSIk +ref14-aarch64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDZK3UpgeeKunMJsDh+LvEoDgyqtxXrhMaYlh99a1Kgm7BR4c62UzUAeGmahHL6/SdTxj0i98DKK9hrM0ahpR8t6fd+TtyGgIOZM15ppb8CQhueIP/m7MmCCJpvqNwTmTLpC5r7qDVapJF13TkuS4mzC6oOfb0LYghfitAIz3dvh7WG2Bof2Q/Z1e9dz47ze+S/pyAJ1DvoVPHZyzT/xJlQko6UTjBxG39tNs+UVhNbOhmFNM+hG1HmsbXmmesNwLDHGwURWO9iFnCek9ErPgfc2JbAj4xaih/3055TuNjB+2igoJyfqTC5GSj5NWOicvSFi+YYEDtJME3nKz6qVZuj +ref14-amd64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAj84PTxbeMMcuXPZns7OM0CmW+QwZ0dGDzAegylkRPmsfMryXZZwlu7AawqHSTd++i2SyCzIjM89N4zbtNtm0o= +ref14-amd64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKhbUj0Pk6/jsGYACO7irSOTvXbbo1gkQs2YXSsjKt8s +ref14-amd64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDClbrTtUv1pw6ryJB/9qt1cN4s8k+JXTcHqQfgLxVx0sLZ3x8O86AvF1j/SQ1HDIdvNFtqM4PRrxBX0E0e52+V7Y15FKMngzOVJ9DzowImpL8yIMSavsAiaijORF/dOGL3+HsugYComQZOfqJN8PNkndwnDIt1qLdxw3YnUxnyQZft7Fi6fOhdbIQBZ1HFeDjvPBCce89awrnDkiXFB1ZZV5m1u3Aj0bdUWCxuTwuwuD4b6/9Buta3cVWvgAh7qYYOYdjDAlOUnHa5zx51QhTM36bz800d0tVFRpBkEVmymQxE8WjDXBuyk4WhP6rEo6zZAsAV0LhbspW8KJXZbYKV +ref14-i386.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMc/l023A4fVFA/ylBcmel3drK8DqSC6xgkLpwXuFt00IuqpFe7vVeyzc3MBbWf1oD0hEgn8REGnM6jQ8WHVUMk= +ref14-i386.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIEtJmB94p4gsInjpWdvEGlgxdqLfWsl5kYllvUIxHpd +ref14-i386.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCm71OMRCmMSsaG7akPqjuQf2CbZ5zl+2bgolE8cNV/uwvBb3vtBEqGykm8bpsmUt2h8AGrV4n9pNGw2wTXrFASZGEePAX/EnzO8+WeZYtbWxRYSnERrVTqvIGYWkUABQglCVgpNc0LOMRdrgKpJo9wre48raKwCygGSvWe4OC0jWAu0FHnWaI4AR0UUTftk6FjE0hrv/rTOeWycaiWfQGP5WF7HkvpED6rSwPzDylIVe8QvH4nmoejG08ATi+pD2YRSf8u9KxwNsxspEvfCHptNmlKS9AZtcVn4stEOIt8F+BUAFeaR19DNhdlxAP6VYfS4bvmstthdgVJgacY6Cah +ref14-ppc64.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEkDw5OBF8pnUbOYInJah30OR5hoGNYVRMzDeprcnLUv8BJnRlHl9j1F2tfdQ/X2zNNKyRHdbAqSUX55l9rtpBU= +ref14-ppc64.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIE0tE8Z3T1m5g+Z9ul+ZlN70ywDivjpeEHvrYTkKzUJi +ref14-ppc64.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4bZXLe8dizCqI7djp+lk2hoeNmgNoK7bjrPCj9CNvHDOWq2IahBvphw1sJyi70snzR35cy+n6zpINz/DHR578tQZoKzWTzKAnOP7siXO7/OSReuHqjnE1Jtjp6YrWA0w5QGT4N/3AHzwOvUOAODU8TSTEL3e302S/rXV568U1RMJ4swVtJCn5HalTlVV9NFkdJsWmgfzM8riv2MHKP07y+pCxP6//C21/Z40KyC7F5fZ36ZtiThpZWbMdoc2mg2lLBOVX1d4tLBYAXSuZAT0QEY4Fp/bFNjbF0x93lS1KPsZla1IdP9CTQ0W2oKH5LySTSRKHyYFTnTvdJEILaQVD +repo.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNT/cpTTWUX3PpuQu43piaqwUgk38rxRf+ln/F7I8mHE+vTA/LjoHxB1Eh9aFa2c7ljcI8GMG3eIUU43Wu3aEmk= +repo.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMRzBZvmnnwNjamH8E5JH8q0BDAgYLgUcFg2I/tFbhf/ +repo.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC46OH12yjSpw+xLiS1Tr+5ZXawxOnR7gwibd+2joF+rvqPlEZ3BxvbP4In6MP56IP1nrPjPhmbRypqlh4i1U+u3t1Otqi1ZhEJOF5+Lyc6prB59x4DyIY/PKIh65VphAaD0RzKfJCRWJvCD84R3KY5GDa9RtIuHmduT9RF4tzs5FZJr+iEGJe88zpPKvlsbWGXH2IYbRUU+VylxMTXMxl1OOMl2PIICMZjmyZgb0TXAh3IAWViFZwsYStzeLvtv8Zb2mQj+w5YFTSgw75+DJZSntS5SU+AMciJ8qQxrDAL3tT8Z1OUWJ1jfnB8SIn6E0G+gYwLGTisEYCi/JUGnYyR +svnrepo.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCYpIsNWM5NsKhXiwPe48FXLXSYteifAYPQMLpSwiQeklv1bnQuMFnb/ASeXipdyoxJBMMEyFSqQ8HJS80F7Ehc= +svnrepo.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOzU38317JG+B+diNuTTXI6tSP/eyiyHsTAZimN97yqJ +svnrepo.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAvnPw8T77uwTMJJTakmWoSA89AtZRi/X5zAFCmfuG9QlofyRa23ktqP0fOxMmFARXRvbVr3pozEl/AP14CZbTxWZYwHAphZd0EcEYgDiW/N75t/ilywWHPXp/IiYQLLL3xeHxNyTNEiodcCLCVUufPyFGfaeBrUw2r3PKNZ7ZwW0UofbbSytJHsk8UVxpjS3RFjxB3daRjrMc/df7xIBPr61bhfxKR+C42K8qX9TqATTFoV9ngNafcfiPRzB9OLZ8sJwLjaV1Tc1lDjUr0nSbcRMr690yQ96O7e+eklze6ocSiglbqtpenPN430Ru0YnDP23u/k2CLHPo3hszHfmCDw== +universe11a.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJc4KVr+j8znE7W0VNnZipLYdu7vPFEDrd1YywkxLopjpni6UhowPtuT6/tr0Twq2Z1hk+i+XDxpzGMim9ya/NQ= +universe11a.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIG+/U6rFvdNzuWJNde5PvNstCjmvzkuA2PnNNkIFDXxm +universe11a.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYnMgYvNWLpkHAKT8dnPmmsYb8TiSzW3wgGes6hd6BIXZoTRWgZPMIQI0iL7SjbLlH26z2IFfflWUxsNKF+wXx8EgXrO4q5bu9xnYAAk7LynXA+5saP6+UTr0UOYWODuZ/823uWVvJffUdDM08grfIOvZRaN3/kRKCKJW8Csw3NVsgzu4AZ45111FGnqgNgSVeXJy9vDKaQRL2eHs5YVFOeyznFxTWc1O1qWYtzIiJLiRjvvAPZqcYxb9YDcrXGXnjO1JehbyQfEDg1fSo7fXR8XE9N6k1prTkAdlk687ixTJTrFJmNNxrNQbdsP4coSihofyy2H+gsdee+AHpaLMj +universe11b.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFn2GTTzn2QYUsrX/o79vra4tEBKMm09ugvKZFzX30mvRxPoIbAwwmEQmae11OcsraGpgsB36dLXSmd5JKjOzLA= +universe11b.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIdRjv1Ye9VDaLgr5mAiZ6h5nii6hmygJHw4ptHJ7ulU +universe11b.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCpyA+VIN7LZdVgZRiQ8yUBNToK4/x9Vp+k363Cbmg5LHLjIMXuFspTs7CVFcl+Gkr9WeFetE3GpanZ0yc5j3ek+MKVoFQ4siRS10SlGlFeGljMF2CdWrIO2sAh9TlUOk2gLBdv8Z64d2Mhlg19jxNbDBHXPIkOo9flbrT3ePLZRPCZMKLeUAhrWCVpN79fA1nZjuDxN3M5Q1pD1FXAC5WzbbZIz4u8Fw9rsXlGQISOlyzswxMxaU8/YonA7uDG+MsB3e/OvuK+XqWManm+YGr3LsfQ/euidJFkCBRd3o7njMAfLPGJo0pHP8EgzLCtsK+3WTUzusSG9btehKu06zOj +universe12a.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBPzA+9uEO99A0pmZE7psusNdP6MJEwA/5DpqSxN1Bv01TNQj4nvEWabXrkQEfxBAEaecLm6YlBJM8HeVtQQp0zo= +universe12a.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIN+0tCdZhNnE89jHIhN3dgpHnGjzcj637NoFcbO6KsFq +universe12a.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDuGfcl5ECKd1FSaMfP9X0qqhpk2/BnTxXzlydFrNoFWkiFOzWM9RGbZNWXb0Ei+GZoAjMb/jrxRONabY0GaLrt+xlNMIkNeITh4+8GhmAJPtZ9PF9IbmIO1evSFe9JKZ53TjLt7Hj13WMJspR5JsJv1b/t1T8UZ4MAPYiHjq3zz2b4K5rq25K46c93gAsNGAw9+qUoQt/RTFzs+LUeLduLHSMYvurB6fkEWC4UGQBqt65bo/9XRocFwTCnEagJsL1Bski4KsKDbwxeEtpESh2SxLF2YbsN1txIdUOrZY9rOiL4Qc64gpkNNJI3ZKwWsPHPuNqxZZJqHt/3nSVYC1ld +universe12b.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMnSryIFNHS7BKCUGq1XwG/ct+Ftgr/tWmgVi4APPQ2J1BB3YSPCHm7hCQbG9NP5KSPcNFG/IqDsiQ2rLQwERQE= +universe12b.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMn2KgjqlbpaEMyi4d8/IU6AbODIyGpZ3485VpBuDoz1 +universe12b.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDA0dd5CsnBIeIeSFtlvG+G0VOuaDAv5X/i/QYHB90V9PTwPAItd3HSuZSbELFI74KCyRK/BEWQD5A2Ci3PeestxuqoAXUTp0X0UTfYNJ3li1kO7hIn2tpqY4eAEZhhL9eaoC3KgNU+doBVPgqHhxPUCwtdYtPStiMx0gqJRSbabb94bkoPM29p3g0gtPpXtuT27mWAVJbfj2LT2f99MTt2taGKKTjVbRresJGPKMt3avPFjHiVEj9v+Upps08nQahSkqlHH/84yaeh/RRfrw59wXDRyOexu4EHqCTUIO4VHpjJrjPg3GSJvh6O+tpslY+9mApcIpXb7dlLZEHhqinn +universe13a.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHG3qzKk5L5OsG358PbFrlv4H9sU8tDcmYTHO3mvAXV41a8dYiais/6vQ1HTQ+Qt4/CCDQzUtBhN3lOASQZTQWM= +universe13a.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIA+nCS3awdGD0ikkuB1U6XK1D9E7JgGj3yBT6BHPG9je +universe13a.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8RZWtfyVkFfdnw5lDFstHyHk4Avrbherew2ff8rRsOOv2TRgH6uyNoQ7aY39lwJEVDjgHlf09pIU0+51akKL4m+Fhe0eHLzTIASuqa5dD1A6+1jlvwDEEO3o9f+rEdPp92dz2aWfc5BPbSq4DO0S9s8eca4sATY1EPuEas/wZ/S0r2v+QRIg2UIngGQ4EjzvobET3wnMds05iO0nLkGoCF84uX3Fg1i4Qyf33Z1+XYQ0aZ6REO1dBrmZhaXXulmb7xzzUwsA5FmsCPVPji5IPvHRnAoGC0EW+WK0vG0JQnM/bu3SqJi3Lxne9li64c+SAasvXs8Qm5tlpBUJCs87Z +universe13b.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOvWMX3Rp8ANOxAHGM/bvRtZdDTJzhxkaaev5Q8FhkVK9VGXuxcet8+gAEj6P3h8Y5kqEqMvvqPHQeDYtdOV/eM= +universe13b.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINmnwPp9p9aDNdl01rFHOlcuOJ1yqfjYlM95cLK9bP/t +universe13b.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDSqVoh2uDijYLWZAlzg++k1A/H+biWbyURcngKKo12IPOax9hqUicJ66z6pSGyBnhpAqek8bkXcFdyiRF0RnI76vpxiMuiAyxs9rWMfm+4c5MbKOSyaFQhnf7GCXBNWKOQi4gmyh3LvDhCv5/OlEVYryUNanO1OVLOz2hSaRLJopX5c3fDZnm4tflgY8vwkkEEW8gn7uFUYVFqBU5Sx6GgwpMEuEt/opiwEihVQTykVvX0HI4yF+47q25wMfAsSTr0lel2Fs/7beUt3htcL4QuKScIJ98AK2gseCx1rd8xDBn2AHDrnSLjYJ2A9lonljFaSLUs8AuvijAh4micwiDR +universe14a.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDhrhiPFhxL9BZEUfHBPVBJWbJbz/LdCwOaDxAMhjrwOxGmxp9jIKgdJeHWGaXk3+s18y3/gwJDrvWcrXbL/7hk= +universe14a.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBEbzlQ1Vg4Ac27EBkyszHqNzLWZr54yJxZfBg2VY/kx +universe14a.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8/rfquObUgFmfAeyQNAzRA/JYVVjd5bIEGxf8irByVJzivqNVtS9LpvougaykXT9xpfPKPFlVQuROyOGNuk6O/22ILvyialj2IfYU1habdrC+XX4ICt74ndma+p0Qtb2vslmS4g7BnvxAsW8TOeqmcjQkbDQIexr9RslqCLOMlwks3SCUq1QvTtMIDKddHbh+8Ka5VhUXKloh/kkj6WjIw5yoQi4bmq0IzRRo8+VFXAaptcZCY2r7B8/H8oGJ1MbVVQ6ex94/Z8JWMsGa9PYWvQaNIFbje891Eed3tdvXTLAZkIBQbx+9ZAOpU+V37i0mPXe9P2+YEiVGbnpbsI3D +universe14b.freebsd.org ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNr1MNeRcs+VKB+oqNGYTZG4HQS4qh4lB7hcwLU7MvuK//ytlPBiuIz5NurYUdOPfUTO5Z2Ixq9RFfjSNS6f2S4= +universe14b.freebsd.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDN4P1oVzwsYPjblyrHCqFiqqe/FNec4nfEVFiwdk7H6 +universe14b.freebsd.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDe1IZMN8FRP86VfwYTDlR1oNxu5PQirS41tLdixvKAYylQzyEOhmKcBIJRJT1/KmLq6nq3hXHfCyV+sC9HdH6KQmB9tXXWRl6jCyDuF1Lrr4ZV8AQX0kHrcEeL7aqoubUpVeM32UusiXcQQVE/96jP/4gOc7Y+axqw+ZBXmJPubg+/Lwt0WMu43kE+Jp2ZYuFUp04jd3zp/exEWr5kRlbrdCfNurQieRkxhKhx3eLYEv5IkixFEhFt4v9Xu93N/W6KSG85b1WNIAW6cmJcLWTJz/LMyijnDmleNY0etDPnJhoarqH1mfzQxYSMWkN1wxEmuP5WGi1K0fV/t0leNZfx -----BEGIN PGP SIGNATURE----- -iQIzBAEBCgAdFiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAl/o75kACgkQ05eS9J6n -5cJaIQ//bLjdgbOYounWergTcAHUPnwsCtNnOq8zH2iMFPXcjlqXSXVeh1/PCjS2 -hsKZhmeW3cwSMVDN9deMPj5jztsuDfs1nIMnwOCJlFdEBCzjr9aeXQz/3jPx4MW9 -O2xMFN0FGr3E/WEXdj9QL5mS5k1M/AJO6dFe2QdNKBxuhXCINtEre2iZDkfOygJ6 -ZlU/1Gj7XAXFC5QSd6owxy7rtE7RVN2f6mc4V3y0U1GBWx4Ha1b5rrK6sRYx+mqd -EjyyT2+yCUCqNtLWPGMA3EX+xFtsTkT9YmVt0GtHHKqnFEhBVUq1BfkzGDitqu6y -NA6fvVS4NYmwyN6V/G7OHicyJ8wdRJJSwzFx1CvU/i4BfbQ+bNEZTreu3L5doEQa -8MA8aGGZ26gl/Giz1BEAjdg6Pv5TdNRMLdL5ibNaeuuqcs7MpdPiDViv88vRJx4E -YnlBNjdWabvPfgkFRuN4XTlyEoq9Nwkfy61Z3UuUs7IHmpJwRaNNwMYoFyAqxttO -5GyTf1uKvRUWaKtDTvrhJ76vPJpNnGQncg4My28aYsRjZYjm0P4RYG6Ve3fy0TkF -HCrilTO8/wLwsZ3WE4vOXa+75H4j1rV/M/tB/ERQzl3iQHOueyg+8dwa8ZyyBEvQ -syEoe6qVdYelFmQ3ISHoMj4rhrJJsLS2efxrsgco8yViPkD0xL4= -=tlEl +iQIzBAEBCgAdFiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAmClHt8ACgkQ05eS9J6n +5cLWyRAAi1k6/G6NeBEzsBDZ9s7/CadVJ79BuuyBqthPJXQDY4xWHY8eepv6Kq+u +rPIAwbtqDG8gBBDyCa6y9XNm5ahN5WtUIzLgx2WeRBJA871hvHi0buLEECaiVe3m +ZH5W/s21XhEU1f9jdzhCcDLob+HyroZA42AyRJDb4HCG9R4nZKNiyEmeiBDUu/dC +QvrbJWpwdSlTVb1SVZlQG4k7yE2lP5oarKoT+3RopQC0qH3VvuTFGZnhgGp0a/ZB +1ur/ydGrMstalblsf6kbkehsTZGYkjRbB+l31NobipIcn5AbwRn/dciqFOrgjgE2 +C9rIhLOTi8IzRHucHVvKdLO9LZ2unRvFvu95bQTcpGwr1DjCBnXxWPVuQhLNT1KC +a3whu2MWHusAvz/g+MmSOZMeSRGx0y7y4YdDVWycvziHOuNTWjESSmRdgnJyO+U0 +BLw+ZEXTSPXBu+dSmHvUsu7zVuE6fTKnsJLR1jhuD+n8z0NFoWzsprJ7VcVZ/20H +Bda57RP8brQJJBfwq1B+yZ6fAMp7hhrNoSL1rj6VUVquCjmKvhgslvFKY4l22wMu +hAXjEWrYxGIU0xN+T9JEIGmXJ9OiHoSHy2Pn/rmlUFQrfhzLaKEaqUtD/DJG/E9z +rd9fezL4qKe4dMbPZRU7zUhwElhaZki/65/laOVkE1w36D3tb/o= +=22aB -----END PGP SIGNATURE----- From owner-dev-commits-doc-all@freebsd.org Thu May 20 16:08:11 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7788E642E00 for ; Thu, 20 May 2021 16:08:11 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FmF5R2dftz3FyH; Thu, 20 May 2021 16:08:11 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 42A6C2918F; Thu, 20 May 2021 16:08:11 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14KG8Bdm090813; Thu, 20 May 2021 16:08:11 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14KG8BIv090812; Thu, 20 May 2021 16:08:11 GMT (envelope-from git) Date: Thu, 20 May 2021 16:08:11 GMT Message-Id: <202105201608.14KG8BIv090812@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Marc Fonvieille Subject: git: a941530652 - main - fr/articles: Fix include paths MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: blackend X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: a941530652d14ef540b12be2a16ac9e78a0acf65 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2021 16:08:11 -0000 The branch main has been updated by blackend: URL: https://cgit.FreeBSD.org/doc/commit/?id=a941530652d14ef540b12be2a16ac9e78a0acf65 commit a941530652d14ef540b12be2a16ac9e78a0acf65 Author: Marc Fonvieille AuthorDate: 2021-05-20 16:07:04 +0000 Commit: Marc Fonvieille CommitDate: 2021-05-20 16:07:04 +0000 fr/articles: Fix include paths --- .../fr/articles/building-products/_index.adoc | 7 +++-- .../fr/articles/filtering-bridges/_index.adoc | 10 ++++++++ .../content/fr/articles/ipsec-must/_index.adoc | 10 ++++++++ .../content/fr/articles/leap-seconds/_index.adoc | 10 ++++++++ .../content/fr/articles/linux-users/_index.adoc | 10 ++++++++ .../content/fr/articles/nanobsd/_index.adoc | 10 ++++++++ .../content/fr/articles/new-users/_index.adoc | 10 ++++++++ documentation/content/fr/articles/pam/_index.adoc | 30 ++++++++++++++++++++++ 8 files changed, 95 insertions(+), 2 deletions(-) diff --git a/documentation/content/fr/articles/building-products/_index.adoc b/documentation/content/fr/articles/building-products/_index.adoc index 97c3cf21e5..28622f82b5 100644 --- a/documentation/content/fr/articles/building-products/_index.adoc +++ b/documentation/content/fr/articles/building-products/_index.adoc @@ -25,15 +25,18 @@ trademarks: ["freebsd", "general"] :table-caption: Tableau :example-caption: Exemple + +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] include::shared/fr/mailing-lists.adoc[] include::shared/releases.adoc[] - -ifeval::["{backend}" == "html5"] :imagesdir: ../../../images/articles/building-products/ endif::[] ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/mailing-lists.adoc[] +include::../../../../shared/fr/urls.adoc[] +include::../../../../shared/releases.adoc[] :imagesdir: ../../../../static/images/articles/building-products/ endif::[] diff --git a/documentation/content/fr/articles/filtering-bridges/_index.adoc b/documentation/content/fr/articles/filtering-bridges/_index.adoc index 54a3ebe520..dfd3acd4eb 100644 --- a/documentation/content/fr/articles/filtering-bridges/_index.adoc +++ b/documentation/content/fr/articles/filtering-bridges/_index.adoc @@ -23,7 +23,17 @@ trademarks: ["freebsd", "3com", "intel", "general"] :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/fr/urls.adoc[] +endif::[] [.abstract-title] Résumé diff --git a/documentation/content/fr/articles/ipsec-must/_index.adoc b/documentation/content/fr/articles/ipsec-must/_index.adoc index a1cd459988..d6d0ea1c06 100644 --- a/documentation/content/fr/articles/ipsec-must/_index.adoc +++ b/documentation/content/fr/articles/ipsec-must/_index.adoc @@ -23,7 +23,17 @@ trademarks: ["freebsd", "opengroup", "general"] :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/fr/urls.adoc[] +endif::[] [.abstract-title] Résumé diff --git a/documentation/content/fr/articles/leap-seconds/_index.adoc b/documentation/content/fr/articles/leap-seconds/_index.adoc index 37195ed707..19bc5b27f9 100644 --- a/documentation/content/fr/articles/leap-seconds/_index.adoc +++ b/documentation/content/fr/articles/leap-seconds/_index.adoc @@ -19,7 +19,17 @@ releaseinfo: "$FreeBSD$" :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/fr/urls.adoc[] +endif::[] ''' diff --git a/documentation/content/fr/articles/linux-users/_index.adoc b/documentation/content/fr/articles/linux-users/_index.adoc index 42be916d26..e6b6c1a487 100644 --- a/documentation/content/fr/articles/linux-users/_index.adoc +++ b/documentation/content/fr/articles/linux-users/_index.adoc @@ -23,7 +23,17 @@ trademarks: ["freebsd", "intel", "redhat", "linux", "unix", "general"] :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/fr/urls.adoc[] +endif::[] [.abstract-title] Résumé diff --git a/documentation/content/fr/articles/nanobsd/_index.adoc b/documentation/content/fr/articles/nanobsd/_index.adoc index 5e5fa26547..b81e5863e4 100644 --- a/documentation/content/fr/articles/nanobsd/_index.adoc +++ b/documentation/content/fr/articles/nanobsd/_index.adoc @@ -23,7 +23,17 @@ trademarks: ["freebsd", "general"] :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +endif::[] [.abstract-title] Résumé diff --git a/documentation/content/fr/articles/new-users/_index.adoc b/documentation/content/fr/articles/new-users/_index.adoc index 321aafcba5..1afdde681b 100644 --- a/documentation/content/fr/articles/new-users/_index.adoc +++ b/documentation/content/fr/articles/new-users/_index.adoc @@ -23,7 +23,17 @@ trademarks: ["freebsd", "ibm", "microsoft", "opengroup", "general"] :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/fr/urls.adoc[] +endif::[] [.abstract-title] Résumé diff --git a/documentation/content/fr/articles/pam/_index.adoc b/documentation/content/fr/articles/pam/_index.adoc index ec5fc6d248..8daeac087b 100644 --- a/documentation/content/fr/articles/pam/_index.adoc +++ b/documentation/content/fr/articles/pam/_index.adoc @@ -515,7 +515,17 @@ Ce qui suit est une implémentation minimale de man:su[1] en utilisant PAM. Note [.programlisting] .... +ifeval::["{backend}" == "html5"] include::static/source/articles/pam/su.c[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../static/source/articles/pam/su.c[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../static/source/articles/pam/su.c[] +endif::[] .... :sectnums!: @@ -528,7 +538,17 @@ Ce qui suit est une implémentation minimale de man:pam_unix[8] offrant uniqueme [.programlisting] .... +ifeval::["{backend}" == "html5"] include::static/source/articles/pam/pam_unix.c[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../static/source/articles/pam/pam_unix.c[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../static/source/articles/pam/pam_unix.c[] +endif::[] .... :sectnums!: @@ -541,7 +561,17 @@ La fonction de conversation présentée ci-dessous est une version grandement si [.programlisting] .... +ifeval::["{backend}" == "html5"] include::static/source/articles/pam/converse.c[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../static/source/articles/pam/converse.c[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../static/source/articles/pam/converse.c[] +endif::[] .... :sectnums!: From owner-dev-commits-doc-all@freebsd.org Fri May 21 00:31:18 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D336C64C53D for ; Fri, 21 May 2021 00:31:18 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FmSFy5c8Fz3Lq6; Fri, 21 May 2021 00:31:18 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A7D162F9CC; Fri, 21 May 2021 00:31:18 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14L0VI1G061080; Fri, 21 May 2021 00:31:18 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14L0VIDx061079; Fri, 21 May 2021 00:31:18 GMT (envelope-from git) Date: Fri, 21 May 2021 00:31:18 GMT Message-Id: <202105210031.14L0VIDx061079@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Philip Paeps Subject: git: cef98ab883 - main - fingerprints.cgi: add git.freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: philip X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: cef98ab883e29b99acd8a7fa64dd5e562c217c5c Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 00:31:18 -0000 The branch main has been updated by philip (ports, src committer): URL: https://cgit.FreeBSD.org/doc/commit/?id=cef98ab883e29b99acd8a7fa64dd5e562c217c5c commit cef98ab883e29b99acd8a7fa64dd5e562c217c5c Author: Philip Paeps AuthorDate: 2021-05-21 00:30:32 +0000 Commit: Philip Paeps CommitDate: 2021-05-21 00:30:32 +0000 fingerprints.cgi: add git.freebsd.org Note that svn.freebsd.org is still relevant for stable/11 and stable/12. --- website/content/en/cgi/fingerprints.cgi | 1 + 1 file changed, 1 insertion(+) diff --git a/website/content/en/cgi/fingerprints.cgi b/website/content/en/cgi/fingerprints.cgi index 2dd58ce23d..bc99be8985 100755 --- a/website/content/en/cgi/fingerprints.cgi +++ b/website/content/en/cgi/fingerprints.cgi @@ -20,6 +20,7 @@ print qq{

FreeBSD HTTPS/SSL/TLS Server Certificate Fingerprints

\n}; print qq{

The FreeBSD Project makes use of Let's Encrypt certificates for many of its HTTPS/SSL/TLS services. These certificates are automatically updated every 60 days. The current certificate fingerprints of significant services are listed below.

\n}; # Note: These are all case sensitive. Use lower case to match the file names. +&Fingerprint('git.freebsd.org'); &Fingerprint('svn.freebsd.org'); &Fingerprint('download.freebsd.org'); &Fingerprint('pkg.freebsd.org'); From owner-dev-commits-doc-all@freebsd.org Fri May 21 10:28:13 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 21B9F656992 for ; Fri, 21 May 2021 10:28:13 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FmjVj0SfZz3tPW; Fri, 21 May 2021 10:28:13 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E83197845; Fri, 21 May 2021 10:28:12 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14LASCsd051095; Fri, 21 May 2021 10:28:12 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14LASCpa051094; Fri, 21 May 2021 10:28:12 GMT (envelope-from git) Date: Fri, 21 May 2021 10:28:12 GMT Message-Id: <202105211028.14LASCpa051094@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: =?utf-8?B?RmVybmFuZG8gQXBlc3RlZ3XDrWE=?= Subject: git: 17f753900c - main - Replace references to svnadmin branch MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: fernape X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 17f753900c2530abaa1d6953582a4ffe203bdc0f Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 10:28:13 -0000 The branch main has been updated by fernape: URL: https://cgit.FreeBSD.org/doc/commit/?id=17f753900c2530abaa1d6953582a4ffe203bdc0f commit 17f753900c2530abaa1d6953582a4ffe203bdc0f Author: Fernando Apesteguía AuthorDate: 2021-04-22 13:30:28 +0000 Commit: Fernando Apesteguía CommitDate: 2021-05-21 10:24:14 +0000 Replace references to svnadmin branch In committers-guide, handbook and the new-account page in the website. There were references to the old `svnadmin` branch. Approved by: 0mp (mentor) Differential Revision: https://reviews.freebsd.org/D29922 --- .../content/en/articles/committers-guide/_index.adoc | 19 +++---------------- .../content/en/books/handbook/mirrors/_index.adoc | 1 + website/content/en/internal/new-account.adoc | 10 +++++++--- 3 files changed, 11 insertions(+), 19 deletions(-) diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc index e1ea6a26d6..540a408a51 100644 --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -2429,22 +2429,9 @@ The mentor is also personally responsible for the mentee's actions during this i For committers: do not commit anything without first getting mentor approval. Document that approval with an `Approved by:` line in the commit message. -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#. -This file is in the [.filename]#svnadmin# branch of each repository: - -[.informaltable] -[cols="1,1", frame="none"] -|=== - -|`src` -|[.filename]#base/svnadmin/conf/mentors# - -|`doc` -|[.filename]#doc/svnadmin/conf/mentors# - -|`ports` -|[.filename]#ports/svnadmin/conf/mentors# -|=== +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]#mentors#. +This file is in the [.filename]#admin# orphan branch of each repository. +Detailed information on how to access these branches can be found in link:{handbook}mirror/#admin-branch["admin" branch]. [[pre-commit-review]] == Pre-Commit Review diff --git a/documentation/content/en/books/handbook/mirrors/_index.adoc b/documentation/content/en/books/handbook/mirrors/_index.adoc index 736314acf7..c2ef4eb4d9 100644 --- a/documentation/content/en/books/handbook/mirrors/_index.adoc +++ b/documentation/content/en/books/handbook/mirrors/_index.adoc @@ -627,6 +627,7 @@ Again, note that `gitrepo.freebsd.org` will be canonicalized to `repo.freebsd.or % chmod 755 .git/hooks/prepare-commit-msg .... +[[admin-branch]] ==== "admin" branch The `access` and `mentors` files are stored in an orphan branch, `internal/admin`, in each repository. diff --git a/website/content/en/internal/new-account.adoc b/website/content/en/internal/new-account.adoc index 530db544c1..fc368068b3 100644 --- a/website/content/en/internal/new-account.adoc +++ b/website/content/en/internal/new-account.adoc @@ -55,7 +55,9 @@ accounts@ creates the new account with the above information on the FreeBSD.org == Mentor Activates New Committer's Commit Bit -After the new committer confirms that the account works, the mentor adds the new committer to the correct `access` file, using an appropriate commit message. The commit message should at least contain the committer's full name and username, the mentor's name and what area the new committer will start to work in. An entry should also be added to the `mentors` file in the respective Git repository to indicate the mentor relationship. Having done all that, the new committer and mentor jointly go through the first commit operations. +After the new committer confirms that the account works, the mentor adds the new committer to the correct `access` file, using an appropriate commit message. The commit message should at least contain the committer's full name and username, the mentor's name and what area the new committer will start to work in. +An entry should also be added to the `mentors` file in the respective link:{handbook}mirror/#admin-branch[Git repository] to indicate the mentor relationship. +Having done all that, the new committer and mentor jointly go through the first commit operations. == Additional Services @@ -65,8 +67,10 @@ Reading the link:{committers-guide}[Committer's Guide] is considered a good firs == End Of Mentorship -There is no pre-set duration for a mentorship. Once the mentor feels the mentee is ready to 'fly solo' the mentor notifies the developer community by removing the entry from the `mentors` file in Git. +There is no pre-set duration for a mentorship. +Once the mentor feels the mentee is ready to 'fly solo' the mentor notifies the developer community by removing the entry from the `mentors` file in Git. == Transfer Of Mentorship -Should a need arise to transfer mentorship for a committer please email the responsible party, as described for a new account proposal. Typically this request is rubberstamped as-is. In Git, the `mentors` file should be updated. +Should a need arise to transfer mentorship for a committer please email the responsible party, as described for a new account proposal. Typically this request is rubberstamped as-is. +In Git, the `mentors` file should be updated. From owner-dev-commits-doc-all@freebsd.org Fri May 21 16:58:48 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D5D1A6379D9 for ; Fri, 21 May 2021 16:58:48 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fmt9N5bv8z4Rhc; Fri, 21 May 2021 16:58:48 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A0D811510B; Fri, 21 May 2021 16:58:48 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14LGwmTG071054; Fri, 21 May 2021 16:58:48 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14LGwmLl071053; Fri, 21 May 2021 16:58:48 GMT (envelope-from git) Date: Fri, 21 May 2021 16:58:48 GMT Message-Id: <202105211658.14LGwmLl071053@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Ceri Davies Subject: git: 8d25cf749a - main - books/fdp-primer: Fix table of contents in PDF build MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ceri X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 8d25cf749a208fbb584737c19589cd04cbdde3ab Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 16:58:48 -0000 The branch main has been updated by ceri: URL: https://cgit.FreeBSD.org/doc/commit/?id=8d25cf749a208fbb584737c19589cd04cbdde3ab commit 8d25cf749a208fbb584737c19589cd04cbdde3ab Author: Ceri Davies AuthorDate: 2021-05-21 16:54:22 +0000 Commit: Ceri Davies CommitDate: 2021-05-21 16:54:22 +0000 books/fdp-primer: Fix table of contents in PDF build A PDF build fails to find the correct include files for the table of contents and, for reasons not well understood, installs a duplicate table of contents on top of the text in the Overview chapter. Fix that. Approved by: blackend (mentor) --- documentation/content/en/books/fdp-primer/book.adoc | 6 +++--- documentation/content/en/books/fdp-primer/overview/_index.adoc | 2 -- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/documentation/content/en/books/fdp-primer/book.adoc b/documentation/content/en/books/fdp-primer/book.adoc index 63157028a6..4e0466a240 100644 --- a/documentation/content/en/books/fdp-primer/book.adoc +++ b/documentation/content/en/books/fdp-primer/book.adoc @@ -71,11 +71,11 @@ This is a work in progress. Corrections and additions are always welcome. toc::[] -include::content/en/books/fdp-primer/toc-figures.adoc[] +include::{chapters-path}toc-figures.adoc[] -include::content/en/books/fdp-primer/toc-tables.adoc[] +include::{chapters-path}toc-tables.adoc[] -include::content/en/books/fdp-primer/toc-examples.adoc[] +include::{chapters-path}toc-examples.adoc[] :sectnums!: diff --git a/documentation/content/en/books/fdp-primer/overview/_index.adoc b/documentation/content/en/books/fdp-primer/overview/_index.adoc index 77623625fb..10551ad3a2 100644 --- a/documentation/content/en/books/fdp-primer/overview/_index.adoc +++ b/documentation/content/en/books/fdp-primer/overview/_index.adoc @@ -25,8 +25,6 @@ tags: ["overview", "FreeBSD Documentation Project", "quick start"] include::shared/releases.adoc[] include::shared/en/mailing-lists.adoc[] -toc::[] - Welcome to the FreeBSD Documentation Project (FDP). Quality documentation is crucial to the success of FreeBSD, and we value your contributions very highly. From owner-dev-commits-doc-all@freebsd.org Fri May 21 17:03:57 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7AFBA637AE0 for ; Fri, 21 May 2021 17:03:57 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FmtHK2rkTz4TwQ; Fri, 21 May 2021 17:03:57 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4A09115318; Fri, 21 May 2021 17:03:57 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14LH3vPA084442; Fri, 21 May 2021 17:03:57 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14LH3vxg084441; Fri, 21 May 2021 17:03:57 GMT (envelope-from git) Date: Fri, 21 May 2021 17:03:57 GMT Message-Id: <202105211703.14LH3vxg084441@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Marc Fonvieille Subject: git: cc90951c14 - main - fr/articles: Fix include paths MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: blackend X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: cc90951c140d7c7820457c9c8f452a124d0bf6a9 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 17:03:57 -0000 The branch main has been updated by blackend: URL: https://cgit.FreeBSD.org/doc/commit/?id=cc90951c140d7c7820457c9c8f452a124d0bf6a9 commit cc90951c140d7c7820457c9c8f452a124d0bf6a9 Author: Marc Fonvieille AuthorDate: 2021-05-21 17:01:29 +0000 Commit: Marc Fonvieille CommitDate: 2021-05-21 17:03:23 +0000 fr/articles: Fix include paths --- .../content/fr/articles/committers-guide/_index.adoc | 14 ++++++++++++++ documentation/content/fr/articles/contributing/_index.adoc | 12 ++++++++++++ 2 files changed, 26 insertions(+) diff --git a/documentation/content/fr/articles/committers-guide/_index.adoc b/documentation/content/fr/articles/committers-guide/_index.adoc index a9754036fb..99d34e26f8 100644 --- a/documentation/content/fr/articles/committers-guide/_index.adoc +++ b/documentation/content/fr/articles/committers-guide/_index.adoc @@ -23,9 +23,23 @@ trademarks: ["freebsd", "coverity", "ibm", "intel", "sparc", "general"] :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] include::shared/fr/mailing-lists.adoc[lines=11..-1] include::shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/fr/mailing-lists.adoc[lines=11..-1] +include::../../../../shared/fr/urls.adoc[] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/authors.adoc[] +include::../../../../shared/fr/mailing-lists.adoc[lines=11..-1] +include::../../../../shared/fr/urls.adoc[] +endif::[] [.abstract-title] Résumé diff --git a/documentation/content/fr/articles/contributing/_index.adoc b/documentation/content/fr/articles/contributing/_index.adoc index 2314933dab..2abb4b80d9 100644 --- a/documentation/content/fr/articles/contributing/_index.adoc +++ b/documentation/content/fr/articles/contributing/_index.adoc @@ -22,8 +22,20 @@ trademarks: ["freebsd", "ieee", "general"] :table-caption: Tableau :example-caption: Exemple +ifeval::["{backend}" == "html5"] include::shared/fr/urls.adoc[] include::shared/fr/mailing-lists.adoc[lines=11..-1] +endif::[] + +ifeval::["{backend}" == "pdf"] +include::../../../../shared/fr/urls.adoc[] +include::../../../../shared/fr/mailing-lists.adoc[lines=11..-1] +endif::[] + +ifeval::["{backend}" == "epub3"] +include::../../../../shared/fr/urls.adoc[] +include::../../../../shared/fr/mailing-lists.adoc[lines=11..-1] +endif::[] [.abstract-title] Résumé From owner-dev-commits-doc-all@freebsd.org Sat May 22 01:54:36 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6563C640DF9 for ; Sat, 22 May 2021 01:54:36 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fn63c2Rt9z4j3g; Sat, 22 May 2021 01:54:36 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 3C2F41C221; Sat, 22 May 2021 01:54:36 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14M1sage087823; Sat, 22 May 2021 01:54:36 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14M1sa4a087822; Sat, 22 May 2021 01:54:36 GMT (envelope-from git) Date: Sat, 22 May 2021 01:54:36 GMT Message-Id: <202105220154.14M1sa4a087822@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Allan Jude Subject: git: 474a63dc78 - main - porters-handbook: Fix a broken link from Chapter 2 to Chapter 11 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: allanjude X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 474a63dc789a9debcaec1c84cf45db204c8ff1aa Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2021 01:54:36 -0000 The branch main has been updated by allanjude: URL: https://cgit.FreeBSD.org/doc/commit/?id=474a63dc789a9debcaec1c84cf45db204c8ff1aa commit 474a63dc789a9debcaec1c84cf45db204c8ff1aa Author: Allan Jude AuthorDate: 2021-05-22 01:52:35 +0000 Commit: Allan Jude CommitDate: 2021-05-22 01:52:35 +0000 porters-handbook: Fix a broken link from Chapter 2 to Chapter 11 The name of the section changes, and the crossref needed updating PR: 256065 Reported by: isak@prehosp.se Sponsored by: Klara Inc. --- documentation/content/en/books/porters-handbook/new-port/_index.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/content/en/books/porters-handbook/new-port/_index.adoc b/documentation/content/en/books/porters-handbook/new-port/_index.adoc index ce324731fd..996d9b81fe 100644 --- a/documentation/content/en/books/porters-handbook/new-port/_index.adoc +++ b/documentation/content/en/books/porters-handbook/new-port/_index.adoc @@ -33,7 +33,7 @@ toc::[] Interested in making a new port, or upgrading existing ports? Great! -What follows are some guidelines for creating a new port for FreeBSD. To upgrade an existing port, read this, then read crossref:port-upgrading[port-upgrading,Upgrading a Port]. +What follows are some guidelines for creating a new port for FreeBSD. To upgrade an existing port, read this, then read crossref:upgrading[preamble,Upgrading a Port]. When this document is not sufficiently detailed, refer to [.filename]#/usr/ports/Mk/bsd.port.mk#, which is included by all port [.filename]#Makefiles#. Even those not hacking [.filename]##Makefile##s daily can gain much knowledge from it. Additionally, specific questions can be sent to the {freebsd-ports}. From owner-dev-commits-doc-all@freebsd.org Sat May 22 21:28:36 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BFF32637CD8 for ; Sat, 22 May 2021 21:28:36 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fnc6D4wzFz3H89; Sat, 22 May 2021 21:28:36 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9234836BB; Sat, 22 May 2021 21:28:36 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14MLSaIo047559; Sat, 22 May 2021 21:28:36 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14MLSalE047558; Sat, 22 May 2021 21:28:36 GMT (envelope-from git) Date: Sat, 22 May 2021 21:28:36 GMT Message-Id: <202105222128.14MLSalE047558@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Ceri Davies Subject: git: e697386cd9 - main - books/handbook: fix incorrect output shown in an example MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ceri X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: e697386cd9505cf71ec17ca2bf5eba5585bbc09f Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2021 21:28:36 -0000 The branch main has been updated by ceri: URL: https://cgit.FreeBSD.org/doc/commit/?id=e697386cd9505cf71ec17ca2bf5eba5585bbc09f commit e697386cd9505cf71ec17ca2bf5eba5585bbc09f Author: Ceri Davies AuthorDate: 2021-05-22 21:26:02 +0000 Commit: Ceri Davies CommitDate: 2021-05-22 21:28:18 +0000 books/handbook: fix incorrect output shown in an example "pgrep -l" does not show arguments. Approved by: blackend (mentor) --- documentation/content/en/books/handbook/basics/_index.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/content/en/books/handbook/basics/_index.adoc b/documentation/content/en/books/handbook/basics/_index.adoc index 0d787495cf..3755b4a547 100644 --- a/documentation/content/en/books/handbook/basics/_index.adoc +++ b/documentation/content/en/books/handbook/basics/_index.adoc @@ -1283,7 +1283,7 @@ This example shows how to send a signal to man:inetd[8]. The man:inetd[8] config [source,shell] .... % pgrep -l inetd -198 inetd -wW +198 inetd .... + . Use man:kill[1] to send the signal. As man:inetd[8] is owned by `root`, use man:su[1] to become `root` first. From owner-dev-commits-doc-all@freebsd.org Sun May 23 15:21:13 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 536BC649A73 for ; Sun, 23 May 2021 15:21:13 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fp3vs1ttFz4YrB; Sun, 23 May 2021 15:21:13 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 283E5196D5; Sun, 23 May 2021 15:21:13 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14NFLDbD083461; Sun, 23 May 2021 15:21:13 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14NFLD0k083460; Sun, 23 May 2021 15:21:13 GMT (envelope-from git) Date: Sun, 23 May 2021 15:21:13 GMT Message-Id: <202105231521.14NFLD0k083460@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Ceri Davies Subject: git: 7c1856c004 - main - articles/[contributors, pgpkeys]: Correct include paths MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ceri X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 7c1856c004f27e6de26a147f1bfb7bf481d67abc Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 15:21:13 -0000 The branch main has been updated by ceri: URL: https://cgit.FreeBSD.org/doc/commit/?id=7c1856c004f27e6de26a147f1bfb7bf481d67abc commit 7c1856c004f27e6de26a147f1bfb7bf481d67abc Author: Ceri Davies AuthorDate: 2021-05-23 15:18:25 +0000 Commit: Ceri Davies CommitDate: 2021-05-23 15:18:25 +0000 articles/[contributors,pgpkeys]: Correct include paths A PDF build shows errors associated with incorrect include paths for these articles, so fix them. Also update the guidance on adding a pgpkey to the new required format. Reported by: dbaio Approved by: blackend (mentor) --- .../content/en/articles/contributors/_index.adoc | 17 +- .../content/en/articles/pgpkeys/_index.adoc | 1169 ++++++++++---------- documentation/static/pgpkeys/README | 2 +- 3 files changed, 597 insertions(+), 591 deletions(-) diff --git a/documentation/content/en/articles/contributors/_index.adoc b/documentation/content/en/articles/contributors/_index.adoc index a3f7fd0652..5309b2b062 100644 --- a/documentation/content/en/articles/contributors/_index.adoc +++ b/documentation/content/en/articles/contributors/_index.adoc @@ -18,16 +18,19 @@ tags: ["Contributors", "FreeBSD", "individuals", "organizations"] ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] include::shared/en/urls.adoc[] +:include-path: content/en/articles/contributors/ endif::[] ifeval::["{backend}" == "pdf"] include::../../../../shared/authors.adoc[] include::../../../../shared/en/urls.adoc[] +:include-path: endif::[] ifeval::["{backend}" == "epub3"] include::../../../../shared/authors.adoc[] include::../../../../shared/en/urls.adoc[] +:include-path: endif::[] [.abstract-title] @@ -114,7 +117,7 @@ All core team members are also developers. (in alphabetical order by last name): -include::content/en/articles/contributors/contrib-committers.adoc[] +include::{include-path}contrib-committers.adoc[] [[contrib-corealumni]] == Core Team Alumni @@ -124,7 +127,7 @@ We thank them for their past efforts in the service of the FreeBSD project. _In rough reverse chronological order:_ -include::content/en/articles/contributors/contrib-corealumni.adoc[] +include::{include-path}contrib-corealumni.adoc[] [[contrib-develalumni]] == Development Team Alumni @@ -134,7 +137,7 @@ We thank them for their past efforts in the service of the FreeBSD project. _In rough reverse chronological order:_ -include::content/en/articles/contributors/contrib-develalumni.adoc[] +include::{include-path}contrib-develalumni.adoc[] [[contrib-portmgralumni]] == Ports Management Team Alumni @@ -144,7 +147,7 @@ We thank them for their past efforts in the service of the FreeBSD project. _In rough reverse chronological order:_ -include::content/en/articles/contributors/contrib-portmgralumni.adoc[] +include::{include-path}contrib-portmgralumni.adoc[] [[contrib-develinmemoriam]] == Development Team: In Memoriam @@ -154,7 +157,7 @@ Here are some remembrances. _In rough reverse chronological order of their passing:_ -include::content/en/articles/contributors/contrib-develinmemoriam.adoc[] +include::{include-path}contrib-develinmemoriam.adoc[] [[contrib-derived]] == Derived Software Contributors @@ -169,11 +172,11 @@ There are also portions of NetBSD and OpenBSD that have been integrated into Fre (in alphabetical order by first name): -include::content/en/articles/contributors/contrib-additional.adoc[] +include::{include-path}contrib-additional.adoc[] [[contrib-386bsd]] == 386BSD Patch Kit Patch Contributors (in alphabetical order by first name): -include::content/en/articles/contributors/contrib-386bsd.adoc[] +include::{include-path}contrib-386bsd.adoc[] diff --git a/documentation/content/en/articles/pgpkeys/_index.adoc b/documentation/content/en/articles/pgpkeys/_index.adoc index d7d7698fb1..f0737ef992 100644 --- a/documentation/content/en/articles/pgpkeys/_index.adoc +++ b/documentation/content/en/articles/pgpkeys/_index.adoc @@ -17,16 +17,19 @@ tags: ["OpenPGP", "Developers", "Officers", "FreeBSD"] ifeval::["{backend}" == "html5"] include::shared/authors.adoc[] include::shared/en/teams.adoc[lines=16..-1] +:include-path: static/pgpkeys/ endif::[] ifeval::["{backend}" == "pdf"] include::../../../../shared/authors.adoc[] include::../../../../shared/en/teams.adoc[lines=16..-1] +:include-path: ../../../../static/pgpkeys/ endif::[] ifeval::["{backend}" == "epub3"] include::../../../../shared/authors.adoc[] include::../../../../shared/en/teams.adoc[lines=16..-1] +:include-path: ../../../../static/pgpkeys/ endif::[] ''' @@ -49,1759 +52,1759 @@ shown in the Handbook PGP keys chapter. == Officers === {security-officer-name} `<{security-officer-email}>` -include::static/pgpkeys/security-officer.key[] +include::{include-path}security-officer.key[] === {secteam-secretary-name} `<{secteam-secretary-email}>` -include::static/pgpkeys/secteam-secretary.key[] +include::{include-path}secteam-secretary.key[] === {core-secretary-name} `<{core-secretary-email}>` -include::static/pgpkeys/core-secretary.key[] +include::{include-path}core-secretary.key[] === {portmgr-secretary-name} `<{portmgr-secretary-email}>` -include::static/pgpkeys/portmgr-secretary.key[] +include::{include-path}portmgr-secretary.key[] === `{doceng-secretary-email}` -include::static/pgpkeys/doceng-secretary.key[] +include::{include-path}doceng-secretary.key[] [[pgpkeys-core]] == Core Team Members === `{bapt}` -include::static/pgpkeys/bapt.key[] +include::{include-path}bapt.key[] === `{emaste}` -include::static/pgpkeys/emaste.key[] +include::{include-path}emaste.key[] === `{gnn}` -include::static/pgpkeys/gnn.key[] +include::{include-path}gnn.key[] === `{hrs}` -include::static/pgpkeys/hrs.key[] +include::{include-path}hrs.key[] === `{imp}` -include::static/pgpkeys/imp.key[] +include::{include-path}imp.key[] === `{kevans}` -include::static/pgpkeys/kevans.key[] +include::{include-path}kevans.key[] === `{markj}` -include::static/pgpkeys/markj.key[] +include::{include-path}markj.key[] === `{scottl}` -include::static/pgpkeys/scottl.key[] +include::{include-path}scottl.key[] === `{seanc}` -include::static/pgpkeys/seanc.key[] +include::{include-path}seanc.key[] [[pgpkeys-developers]] == Developers === `{ariff}` -include::static/pgpkeys/ariff.key[] +include::{include-path}ariff.key[] === `{tabthorpe}` -include::static/pgpkeys/tabthorpe.key[] +include::{include-path}tabthorpe.key[] === `{eadler}` -include::static/pgpkeys/eadler.key[] +include::{include-path}eadler.key[] === `{mahrens}` -include::static/pgpkeys/mahrens.key[] +include::{include-path}mahrens.key[] === `{shaun}` -include::static/pgpkeys/shaun.key[] +include::{include-path}shaun.key[] === `{brix}` -include::static/pgpkeys/brix.key[] +include::{include-path}brix.key[] === `{mandree}` -include::static/pgpkeys/mandree.key[] +include::{include-path}mandree.key[] === `{will}` -include::static/pgpkeys/will.key[] +include::{include-path}will.key[] === `{dim}` -include::static/pgpkeys/dim.key[] +include::{include-path}dim.key[] === `{anholt}` -include::static/pgpkeys/anholt.key[] +include::{include-path}anholt.key[] === `{fernape}` -include::static/pgpkeys/fernape.key[] +include::{include-path}fernape.key[] === `{mva}` -include::static/pgpkeys/mva.key[] +include::{include-path}mva.key[] === `{araujo}` -include::static/pgpkeys/araujo.key[] +include::{include-path}araujo.key[] === `{mat}` -include::static/pgpkeys/mat.key[] +include::{include-path}mat.key[] === `{syuu}` -include::static/pgpkeys/syuu.key[] +include::{include-path}syuu.key[] === `{asami}` -include::static/pgpkeys/asami.key[] +include::{include-path}asami.key[] === `{gavin}` -include::static/pgpkeys/gavin.key[] +include::{include-path}gavin.key[] === `{jsa}` -include::static/pgpkeys/jsa.key[] +include::{include-path}jsa.key[] === `{jadawin}` -include::static/pgpkeys/jadawin.key[] +include::{include-path}jadawin.key[] === `{jwb}` -include::static/pgpkeys/jwb.key[] +include::{include-path}jwb.key[] === `{badger}` -include::static/pgpkeys/badger.key[] +include::{include-path}badger.key[] === `{dbaio}` -include::static/pgpkeys/dbaio.key[] +include::{include-path}dbaio.key[] === `{timur}` -include::static/pgpkeys/timur.key[] +include::{include-path}timur.key[] === `{jhb}` -include::static/pgpkeys/jhb.key[] +include::{include-path}jhb.key[] === `{gjb}` -include::static/pgpkeys/gjb.key[] +include::{include-path}gjb.key[] === `{snb}` -include::static/pgpkeys/snb.key[] +include::{include-path}snb.key[] === `{barner}` -include::static/pgpkeys/barner.key[] +include::{include-path}barner.key[] === `{lbartoletti}` -include::static/pgpkeys/lbartoletti.key[] +include::{include-path}lbartoletti.key[] === `{jbeich}` -include::static/pgpkeys/jbeich.key[] +include::{include-path}jbeich.key[] === `{art}` -include::static/pgpkeys/art.key[] +include::{include-path}art.key[] === `{tobez}` -include::static/pgpkeys/tobez.key[] +include::{include-path}tobez.key[] === `{damien}` -include::static/pgpkeys/damien.key[] +include::{include-path}damien.key[] === `{bdragon}` -include::static/pgpkeys/bdragon.key[] +include::{include-path}bdragon.key[] === `{tcberner}` -include::static/pgpkeys/tcberner.key[] +include::{include-path}tcberner.key[] === `{tdb}` -include::static/pgpkeys/tdb.key[] +include::{include-path}tdb.key[] === `{gblach}` -include::static/pgpkeys/gblach.key[] +include::{include-path}gblach.key[] === `{mbr}` -include::static/pgpkeys/mbr.key[] +include::{include-path}mbr.key[] === `{wblock}` -include::static/pgpkeys/wblock.key[] +include::{include-path}wblock.key[] === `{bvs}` -include::static/pgpkeys/bvs.key[] +include::{include-path}bvs.key[] === `{zbb}` -include::static/pgpkeys/zbb.key[] +include::{include-path}zbb.key[] === `{novel}` -include::static/pgpkeys/novel.key[] +include::{include-path}novel.key[] === `{garga}` -include::static/pgpkeys/garga.key[] +include::{include-path}garga.key[] === `{kbowling}` -include::static/pgpkeys/kbowling.key[] +include::{include-path}kbowling.key[] === `{alexbl}` -include::static/pgpkeys/alexbl.key[] +include::{include-path}alexbl.key[] === `{sbz}` -include::static/pgpkeys/sbz.key[] +include::{include-path}sbz.key[] === `{ebrandi}` -include::static/pgpkeys/ebrandi.key[] +include::{include-path}ebrandi.key[] === `{dab}` -include::static/pgpkeys/dab.key[] +include::{include-path}dab.key[] === `{harti}` -include::static/pgpkeys/harti.key[] +include::{include-path}harti.key[] === `{obraun}` -include::static/pgpkeys/obraun.key[] +include::{include-path}obraun.key[] === `{makc}` -include::static/pgpkeys/makc.key[] +include::{include-path}makc.key[] === `{jmb}` -include::static/pgpkeys/jmb.key[] +include::{include-path}jmb.key[] === `{antoine}` -include::static/pgpkeys/antoine.key[] +include::{include-path}antoine.key[] === `{db}` -include::static/pgpkeys/db.key[] +include::{include-path}db.key[] === `{brueffer}` -include::static/pgpkeys/brueffer.key[] +include::{include-path}brueffer.key[] === `{markus}` -include::static/pgpkeys/markus.key[] +include::{include-path}markus.key[] === `{sbruno}` -include::static/pgpkeys/sbruno.key[] +include::{include-path}sbruno.key[] === `{br}` -include::static/pgpkeys/br.key[] +include::{include-path}br.key[] === `{oleg}` -include::static/pgpkeys/oleg.key[] +include::{include-path}oleg.key[] === `{bushman}` -include::static/pgpkeys/bushman.key[] +include::{include-path}bushman.key[] === `{adrian}` -include::static/pgpkeys/adrian.key[] +include::{include-path}adrian.key[] === `{jch}` -include::static/pgpkeys/jch.key[] +include::{include-path}jch.key[] === `{jchandra}` -include::static/pgpkeys/jchandra.key[] +include::{include-path}jchandra.key[] === `{jcamou}` -include::static/pgpkeys/jcamou.key[] +include::{include-path}jcamou.key[] === `{acm}` -include::static/pgpkeys/acm.key[] +include::{include-path}acm.key[] === `{gahr}` -include::static/pgpkeys/gahr.key[] +include::{include-path}gahr.key[] === `{dchagin}` -include::static/pgpkeys/dchagin.key[] +include::{include-path}dchagin.key[] === `{perky}` -include::static/pgpkeys/perky.key[] +include::{include-path}perky.key[] === `{jon}` -include::static/pgpkeys/jon.key[] +include::{include-path}jon.key[] === `{jonathan}` -include::static/pgpkeys/jonathan.key[] +include::{include-path}jonathan.key[] === `{loader}` -include::static/pgpkeys/loader.key[] +include::{include-path}loader.key[] === `{luoqi}` -include::static/pgpkeys/luoqi.key[] +include::{include-path}luoqi.key[] === `{ache}` -include::static/pgpkeys/ache.key[] +include::{include-path}ache.key[] === `{melifaro}` -include::static/pgpkeys/melifaro.key[] +include::{include-path}melifaro.key[] === `{seanc}` -include::static/pgpkeys/seanc.key[] +include::{include-path}seanc.key[] === `{cjh}` -include::static/pgpkeys/cjh.key[] +include::{include-path}cjh.key[] === `{davidch}` -include::static/pgpkeys/davidch.key[] +include::{include-path}davidch.key[] === `{milki}` -include::static/pgpkeys/milki.key[] +include::{include-path}milki.key[] === `{cjc}` -include::static/pgpkeys/cjc.key[] +include::{include-path}cjc.key[] === `{marcus}` -include::static/pgpkeys/marcus.key[] +include::{include-path}marcus.key[] === `{nik}` -include::static/pgpkeys/nik.key[] +include::{include-path}nik.key[] === `{benjsc}` -include::static/pgpkeys/benjsc.key[] +include::{include-path}benjsc.key[] === `{lcook}` -include::static/pgpkeys/lcook.key[] +include::{include-path}lcook.key[] === `{ngie}` -include::static/pgpkeys/ngie.key[] +include::{include-path}ngie.key[] === `{tijl}` -include::static/pgpkeys/tijl.key[] +include::{include-path}tijl.key[] === `{rakuco}` -include::static/pgpkeys/rakuco.key[] +include::{include-path}rakuco.key[] === `{dch}` -include::static/pgpkeys/dch.key[] +include::{include-path}dch.key[] === `{alc}` -include::static/pgpkeys/alc.key[] +include::{include-path}alc.key[] === `{olivier}` -include::static/pgpkeys/olivier.key[] +include::{include-path}olivier.key[] === `{jeb}` -include::static/pgpkeys/jeb.key[] +include::{include-path}jeb.key[] === `{bcran}` -include::static/pgpkeys/bcran.key[] +include::{include-path}bcran.key[] === `{culot}` -include::static/pgpkeys/culot.key[] +include::{include-path}culot.key[] === `{aaron}` -include::static/pgpkeys/aaron.key[] +include::{include-path}aaron.key[] === `{alfredo}` -include::static/pgpkeys/alfredo.key[] +include::{include-path}alfredo.key[] === `{bapt}` -include::static/pgpkeys/bapt.key[] +include::{include-path}bapt.key[] === `{ceri}` -include::static/pgpkeys/ceri.key[] +include::{include-path}ceri.key[] === `{brd}` -include::static/pgpkeys/brd.key[] +include::{include-path}brd.key[] === `{edavis}` -include::static/pgpkeys/edavis.key[] +include::{include-path}edavis.key[] === `{pjd}` -include::static/pgpkeys/pjd.key[] +include::{include-path}pjd.key[] === `{alexey}` -include::static/pgpkeys/alexey.key[] +include::{include-path}alexey.key[] === `{bsd}` -include::static/pgpkeys/bsd.key[] +include::{include-path}bsd.key[] === `{carl}` -include::static/pgpkeys/carl.key[] +include::{include-path}carl.key[] === `{carlavilla}` -include::static/pgpkeys/carlavilla.key[] +include::{include-path}carlavilla.key[] === `{jmd}` -include::static/pgpkeys/jmd.key[] +include::{include-path}jmd.key[] === `{vd}` -include::static/pgpkeys/vd.key[] +include::{include-path}vd.key[] === `{rdivacky}` -include::static/pgpkeys/rdivacky.key[] +include::{include-path}rdivacky.key[] === `{danfe}` -include::static/pgpkeys/danfe.key[] +include::{include-path}danfe.key[] === `{dd}` -include::static/pgpkeys/dd.key[] +include::{include-path}dd.key[] === `{bdrewery}` -include::static/pgpkeys/bdrewery.key[] +include::{include-path}bdrewery.key[] === `{gad}` -include::static/pgpkeys/gad.key[] +include::{include-path}gad.key[] === `{olivierd}` -include::static/pgpkeys/olivierd.key[] +include::{include-path}olivierd.key[] === `{bruno}` -include::static/pgpkeys/bruno.key[] +include::{include-path}bruno.key[] === `{ale}` -include::static/pgpkeys/ale.key[] +include::{include-path}ale.key[] === `{nemysis}` -include::static/pgpkeys/nemysis.key[] +include::{include-path}nemysis.key[] === `{peadar}` -include::static/pgpkeys/peadar.key[] +include::{include-path}peadar.key[] === `{deischen}` -include::static/pgpkeys/deischen.key[] +include::{include-path}deischen.key[] === `{josef}` -include::static/pgpkeys/josef.key[] +include::{include-path}josef.key[] === `{lme}` -include::static/pgpkeys/lme.key[] +include::{include-path}lme.key[] === `{ue}` -include::static/pgpkeys/ue.key[] +include::{include-path}ue.key[] === `{ru}` -include::static/pgpkeys/ru.key[] +include::{include-path}ru.key[] === `{le}` -include::static/pgpkeys/le.key[] +include::{include-path}le.key[] === `{se}` -include::static/pgpkeys/se.key[] +include::{include-path}se.key[] === `{kevans}` -include::static/pgpkeys/kevans.key[] +include::{include-path}kevans.key[] === `{bf}` -include::static/pgpkeys/bf.key[] +include::{include-path}bf.key[] === `{sef}` -include::static/pgpkeys/sef.key[] +include::{include-path}sef.key[] === `{madpilot}` -include::static/pgpkeys/madpilot.key[] +include::{include-path}madpilot.key[] === `{rafan}` -include::static/pgpkeys/rafan.key[] +include::{include-path}rafan.key[] === `{kami}` -include::static/pgpkeys/kami.key[] +include::{include-path}kami.key[] === `{stefanf}` -include::static/pgpkeys/stefanf.key[] +include::{include-path}stefanf.key[] === `{farrokhi}` -include::static/pgpkeys/farrokhi.key[] +include::{include-path}farrokhi.key[] === `{jedgar}` -include::static/pgpkeys/jedgar.key[] +include::{include-path}jedgar.key[] === `{mfechner}` -include::static/pgpkeys/mfechner.key[] +include::{include-path}mfechner.key[] === `{feld}` -include::static/pgpkeys/feld.key[] +include::{include-path}feld.key[] === `{green}` -include::static/pgpkeys/green.key[] +include::{include-path}green.key[] === `{lioux}` -include::static/pgpkeys/lioux.key[] +include::{include-path}lioux.key[] === `{mdf}` -include::static/pgpkeys/mdf.key[] +include::{include-path}mdf.key[] === `{fanf}` -include::static/pgpkeys/fanf.key[] +include::{include-path}fanf.key[] === `{blackend}` -include::static/pgpkeys/blackend.key[] +include::{include-path}blackend.key[] === `{petef}` -include::static/pgpkeys/petef.key[] +include::{include-path}petef.key[] === `{decke}` -include::static/pgpkeys/decke.key[] +include::{include-path}decke.key[] === `{landonf}` -include::static/pgpkeys/landonf.key[] +include::{include-path}landonf.key[] === `{billf}` -include::static/pgpkeys/billf.key[] +include::{include-path}billf.key[] === `{sg}` -include::static/pgpkeys/sg.key[] +include::{include-path}sg.key[] === `{sgalabov}` -include::static/pgpkeys/sgalabov.key[] +include::{include-path}sgalabov.key[] === `{ultima}` -include::static/pgpkeys/ultima.key[] +include::{include-path}ultima.key[] === `{avg}` -include::static/pgpkeys/avg.key[] +include::{include-path}avg.key[] === `{beat}` -include::static/pgpkeys/beat.key[] +include::{include-path}beat.key[] === `{danger}` -include::static/pgpkeys/danger.key[] +include::{include-path}danger.key[] === `{sjg}` -include::static/pgpkeys/sjg.key[] +include::{include-path}sjg.key[] === `{gibbs}` -include::static/pgpkeys/gibbs.key[] +include::{include-path}gibbs.key[] === `{pfg}` -include::static/pgpkeys/pfg.key[] +include::{include-path}pfg.key[] === `{girgen}` -include::static/pgpkeys/girgen.key[] +include::{include-path}girgen.key[] === `{eugen}` -include::static/pgpkeys/eugen.key[] +include::{include-path}eugen.key[] === `{pgollucci}` -include::static/pgpkeys/pgollucci.key[] +include::{include-path}pgollucci.key[] === `{trociny}` -include::static/pgpkeys/trociny.key[] +include::{include-path}trociny.key[] === `{danilo}` -include::static/pgpkeys/danilo.key[] +include::{include-path}danilo.key[] === `{dmgk}` -include::static/pgpkeys/dmgk.key[] +include::{include-path}dmgk.key[] === `{daichi}` -include::static/pgpkeys/daichi.key[] +include::{include-path}daichi.key[] === `{mnag}` -include::static/pgpkeys/mnag.key[] +include::{include-path}mnag.key[] === `{grehan}` -include::static/pgpkeys/grehan.key[] +include::{include-path}grehan.key[] === `{jamie}` -include::static/pgpkeys/jamie.key[] +include::{include-path}jamie.key[] === `{adridg}` -include::static/pgpkeys/adridg.key[] +include::{include-path}adridg.key[] === `{edwin}` -include::static/pgpkeys/edwin.key[] +include::{include-path}edwin.key[] === `{wg}` -include::static/pgpkeys/wg.key[] +include::{include-path}wg.key[] === `{bar}` -include::static/pgpkeys/bar.key[] +include::{include-path}bar.key[] === `{anish}` -include::static/pgpkeys/anish.key[] +include::{include-path}anish.key[] === `{jmg}` -include::static/pgpkeys/jmg.key[] +include::{include-path}jmg.key[] === `{mjg}` -include::static/pgpkeys/mjg.key[] +include::{include-path}mjg.key[] === `{jhale}` -include::static/pgpkeys/jhale.key[] +include::{include-path}jhale.key[] === `{jah}` -include::static/pgpkeys/jah.key[] +include::{include-path}jah.key[] === `{dannyboy}` -include::static/pgpkeys/dannyboy.key[] +include::{include-path}dannyboy.key[] === `{dhartmei}` -include::static/pgpkeys/dhartmei.key[] +include::{include-path}dhartmei.key[] === `{ohauer}` -include::static/pgpkeys/ohauer.key[] +include::{include-path}ohauer.key[] === `{ehaupt}` -include::static/pgpkeys/ehaupt.key[] +include::{include-path}ehaupt.key[] === `{jhay}` -include::static/pgpkeys/jhay.key[] +include::{include-path}jhay.key[] === `{bhd}` -include::static/pgpkeys/bhd.key[] +include::{include-path}bhd.key[] === `{sheldonh}` -include::static/pgpkeys/sheldonh.key[] +include::{include-path}sheldonh.key[] === `{mikeh}` -include::static/pgpkeys/mikeh.key[] +include::{include-path}mikeh.key[] === `{mheinen}` -include::static/pgpkeys/mheinen.key[] +include::{include-path}mheinen.key[] === `{niels}` -include::static/pgpkeys/niels.key[] +include::{include-path}niels.key[] === `{jh}` -include::static/pgpkeys/jh.key[] +include::{include-path}jh.key[] === `{jgh}` -include::static/pgpkeys/jgh.key[] +include::{include-path}jgh.key[] === `{ghelmer}` -include::static/pgpkeys/ghelmer.key[] +include::{include-path}ghelmer.key[] === `{mux}` -include::static/pgpkeys/mux.key[] +include::{include-path}mux.key[] === `{wen}` -include::static/pgpkeys/wen.key[] +include::{include-path}wen.key[] === `{dhn}` -include::static/pgpkeys/dhn.key[] +include::{include-path}dhn.key[] === `{jhibbits}` -include::static/pgpkeys/jhibbits.key[] +include::{include-path}jhibbits.key[] === `{jhixson}` -include::static/pgpkeys/jhixson.key[] +include::{include-path}jhixson.key[] === `{pho}` -include::static/pgpkeys/pho.key[] +include::{include-path}pho.key[] === `{oh}` -include::static/pgpkeys/oh.key[] +include::{include-path}oh.key[] === `{mhorne}` -include::static/pgpkeys/mhorne.key[] +include::{include-path}mhorne.key[] === `{bhughes}` -include::static/pgpkeys/bhughes.key[] +include::{include-path}bhughes.key[] === `{mich}` -include::static/pgpkeys/mich.key[] +include::{include-path}mich.key[] === `{sunpoet}` -include::static/pgpkeys/sunpoet.key[] +include::{include-path}sunpoet.key[] === `{lwhsu}` -include::static/pgpkeys/lwhsu.key[] +include::{include-path}lwhsu.key[] === `{foxfair}` -include::static/pgpkeys/foxfair.key[] +include::{include-path}foxfair.key[] === `{whu}` -include::static/pgpkeys/whu.key[] +include::{include-path}whu.key[] === `{chinsan}` -include::static/pgpkeys/chinsan.key[] +include::{include-path}chinsan.key[] === `{shurd}` -include::static/pgpkeys/shurd.key[] +include::{include-path}shurd.key[] *** 1499 LINES SKIPPED *** From owner-dev-commits-doc-all@freebsd.org Sun May 23 15:21:12 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 39BBC649DA7 for ; Sun, 23 May 2021 15:21:12 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fp3vr19m7z4Ywd; Sun, 23 May 2021 15:21:12 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 11C5F19624; Sun, 23 May 2021 15:21:12 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14NFLBW5083440; Sun, 23 May 2021 15:21:11 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14NFLBk5083439; Sun, 23 May 2021 15:21:11 GMT (envelope-from git) Date: Sun, 23 May 2021 15:21:11 GMT Message-Id: <202105231521.14NFLBk5083439@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Ceri Davies Subject: git: 01d3670c18 - main - articles/contributors: Correct an incorrectly merged entry MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ceri X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 01d3670c18632effda4785d8fe57b4da0d4260cb Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 15:21:12 -0000 The branch main has been updated by ceri: URL: https://cgit.FreeBSD.org/doc/commit/?id=01d3670c18632effda4785d8fe57b4da0d4260cb commit 01d3670c18632effda4785d8fe57b4da0d4260cb Author: Ceri Davies AuthorDate: 2021-05-23 15:12:57 +0000 Commit: Ceri Davies CommitDate: 2021-05-23 15:12:57 +0000 articles/contributors: Correct an incorrectly merged entry There is a single entry which refers to two individuals and with a syntactically incorrect email address. This was incorrect and causing issues with a PDF build of this article, so split it into two correct entries, using information from our ppp(8) manpage. Approved by: blackend (mentor) --- documentation/content/en/articles/contributors/contrib-additional.adoc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/documentation/content/en/articles/contributors/contrib-additional.adoc b/documentation/content/en/articles/contributors/contrib-additional.adoc index 431880211b..5ce5753984 100644 --- a/documentation/content/en/articles/contributors/contrib-additional.adoc +++ b/documentation/content/en/articles/contributors/contrib-additional.adoc @@ -249,6 +249,7 @@ * Ask Bjoern Hansen mailto:ask@valueclick.com[ask@valueclick.com] * Athanasios Douitsis mailto:aduitsis@cpan.org[aduitsis@cpan.org] * Atsushi Furuta mailto:furuta@sra.co.jp[furuta@sra.co.jp] +* Atsushi Murai mailto:amurai@spec.co.jp[amurai@spec.co.jp] * Attila Nagy mailto:bra@fsn.hu[bra@fsn.hu] * Atushi Sakauchi mailto:sakauchi@yamame.to[sakauchi@yamame.to] * Autrijus Tang mailto:autrijus@autrijus.org[autrijus@autrijus.org] @@ -1645,7 +1646,6 @@ * No Name mailto:sumii@is.s.u-tokyo.ac.jp[sumii@is.s.u-tokyo.ac.jp] * No Name mailto:takas-su@is.aist-nara.ac.jp[takas-su@is.aist-nara.ac.jp] * No Name mailto:tjevans@raleigh.ibm.com[tjevans@raleigh.ibm.com] -* No Name mailto:tony-o@iij.ad.jpamurai@spec.co.jp[tony-o@iij.ad.jpamurai@spec.co.jp] * No Name mailto:torii@tcd.hitachi.co.jp[torii@tcd.hitachi.co.jp] * No Name mailto:uenami@imasy.or.jp[uenami@imasy.or.jp] * No Name mailto:vode@hut.fi[vode@hut.fi] @@ -2208,6 +2208,7 @@ * Tony Shadwick mailto:numbski@hksilver.net[numbski@hksilver.net] * Tor Halvard "Squat" Furulund mailto:squat@squat.no[squat@squat.no] * Torbjorn Granlund mailto:tege@matematik.su.se[tege@matematik.su.se] +* Toshiharu Ohno mailto:tony-o@iij.ad.jp[tony-o@iij.ad.jp] * Toshihiko SHIMOKAWA mailto:toshi@tea.forus.or.jp[toshi@tea.forus.or.jp] * Toshihiro Kanda mailto:candy@kgc.co.jp[candy@kgc.co.jp] * Toshiomi Moriki mailto:Toshiomi.Moriki@ma1.seikyou.ne.jp[Toshiomi.Moriki@ma1.seikyou.ne.jp] From owner-dev-commits-doc-all@freebsd.org Sun May 23 19:01:20 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BCB3164D785 for ; Sun, 23 May 2021 19:01:20 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fp8nr4p4rz3pXl; Sun, 23 May 2021 19:01:20 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8C8901C980; Sun, 23 May 2021 19:01:20 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14NJ1Kpa074286; Sun, 23 May 2021 19:01:20 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14NJ1Kup074285; Sun, 23 May 2021 19:01:20 GMT (envelope-from git) Date: Sun, 23 May 2021 19:01:20 GMT Message-Id: <202105231901.14NJ1Kup074285@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Sergio Carlavilla Delgado Subject: git: 0030e0f18a - main - Remove comment and CSS class from the pgpkeys.txt file MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: carlavilla X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 0030e0f18adf90701e4e8137550c0f036804e2cb Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 19:01:20 -0000 The branch main has been updated by carlavilla: URL: https://cgit.FreeBSD.org/doc/commit/?id=0030e0f18adf90701e4e8137550c0f036804e2cb commit 0030e0f18adf90701e4e8137550c0f036804e2cb Author: Sergio Carlavilla Delgado AuthorDate: 2021-05-23 19:00:35 +0000 Commit: Sergio Carlavilla Delgado CommitDate: 2021-05-23 19:00:35 +0000 Remove comment and CSS class from the pgpkeys.txt file --- documentation/tools/global-pgpkeys-creator.rb | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/documentation/tools/global-pgpkeys-creator.rb b/documentation/tools/global-pgpkeys-creator.rb index 37eb94fe32..72825f613e 100644 --- a/documentation/tools/global-pgpkeys-creator.rb +++ b/documentation/tools/global-pgpkeys-creator.rb @@ -22,7 +22,9 @@ end def processPGPKey(keyFile, pgpKeysFile) File.readlines(keyFile).each do |line| - pgpKeysFile.puts(line) + if not line.include? "// sh addkey.sh" and not line.include? "[.literal-block-margin]" + pgpKeysFile.puts(line) + end end end From owner-dev-commits-doc-all@freebsd.org Sun May 23 19:34:53 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 47BC064DE98 for ; Sun, 23 May 2021 19:34:53 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fp9XY1QsGz4bTX; Sun, 23 May 2021 19:34:53 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 115011C959; Sun, 23 May 2021 19:34:53 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14NJYqFf016192; Sun, 23 May 2021 19:34:52 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14NJYq7W016191; Sun, 23 May 2021 19:34:52 GMT (envelope-from git) Date: Sun, 23 May 2021 19:34:52 GMT Message-Id: <202105231934.14NJYq7W016191@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Sergio Carlavilla Delgado Subject: git: adda9a6066 - main - Link to the new pgpkeys.txt file in articles and books MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: carlavilla X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: adda9a606635e898972fe88170ae51c76b02fc02 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 19:34:53 -0000 The branch main has been updated by carlavilla: URL: https://cgit.FreeBSD.org/doc/commit/?id=adda9a606635e898972fe88170ae51c76b02fc02 commit adda9a606635e898972fe88170ae51c76b02fc02 Author: Sergio Carlavilla Delgado AuthorDate: 2021-05-23 19:33:46 +0000 Commit: Sergio Carlavilla Delgado CommitDate: 2021-05-23 19:33:46 +0000 Link to the new pgpkeys.txt file in articles and books Link in articles and books to the new pgpkeys.txt file Remove all AsciiDoc syntax in pgpkeys.txt PR: 254636 Submitted by: dinoex@ --- documentation/content/de/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/content/el/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/content/en/articles/pgpkeys/_index.adoc | 2 +- documentation/content/en/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/content/fr/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/content/hu/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/content/it/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/content/ja/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/content/mn/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/content/nl/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/content/pl/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/content/ru/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/content/zh-cn/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/content/zh-tw/books/handbook/pgpkeys/_index.adoc | 2 +- documentation/tools/global-pgpkeys-creator.rb | 5 ++++- 15 files changed, 18 insertions(+), 15 deletions(-) diff --git a/documentation/content/de/books/handbook/pgpkeys/_index.adoc b/documentation/content/de/books/handbook/pgpkeys/_index.adoc index 3dd74c2628..0be2e24e81 100644 --- a/documentation/content/de/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/de/books/handbook/pgpkeys/_index.adoc @@ -31,7 +31,7 @@ include::shared/de/urls.adoc[] :pgpkeys-path: -Verwenden Sie die nachstehenden Schlüssel, wenn Sie eine Signatur überprüfen oder eine verschlüsselte E-Mail an einen Ansprechpartner oder einen Entwickler schicken wollen. Eine vollständige Liste der FreeBSD OpenPGP-Schlüssel finden Sie im Artikel {pgpkeys}[PGP Keys]. Den vollständigen Schlüsselring der Entwickler von FreeBSD finden Sie unter https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt]. +Verwenden Sie die nachstehenden Schlüssel, wenn Sie eine Signatur überprüfen oder eine verschlüsselte E-Mail an einen Ansprechpartner oder einen Entwickler schicken wollen. Eine vollständige Liste der FreeBSD OpenPGP-Schlüssel finden Sie im Artikel {pgpkeys}[PGP Keys]. Den vollständigen Schlüsselring der Entwickler von FreeBSD finden Sie unter link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt]. [[pgpkeys-officers]] == Ansprechpartner diff --git a/documentation/content/el/books/handbook/pgpkeys/_index.adoc b/documentation/content/el/books/handbook/pgpkeys/_index.adoc index 2515d26995..7ed4bf4060 100644 --- a/documentation/content/el/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/el/books/handbook/pgpkeys/_index.adoc @@ -32,7 +32,7 @@ include::shared/el/urls.adoc[] :pgpkeys-path: -Στο παράρτημα αυτό, θα βρείτε τα δημόσια PGP κλειδιά των officers και των μελών της ομάδας ανάπτυξης του FreeBSD. Μπορείτε να τα χρησιμοποιήσετε για να ελέγξετε μια ψηφιακή υπογραφή ή για να στείλετε κρυπτογραφημένο email σε κάποιο μέλος της ομάδας. Μπορείτε να κατεβάσετε την πλήρη λίστα από κλειδιά χρηστών του `FreeBSD.org`, από την τοποθεσία link:https://www.FreeBSD.org/doc/pgpkeyring.txt[http://www.FreeBSD.org/doc/pgpkeyring.txt]. +Στο παράρτημα αυτό, θα βρείτε τα δημόσια PGP κλειδιά των officers και των μελών της ομάδας ανάπτυξης του FreeBSD. Μπορείτε να τα χρησιμοποιήσετε για να ελέγξετε μια ψηφιακή υπογραφή ή για να στείλετε κρυπτογραφημένο email σε κάποιο μέλος της ομάδας. Μπορείτε να κατεβάσετε την πλήρη λίστα από κλειδιά χρηστών του `FreeBSD.org`, από την τοποθεσία link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt]. [[pgpkeys-officers]] == Officers diff --git a/documentation/content/en/articles/pgpkeys/_index.adoc b/documentation/content/en/articles/pgpkeys/_index.adoc index f0737ef992..4efcf5152b 100644 --- a/documentation/content/en/articles/pgpkeys/_index.adoc +++ b/documentation/content/en/articles/pgpkeys/_index.adoc @@ -37,7 +37,7 @@ endif::[] toc::[] These OpenPGP keys can be used to verify a signature or send encrypted email to `FreeBSD.org` officers or developers. -The complete keyring can be downloaded at link:https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt]. +The complete keyring can be downloaded at link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt]. //// Do not edit this file except as instructed by the addkey.sh script. diff --git a/documentation/content/en/books/handbook/pgpkeys/_index.adoc b/documentation/content/en/books/handbook/pgpkeys/_index.adoc index 0c481c80c6..ff7404be9a 100644 --- a/documentation/content/en/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/en/books/handbook/pgpkeys/_index.adoc @@ -30,7 +30,7 @@ include::shared/en/urls.adoc[] :pgpkeys-path: -The OpenPGP keys of the `FreeBSD.org` officers are shown here. These keys can be used to verify a signature or send encrypted email to one of the officers. A full list of FreeBSD OpenPGP keys is available in the link:{pgpkeys}[PGP Keys] article. The complete keyring can be downloaded at https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt]. +The OpenPGP keys of the `FreeBSD.org` officers are shown here. These keys can be used to verify a signature or send encrypted email to one of the officers. A full list of FreeBSD OpenPGP keys is available in the link:{pgpkeys}[PGP Keys] article. The complete keyring can be downloaded at link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt]. [[pgpkeys-officers]] == Officers diff --git a/documentation/content/fr/books/handbook/pgpkeys/_index.adoc b/documentation/content/fr/books/handbook/pgpkeys/_index.adoc index 66c7310c69..febab06565 100644 --- a/documentation/content/fr/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/fr/books/handbook/pgpkeys/_index.adoc @@ -31,7 +31,7 @@ include::shared/fr/urls.adoc[] :pgpkeys-path: -Les clés OpenPGP des officiers `FreeBSD.org` sont données ici. Ces clés peuvent être utilisées pour vérifier une signature ou pour envoyer un courrier électronique chiffré à un des officiers. Une liste complète des clés OpenPGP FreeBSD est disponible dans l'article link:{pgpkeys}[Clés PGP]. Le trouseau complet peut être télécharger depuis https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt]. +Les clés OpenPGP des officiers `FreeBSD.org` sont données ici. Ces clés peuvent être utilisées pour vérifier une signature ou pour envoyer un courrier électronique chiffré à un des officiers. Une liste complète des clés OpenPGP FreeBSD est disponible dans l'article link:{pgpkeys}[Clés PGP]. Le trouseau complet peut être télécharger depuis link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt]. [[pgpkeys-officers]] == Officers diff --git a/documentation/content/hu/books/handbook/pgpkeys/_index.adoc b/documentation/content/hu/books/handbook/pgpkeys/_index.adoc index 26f9a79cf7..95794e5c26 100644 --- a/documentation/content/hu/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/hu/books/handbook/pgpkeys/_index.adoc @@ -32,7 +32,7 @@ include::shared/hu/urls.adoc[] :pgpkeys-path: -The OpenPGP keys of the `FreeBSD.org` officers are shown here. These keys can be used to verify a signature or send encrypted email to one of the officers. A full list of FreeBSD OpenPGP keys is available in the link:{pgpkeys}[PGP Keys] article. The complete keyring can be downloaded at https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt]. +The OpenPGP keys of the `FreeBSD.org` officers are shown here. These keys can be used to verify a signature or send encrypted email to one of the officers. A full list of FreeBSD OpenPGP keys is available in the link:{pgpkeys}[PGP Keys] article. The complete keyring can be downloaded at link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt]. [[pgpkeys-officers]] == Tisztségviselők diff --git a/documentation/content/it/books/handbook/pgpkeys/_index.adoc b/documentation/content/it/books/handbook/pgpkeys/_index.adoc index 77cbb87bb9..9bfaf76a71 100644 --- a/documentation/content/it/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/it/books/handbook/pgpkeys/_index.adoc @@ -32,7 +32,7 @@ include::shared/it/teams.adoc[] :pgpkeys-path: -Nel caso tu debba verificare una firma o inviare un messaggio cifrato a una delle cariche ufficiali o a uno degli sviluppatori, qui puoi trovare per tua comodità una serie di chiavi. Un portachiavi completo degli utenti `FreeBSD.org` è disponibile per il download da https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt]. +Nel caso tu debba verificare una firma o inviare un messaggio cifrato a una delle cariche ufficiali o a uno degli sviluppatori, qui puoi trovare per tua comodità una serie di chiavi. Un portachiavi completo degli utenti `FreeBSD.org` è disponibile per il download da link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt]. [[pgpkeys-officers]] == Cariche Ufficiali diff --git a/documentation/content/ja/books/handbook/pgpkeys/_index.adoc b/documentation/content/ja/books/handbook/pgpkeys/_index.adoc index e7ef770d0c..025a56812b 100644 --- a/documentation/content/ja/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/ja/books/handbook/pgpkeys/_index.adoc @@ -32,7 +32,7 @@ include::shared/ja/urls.adoc[] :pgpkeys-path: -`FreeBSD.org` オフィサの PGP 公開鍵を以下に示します。 これらの公開鍵は、署名を検証したり、 オフィサに暗号メールを送る必要がある場合に使用できます。 すべての FreeBSD 公開鍵の一覧は、 link:{pgpkeys}[PGP Keys] にあります。 また、完全なキーリングは https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt] からダウンロードできます。 +`FreeBSD.org` オフィサの PGP 公開鍵を以下に示します。 これらの公開鍵は、署名を検証したり、 オフィサに暗号メールを送る必要がある場合に使用できます。 すべての FreeBSD 公開鍵の一覧は、 link:{pgpkeys}[PGP Keys] にあります。 また、完全なキーリングは link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt] からダウンロードできます。 [[pgpkeys-officers]] == オフィサ diff --git a/documentation/content/mn/books/handbook/pgpkeys/_index.adoc b/documentation/content/mn/books/handbook/pgpkeys/_index.adoc index e1d9aa6198..1f862eb598 100644 --- a/documentation/content/mn/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/mn/books/handbook/pgpkeys/_index.adoc @@ -32,7 +32,7 @@ include::shared/mn/urls.adoc[] :pgpkeys-path: -The OpenPGP keys of the `FreeBSD.org` officers are shown here. These keys can be used to verify a signature or send encrypted email to one of the officers. A full list of FreeBSD OpenPGP keys is available in the link:{pgpkeys}[PGP Keys] article. The complete keyring can be downloaded at https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt]. +The OpenPGP keys of the `FreeBSD.org` officers are shown here. These keys can be used to verify a signature or send encrypted email to one of the officers. A full list of FreeBSD OpenPGP keys is available in the link:{pgpkeys}[PGP Keys] article. The complete keyring can be downloaded at link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt]. [[pgpkeys-officers]] == Officers diff --git a/documentation/content/nl/books/handbook/pgpkeys/_index.adoc b/documentation/content/nl/books/handbook/pgpkeys/_index.adoc index 846ecf8a4f..35f8740cff 100644 --- a/documentation/content/nl/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/nl/books/handbook/pgpkeys/_index.adoc @@ -32,7 +32,7 @@ include::shared/nl/urls.adoc[] :pgpkeys-path: -In het geval een handtekening van een van de beambten of ontwikkelaars gecontroleerd moet worden of er een versleutelde e-mail aan ze gezonden moet worden, worden hier voor het gemak een aantal sleutels weergegeven. Een complete sleutelring van `FreeBSD.org` gebruikers kan op de volgende link gedownload worden: https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt]. +In het geval een handtekening van een van de beambten of ontwikkelaars gecontroleerd moet worden of er een versleutelde e-mail aan ze gezonden moet worden, worden hier voor het gemak een aantal sleutels weergegeven. Een complete sleutelring van `FreeBSD.org` gebruikers kan op de volgende link gedownload worden: link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt]. [[pgpkeys-officers]] == Beambten diff --git a/documentation/content/pl/books/handbook/pgpkeys/_index.adoc b/documentation/content/pl/books/handbook/pgpkeys/_index.adoc index 44c60009d6..71891b0a9c 100644 --- a/documentation/content/pl/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/pl/books/handbook/pgpkeys/_index.adoc @@ -32,7 +32,7 @@ include::shared/pl/teams.adoc[] :pgpkeys-path: -W tym rozdziale zostało zebranych, dla naszej wygody, wiele kluczy oficerów czy twórców FreeBSD, gdybyśmy musieli zweryfikować podpis bądź wysłać do jednego z nich zaszyfrowaną wiadomość. Kompletna baza kluczy użytkowników `FreeBSD.org` dostępna jest pod adresem https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt]. +W tym rozdziale zostało zebranych, dla naszej wygody, wiele kluczy oficerów czy twórców FreeBSD, gdybyśmy musieli zweryfikować podpis bądź wysłać do jednego z nich zaszyfrowaną wiadomość. Kompletna baza kluczy użytkowników `FreeBSD.org` dostępna jest pod adresem link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt]. [[pgpkeys-officers]] == Oficerowie diff --git a/documentation/content/ru/books/handbook/pgpkeys/_index.adoc b/documentation/content/ru/books/handbook/pgpkeys/_index.adoc index 809e8fb031..9b85e25682 100644 --- a/documentation/content/ru/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/ru/books/handbook/pgpkeys/_index.adoc @@ -32,7 +32,7 @@ include::shared/ru/urls.adoc[] :pgpkeys-path: -В случае, если вам нужно проверить подпись или послать зашифрованное электронное письмо одному из офицеров или разработчиков, то для вашего удобства здесь представлено некоторое количество ключей. Полный список ключей пользователей `FreeBSD.org` доступен для скачивания с http://www.FreeBSD.org/doc/pgpkeyring.txt. +В случае, если вам нужно проверить подпись или послать зашифрованное электронное письмо одному из офицеров или разработчиков, то для вашего удобства здесь представлено некоторое количество ключей. Полный список ключей пользователей `FreeBSD.org` доступен для скачивания с link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt]. [[pgpkeys-officers]] == Офицеры diff --git a/documentation/content/zh-cn/books/handbook/pgpkeys/_index.adoc b/documentation/content/zh-cn/books/handbook/pgpkeys/_index.adoc index b74d12071a..568193758e 100644 --- a/documentation/content/zh-cn/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/zh-cn/books/handbook/pgpkeys/_index.adoc @@ -32,7 +32,7 @@ include::shared/zh-cn/urls.adoc[] :pgpkeys-path: -有些时候，您可能需要校验签名或者发送加密的邮件给官员或者开发者， 这里为了方便您而提供了一些密钥。完整的 FreeBSD.org 用户密钥可以在 http://www.FreeBSD.org/doc/pgpkeyring.txt 下载。 +有些时候，您可能需要校验签名或者发送加密的邮件给官员或者开发者， 这里为了方便您而提供了一些密钥。完整的 FreeBSD.org 用户密钥可以在 link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt] 下载。 [[pgpkeys-officers]] == Officers diff --git a/documentation/content/zh-tw/books/handbook/pgpkeys/_index.adoc b/documentation/content/zh-tw/books/handbook/pgpkeys/_index.adoc index eb46d2da5e..5758a5cfa9 100644 --- a/documentation/content/zh-tw/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/zh-tw/books/handbook/pgpkeys/_index.adoc @@ -32,7 +32,7 @@ include::shared/zh-tw/teams.adoc[] :pgpkeys-path: -The OpenPGP keys of the `FreeBSD.org` officers are shown here. These keys can be used to verify a signature or send encrypted email to one of the officers. A full list of FreeBSD OpenPGP keys is available in the link:{pgpkeys}[PGP Keys] article. The complete keyring can be downloaded at https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt]. +The OpenPGP keys of the `FreeBSD.org` officers are shown here. These keys can be used to verify a signature or send encrypted email to one of the officers. A full list of FreeBSD OpenPGP keys is available in the link:{pgpkeys}[PGP Keys] article. The complete keyring can be downloaded at link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt]. [[pgpkeys-officers]] == Officers diff --git a/documentation/tools/global-pgpkeys-creator.rb b/documentation/tools/global-pgpkeys-creator.rb index 72825f613e..6f9dd3d08e 100644 --- a/documentation/tools/global-pgpkeys-creator.rb +++ b/documentation/tools/global-pgpkeys-creator.rb @@ -22,7 +22,10 @@ end def processPGPKey(keyFile, pgpKeysFile) File.readlines(keyFile).each do |line| - if not line.include? "// sh addkey.sh" and not line.include? "[.literal-block-margin]" + if # remove script comment and AsciiDoc syntax + not line.include? "// sh addkey.sh" and + not line.include? "[.literal-block-margin]" and + not line.include? "...." pgpKeysFile.puts(line) end end From owner-dev-commits-doc-all@freebsd.org Sun May 23 19:52:47 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4E27664E486 for ; Sun, 23 May 2021 19:52:47 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fp9xC1n2Pz4kx4; Sun, 23 May 2021 19:52:47 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 265241D224; Sun, 23 May 2021 19:52:47 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14NJqlV9042250; Sun, 23 May 2021 19:52:47 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14NJqlt4042249; Sun, 23 May 2021 19:52:47 GMT (envelope-from git) Date: Sun, 23 May 2021 19:52:47 GMT Message-Id: <202105231952.14NJqlt4042249@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Sergio Carlavilla Delgado Subject: git: 8619f06653 - main - Improve the documentation titles MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: carlavilla X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 8619f066537d36101d4f4d8a60ccb806a9c62275 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 19:52:47 -0000 The branch main has been updated by carlavilla: URL: https://cgit.FreeBSD.org/doc/commit/?id=8619f066537d36101d4f4d8a60ccb806a9c62275 commit 8619f066537d36101d4f4d8a60ccb806a9c62275 Author: Ceri Davies AuthorDate: 2021-05-23 19:50:24 +0000 Commit: Sergio Carlavilla Delgado CommitDate: 2021-05-23 19:50:24 +0000 Improve the documentation titles Change the documentation titles order. From: The FreeBSD Project | Committer's Guide To: Committers'Guide | The FreeBSD Project PR: 255884 Submitted by: ygy@ --- documentation/themes/beastie/layouts/partials/site-head.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/themes/beastie/layouts/partials/site-head.html b/documentation/themes/beastie/layouts/partials/site-head.html index 8ab1b3b283..f8caeca139 100644 --- a/documentation/themes/beastie/layouts/partials/site-head.html +++ b/documentation/themes/beastie/layouts/partials/site-head.html @@ -6,7 +6,7 @@ - {{ block "title" . }}{{ .Site.Title }}{{ with .Params.Title }} | {{ . }}{{ end }}{{ end }} + {{ with .Params.Title }}{{ . }} | {{ end }} {{ block "title" . }}{{ .Site.Title }}{{ end }} From owner-dev-commits-doc-all@freebsd.org Sun May 23 20:58:41 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2635864F5A6 for ; Sun, 23 May 2021 20:58:41 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FpCPF0X3zz3qHn; Sun, 23 May 2021 20:58:41 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E8A0B1DDE3; Sun, 23 May 2021 20:58:40 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14NKweWJ023028; Sun, 23 May 2021 20:58:40 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14NKwehc023027; Sun, 23 May 2021 20:58:40 GMT (envelope-from git) Date: Sun, 23 May 2021 20:58:40 GMT Message-Id: <202105232058.14NKwehc023027@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Wolfram Schneider Subject: git: 6f56002b23 - main - add NetBSD 9.2 manual pages MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: wosch X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 6f56002b23384b8fdcd211f93b2c29ac52d42011 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 20:58:41 -0000 The branch main has been updated by wosch: URL: https://cgit.FreeBSD.org/doc/commit/?id=6f56002b23384b8fdcd211f93b2c29ac52d42011 commit 6f56002b23384b8fdcd211f93b2c29ac52d42011 Author: Wolfram Schneider AuthorDate: 2021-05-23 20:58:27 +0000 Commit: Wolfram Schneider CommitDate: 2021-05-23 20:58:27 +0000 add NetBSD 9.2 manual pages --- website/content/en/cgi/man.cgi | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/website/content/en/cgi/man.cgi b/website/content/en/cgi/man.cgi index edeb46dfeb..a000c04305 100755 --- a/website/content/en/cgi/man.cgi +++ b/website/content/en/cgi/man.cgi @@ -1,6 +1,6 @@ #!/usr/local/bin/perl -T # -# Copyright (c) 1996-2020 Wolfram Schneider +# Copyright (c) 1996-2021 Wolfram Schneider # All rights reserved. # # Redistribution and use in source and binary forms, with or without @@ -624,6 +624,7 @@ $manPathDefault = 'FreeBSD 12.2-RELEASE and Ports'; 'NetBSD 8.2', "$manLocalDir/NetBSD-8.2", 'NetBSD 9.0', "$manLocalDir/NetBSD-9.0", 'NetBSD 9.1', "$manLocalDir/NetBSD-9.1", + 'NetBSD 9.2', "$manLocalDir/NetBSD-9.2", '2.8 BSD', "$manLocalDir/2.8BSD", '2.9.1 BSD', "$manLocalDir/2.9.1BSD", @@ -864,6 +865,7 @@ my %arch = ( 'NetBSD 8.2' => { 'arch' => [qw/acorn26 acorn32 algor alpha amd64 amiga arc atari bebox cats cesfic cobalt dreamcast emips evbarm evbmips evbppc evbsh3 hp300 hpcarm hpcmips hpcsh hppa i386 ibmnws luna68k mac68k macppc mipsco mmeye mvme68k mvmeppc netwinder news68k newsmips next68k ofppc playstation2 pmax prep sandpoint sbmips sgimips shark sparc sparc64 sun2 sun3 vax x68k x86/] } , 'NetBSD 9.0' => { 'arch' => [qw/acorn26 acorn32 algor alpha amd64 amiga arc atari bebox cats cesfic cobalt dreamcast emips evbarm evbmips evbppc evbsh3 hp300 hpcarm hpcmips hpcsh hppa i386 ibmnws luna68k mac68k macppc mipsco mmeye mvme68k mvmeppc netwinder news68k newsmips next68k ofppc playstation2 pmax prep sandpoint sbmips sgimips shark sparc sparc64 sun2 sun3 vax x68k x86/] } , 'NetBSD 9.1' => { 'arch' => [qw/acorn26 acorn32 algor alpha amd64 amiga arc atari bebox cats cesfic cobalt dreamcast emips evbarm evbmips evbppc evbsh3 hp300 hpcarm hpcmips hpcsh hppa i386 ibmnws luna68k mac68k macppc mipsco mmeye mvme68k mvmeppc netwinder news68k newsmips next68k ofppc playstation2 pmax prep sandpoint sbmips sgimips shark sparc sparc64 sun2 sun3 vax x68k x86/] } , +'NetBSD 9.2' => { 'arch' => [qw/acorn26 acorn32 algor alpha amd64 amiga arc atari bebox cats cesfic cobalt dreamcast emips evbarm evbmips evbppc evbsh3 hp300 hpcarm hpcmips hpcsh hppa i386 ibmnws luna68k mac68k macppc mipsco mmeye mvme68k mvmeppc netwinder news68k newsmips next68k ofppc playstation2 pmax prep sandpoint sbmips sgimips shark sparc sparc64 sun2 sun3 vax x68k x86/] } , 'OpenBSD 4.7' => { 'arch' => [qw/alpha amd64 armish aviion hp300 hppa hppa64 i386 landisk loongson luna88k mac68k macppc mvme68k mvme88k mvmeppc palm sgi socppc sparc sparc64 vax zaurus/] }, 'OpenBSD 4.8' => { 'arch' => [qw/alpha amd64 armish aviion hp300 hppa hppa64 i386 landisk loongson luna88k mac68k macppc mvme68k mvme88k mvmeppc palm sgi socppc sparc sparc64 vax zaurus/] }, 'OpenBSD 4.9' => { 'arch' => [qw/alpha amd64 armish aviion hp300 hppa hppa64 i386 landisk loongson luna88k mac68k macppc mvme68k mvme88k mvmeppc palm sgi socppc sparc sparc64 vax zaurus/] }, @@ -929,7 +931,7 @@ while ( ( $key, $val ) = each %manPath ) { 'opendarwin', 'OpenDarwin 7.2.1', 'macosx', 'Darwin 8.0.1/ppc', - 'netbsd', 'NetBSD 9.1', + 'netbsd', 'NetBSD 9.2', 'openbsd', 'OpenBSD 6.9', 'v7', 'Unix Seventh Edition', 'v7man', 'Unix Seventh Edition', From owner-dev-commits-doc-all@freebsd.org Sun May 23 21:10:55 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2003A64FD71 for ; Sun, 23 May 2021 21:10:55 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FpCgM0Flmz4TTQ; Sun, 23 May 2021 21:10:55 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E4C5C1E52B; Sun, 23 May 2021 21:10:54 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14NLAsvg045271; Sun, 23 May 2021 21:10:54 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14NLAskx045270; Sun, 23 May 2021 21:10:54 GMT (envelope-from git) Date: Sun, 23 May 2021 21:10:54 GMT Message-Id: <202105232110.14NLAskx045270@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Sergio Carlavilla Delgado Subject: git: 3c5fc735b9 - main - Design 44BSD style, images path fix and correct minor fixes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: carlavilla X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 3c5fc735b9d6138a5d8c8f486f42e50d5c7ce734 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 21:10:55 -0000 The branch main has been updated by carlavilla: URL: https://cgit.FreeBSD.org/doc/commit/?id=3c5fc735b9d6138a5d8c8f486f42e50d5c7ce734 commit 3c5fc735b9d6138a5d8c8f486f42e50d5c7ce734 Author: Sergio Carlavilla Delgado AuthorDate: 2021-05-23 21:09:27 +0000 Commit: Sergio Carlavilla Delgado CommitDate: 2021-05-23 21:09:27 +0000 Design 44BSD style, images path fix and correct minor fixes Format the book with "One Sentence per Line" Fix the images path Minor fixes --- .../content/en/books/design-44bsd/_index.adoc | 620 ++++++++++++++++----- 1 file changed, 489 insertions(+), 131 deletions(-) diff --git a/documentation/content/en/books/design-44bsd/_index.adoc b/documentation/content/en/books/design-44bsd/_index.adoc index 800409ae10..0fde927c10 100644 --- a/documentation/content/en/books/design-44bsd/_index.adoc +++ b/documentation/content/en/books/design-44bsd/_index.adoc @@ -37,7 +37,7 @@ include::shared/releases.adoc[] include::shared/en/mailing-lists.adoc[] include::shared/en/teams.adoc[] include::shared/en/urls.adoc[] -:imagesdir: ../../images/books/design-44bsd/ +:imagesdir: ../../../images/books/design-44bsd/ endif::[] ifeval::["{backend}" == "pdf"] @@ -70,26 +70,44 @@ toc::[] [[overview-facilities]] === 4.4BSD Facilities and the Kernel -The 4.4BSD kernel provides four basic facilities: processes, a filesystem, communications, and system startup. This section outlines where each of these four basic services is described in this book. +The 4.4BSD kernel provides four basic facilities: processes, a filesystem, communications, and system startup. +This section outlines where each of these four basic services is described in this book. . Processes constitute a thread of control in an address space. Mechanisms for creating, terminating, and otherwise controlling processes are described in Chapter 4. The system multiplexes separate virtual-address spaces for each process; this memory management is discussed in Chapter 5. . The user interface to the filesystem and devices is similar; common aspects are discussed in Chapter 6. The filesystem is a set of named files, organized in a tree-structured hierarchy of directories, and of operations to manipulate them, as presented in Chapter 7. Files reside on physical media such as disks. 4.4BSD supports several organizations of data on the disk, as set forth in Chapter 8. Access to files on remote machines is the subject of Chapter 9. Terminals are used to access the system; their operation is the subject of Chapter 10. . Communication mechanisms provided by traditional UNIX systems include simplex reliable byte streams between related processes (see pipes, Section 11.1), and notification of exceptional events (see signals, Section 4.7). 4.4BSD also has a general interprocess-communication facility. This facility, described in Chapter 11, uses access mechanisms distinct from those of the filesystem, but, once a connection is set up, a process can access it as though it were a pipe. There is a general networking framework, discussed in Chapter 12, that is normally used as a layer underlying the IPC facility. Chapter 13 describes a particular networking implementation in detail. . Any real operating system has operational issues, such as how to start it running. Startup and operational issues are described in Chapter 14. -Sections 2.3 through 2.14 present introductory material related to Chapters 3 through 14. We shall define terms, mention basic system calls, and explore historical developments. Finally, we shall give the reasons for many major design decisions. +Sections 2.3 through 2.14 present introductory material related to Chapters 3 through 14. +We shall define terms, mention basic system calls, and explore historical developments. +Finally, we shall give the reasons for many major design decisions. ==== The Kernel -The _kernel_ is the part of the system that runs in protected mode and mediates access by all user programs to the underlying hardware (e.g., CPU, disks, terminals, network links) and software constructs (e.g., filesystem, network protocols). The kernel provides the basic system facilities; it creates and manages processes, and provides functions to access the filesystem and communication facilities. These functions, called _system calls_ appear to user processes as library subroutines. These system calls are the only interface that processes have to these facilities. Details of the system-call mechanism are given in Chapter 3, as are descriptions of several kernel mechanisms that do not execute as the direct result of a process doing a system call. +The _kernel_ is the part of the system that runs in protected mode and mediates access by all user programs to the underlying hardware (e.g., CPU, disks, terminals, network links) and software constructs (e.g., filesystem, network protocols). +The kernel provides the basic system facilities; it creates and manages processes, and provides functions to access the filesystem and communication facilities. +These functions, called _system calls_ appear to user processes as library subroutines. +These system calls are the only interface that processes have to these facilities. +Details of the system-call mechanism are given in Chapter 3, as are descriptions of several kernel mechanisms that do not execute as the direct result of a process doing a system call. -A _kernel_ in traditional operating-system terminology, is a small nucleus of software that provides only the minimal facilities necessary for implementing additional operating-system services. In contemporary research operating systems -- such as Chorus <>, Mach <>, Tunis <>, and the V Kernel <> -- this division of functionality is more than just a logical one. Services such as filesystems and networking protocols are implemented as client application processes of the nucleus or kernel. +A _kernel_ in traditional operating-system terminology, is a small nucleus of software that provides only the minimal facilities necessary for implementing additional operating-system services. +In contemporary research operating systems -- such as Chorus <>, Mach <>, Tunis <>, and the V Kernel <> -- this division of functionality is more than just a logical one. +Services such as filesystems and networking protocols are implemented as client application processes of the nucleus or kernel. -The 4.4BSD kernel is not partitioned into multiple processes. This basic design decision was made in the earliest versions of UNIX. The first two implementations by Ken Thompson had no memory mapping, and thus made no hardware-enforced distinction between user and kernel space <>. A message-passing system could have been implemented as readily as the actually implemented model of kernel and user processes. The monolithic kernel was chosen for simplicity and performance. And the early kernels were small; the inclusion of facilities such as networking into the kernel has increased its size. The current trend in operating-systems research is to reduce the kernel size by placing such services in user space. +The 4.4BSD kernel is not partitioned into multiple processes. +This basic design decision was made in the earliest versions of UNIX. +The first two implementations by Ken Thompson had no memory mapping, and thus made no hardware-enforced distinction between user and kernel space <>. +A message-passing system could have been implemented as readily as the actually implemented model of kernel and user processes. +The monolithic kernel was chosen for simplicity and performance. +And the early kernels were small; the inclusion of facilities such as networking into the kernel has increased its size. +The current trend in operating-systems research is to reduce the kernel size by placing such services in user space. -Users ordinarily interact with the system through a command-language interpreter, called a _shell_, and perhaps through additional user application programs. Such programs and the shell are implemented with processes. Details of such programs are beyond the scope of this book, which instead concentrates almost exclusively on the kernel. +Users ordinarily interact with the system through a command-language interpreter, called a _shell_, and perhaps through additional user application programs. +Such programs and the shell are implemented with processes. +Details of such programs are beyond the scope of this book, which instead concentrates almost exclusively on the kernel. -Sections 2.3 and 2.4 describe the services provided by the 4.4BSD kernel, and give an overview of the latter's design. Later chapters describe the detailed design and implementation of these services as they appear in 4.4BSD. +Sections 2.3 and 2.4 describe the services provided by the 4.4BSD kernel, and give an overview of the latter's design. +Later chapters describe the detailed design and implementation of these services as they appear in 4.4BSD. [[overview-kernel-organization]] === Kernel Organization @@ -100,7 +118,8 @@ In this section, we view the organization of the 4.4BSD kernel in two ways: . As a static body of software, categorized by the functionality offered by the modules that make up the kernel . By its dynamic operation, categorized according to the services provided to users -The largest part of the kernel implements the system services that applications access through system calls. In 4.4BSD, this software has been organized according to the following: +The largest part of the kernel implements the system services that applications access through system calls. +In 4.4BSD, this software has been organized according to the following: * Basic kernel facilities: timer and system-clock handling, descriptor management, and process management * Memory-management support: paging and swapping @@ -139,7 +158,10 @@ The largest part of the kernel implements the system services that applications Most of the software in these categories is machine independent and is portable across different hardware architectures. -The machine-dependent aspects of the kernel are isolated from the mainstream code. In particular, none of the machine-independent code contains conditional code for specific architecture. When an architecture-dependent action is needed, the machine-independent code calls an architecture-dependent function that is located in the machine-dependent code. The software that is machine dependent includes +The machine-dependent aspects of the kernel are isolated from the mainstream code. +In particular, none of the machine-independent code contains conditional code for specific architecture. +When an architecture-dependent action is needed, the machine-independent code calls an architecture-dependent function that is located in the machine-dependent code. +The software that is machine dependent includes * Low-level system-startup actions * Trap and fault handling @@ -161,112 +183,247 @@ The machine-dependent aspects of the kernel are isolated from the mainstream cod |HP/UX compatibility |4,683 |2.3 |=== -<> summarizes the machine-independent software that constitutes the 4.4BSD kernel for the HP300. The numbers in column 2 are for lines of C source code, header files, and assembly language. Virtually all the software in the kernel is written in the C programming language; less than 2 percent is written in assembly language. As the statistics in <> show, the machine-dependent software, excluding HP/UX and device support, accounts for a minuscule 6.9 percent of the kernel. +<> summarizes the machine-independent software that constitutes the 4.4BSD kernel for the HP300. +The numbers in column 2 are for lines of C source code, header files, and assembly language. +Virtually all the software in the kernel is written in the C programming language; less than 2 percent is written in assembly language. +As the statistics in <> show, the machine-dependent software, excluding HP/UX and device support, accounts for a minuscule 6.9 percent of the kernel. -Only a small part of the kernel is devoted to initializing the system. This code is used when the system is _bootstrapped_ into operation and is responsible for setting up the kernel hardware and software environment (see Chapter 14). Some operating systems (especially those with limited physical memory) discard or _overlay_ the software that performs these functions after that software has been executed. The 4.4BSD kernel does not reclaim the memory used by the startup code because that memory space is barely 0.5 percent of the kernel resources used on a typical machine. Also, the startup code does not appear in one place in the kernel -- it is scattered throughout, and it usually appears in places logically associated with what is being initialized. +Only a small part of the kernel is devoted to initializing the system. +This code is used when the system is _bootstrapped_ into operation and is responsible for setting up the kernel hardware and software environment (see Chapter 14). +Some operating systems (especially those with limited physical memory) discard or _overlay_ the software that performs these functions after that software has been executed. +The 4.4BSD kernel does not reclaim the memory used by the startup code because that memory space is barely 0.5 percent of the kernel resources used on a typical machine. +Also, the startup code does not appear in one place in the kernel -- it is scattered throughout, and it usually appears in places logically associated with what is being initialized. [[overview-kernel-service]] === Kernel Services -The boundary between the kernel- and user-level code is enforced by hardware-protection facilities provided by the underlying hardware. The kernel operates in a separate address space that is inaccessible to user processes. Privileged operations -- such as starting I/O and halting the central processing unit (CPU) -- are available to only the kernel. Applications request services from the kernel with _system calls_. System calls are used to cause the kernel to execute complicated operations, such as writing data to secondary storage, and simple operations, such as returning the current time of day. All system calls appear _synchronous_ to applications: The application does not run while the kernel does the actions associated with a system call. The kernel may finish some operations associated with a system call after it has returned. For example, a _write_ system call will copy the data to be written from the user process to a kernel buffer while the process waits, but will usually return from the system call before the kernel buffer is written to the disk. - -A system call usually is implemented as a hardware trap that changes the CPU's execution mode and the current address-space mapping. Parameters supplied by users in system calls are validated by the kernel before being used. Such checking ensures the integrity of the system. All parameters passed into the kernel are copied into the kernel's address space, to ensure that validated parameters are not changed as a side effect of the system call. System-call results are returned by the kernel, either in hardware registers or by their values being copied to user-specified memory addresses. Like parameters passed into the kernel, addresses used for the return of results must be validated to ensure that they are part of an application's address space. If the kernel encounters an error while processing a system call, it returns an error code to the user. For the C programming language, this error code is stored in the global variable _errno_, and the function that executed the system call r eturns the value -1. - -User applications and the kernel operate independently of each other. 4.4BSD does not store I/O control blocks or other operating-system-related data structures in the application's address space. Each user-level application is provided an independent address space in which it executes. The kernel makes most state changes, such as suspending a process while another is running, invisible to the processes involved. +The boundary between the kernel- and user-level code is enforced by hardware-protection facilities provided by the underlying hardware. +The kernel operates in a separate address space that is inaccessible to user processes. +Privileged operations -- such as starting I/O and halting the central processing unit (CPU) -- are available to only the kernel. +Applications request services from the kernel with _system calls_. +System calls are used to cause the kernel to execute complicated operations, such as writing data to secondary storage, and simple operations, such as returning the current time of day. +All system calls appear _synchronous_ to applications: The application does not run while the kernel does the actions associated with a system call. +The kernel may finish some operations associated with a system call after it has returned. +For example, a _write_ system call will copy the data to be written from the user process to a kernel buffer while the process waits, but will usually return from the system call before the kernel buffer is written to the disk. + +A system call usually is implemented as a hardware trap that changes the CPU's execution mode and the current address-space mapping. +Parameters supplied by users in system calls are validated by the kernel before being used. +Such checking ensures the integrity of the system. +All parameters passed into the kernel are copied into the kernel's address space, to ensure that validated parameters are not changed as a side effect of the system call. +System-call results are returned by the kernel, either in hardware registers or by their values being copied to user-specified memory addresses. +Like parameters passed into the kernel, addresses used for the return of results must be validated to ensure that they are part of an application's address space. +If the kernel encounters an error while processing a system call, it returns an error code to the user. +For the C programming language, this error code is stored in the global variable _errno_, and the function that executed the system call returns the value -1. + +User applications and the kernel operate independently of each other. +4.4BSD does not store I/O control blocks or other operating-system-related data structures in the application's address space. +Each user-level application is provided an independent address space in which it executes. +The kernel makes most state changes, such as suspending a process while another is running, invisible to the processes involved. [[overview-process-management]] === Process Management -4.4BSD supports a multitasking environment. Each task or thread of execution is termed a _process_. The _context_ of a 4.4BSD process consists of user-level state, including the contents of its address space and the run-time environment, and kernel-level state, which includes scheduling parameters, resource controls, and identification information. The context includes everything used by the kernel in providing services for the process. Users can create processes, control the processes' execution, and receive notification when the processes' execution status changes. Every process is assigned a unique value, termed a _process identifier_ (PID). This value is used by the kernel to identify a process when reporting status changes to a user, and by a user when referencing a process in a system call. +4.4BSD supports a multitasking environment. +Each task or thread of execution is termed a _process_. +The _context_ of a 4.4BSD process consists of user-level state, including the contents of its address space and the run-time environment, and kernel-level state, which includes scheduling parameters, resource controls, and identification information. +The context includes everything used by the kernel in providing services for the process. +Users can create processes, control the processes' execution, and receive notification when the processes' execution status changes. +Every process is assigned a unique value, termed a _process identifier_ (PID). +This value is used by the kernel to identify a process when reporting status changes to a user, and by a user when referencing a process in a system call. -The kernel creates a process by duplicating the context of another process. The new process is termed a _child process_ of the original _parent process_ The context duplicated in process creation includes both the user-level execution state of the process and the process's system state managed by the kernel. Important components of the kernel state are described in Chapter 4. +The kernel creates a process by duplicating the context of another process. +The new process is termed a _child process_ of the original _parent process_ +The context duplicated in process creation includes both the user-level execution state of the process and the process's system state managed by the kernel. +Important components of the kernel state are described in Chapter 4. [[fig-process-lifecycle]] .Process lifecycle image:fig1.png[Process lifecycle] -The process lifecycle is depicted in <>. A process may create a new process that is a copy of the original by using the _fork_ system call. The _fork_ call returns twice: once in the parent process, where the return value is the process identifier of the child, and once in the child process, where the return value is 0. The parent-child relationship induces a hierarchical structure on the set of processes in the system. The new process shares all its parent's resources, such as file descriptors, signal-handling status, and memory layout. +The process lifecycle is depicted in <>. +A process may create a new process that is a copy of the original by using the _fork_ system call. +The _fork_ call returns twice: once in the parent process, where the return value is the process identifier of the child, and once in the child process, where the return value is 0. +The parent-child relationship induces a hierarchical structure on the set of processes in the system. +The new process shares all its parent's resources, such as file descriptors, signal-handling status, and memory layout. -Although there are occasions when the new process is intended to be a copy of the parent, the loading and execution of a different program is a more useful and typical action. A process can overlay itself with the memory image of another program, passing to the newly created image a set of parameters, using the system call _execve_. One parameter is the name of a file whose contents are in a format recognized by the system -- either a binary-executable file or a file that causes the execution of a specified interpreter program to process its contents. +Although there are occasions when the new process is intended to be a copy of the parent, the loading and execution of a different program is a more useful and typical action. +A process can overlay itself with the memory image of another program, passing to the newly created image a set of parameters, using the system call _execve_. +One parameter is the name of a file whose contents are in a format recognized by the system -- either a binary-executable file or a file that causes the execution of a specified interpreter program to process its contents. -A process may terminate by executing an _exit_ system call, sending 8 bits of exit status to its parent. If a process wants to communicate more than a single byte of information with its parent, it must either set up an interprocess-communication channel using pipes or sockets, or use an intermediate file. Interprocess communication is discussed extensively in Chapter 11. +A process may terminate by executing an _exit_ system call, sending 8 bits of exit status to its parent. +If a process wants to communicate more than a single byte of information with its parent, it must either set up an interprocess-communication channel using pipes or sockets, or use an intermediate file. +Interprocess communication is discussed extensively in Chapter 11. -A process can suspend execution until any of its child processes terminate using the _wait_ system call, which returns the PID and exit status of the terminated child process. A parent process can arrange to be notified by a signal when a child process exits or terminates abnormally. Using the _wait4_ system call, the parent can retrieve information about the event that caused termination of the child process and about resources consumed by the process during its lifetime. If a process is orphaned because its parent exits before it is finished, then the kernel arranges for the child's exit status to be passed back to a special system process _init_: see Sections 3.1 and 14.6). +A process can suspend execution until any of its child processes terminate using the _wait_ system call, which returns the PID and exit status of the terminated child process. +A parent process can arrange to be notified by a signal when a child process exits or terminates abnormally. +Using the _wait4_ system call, the parent can retrieve information about the event that caused termination of the child process and about resources consumed by the process during its lifetime. +If a process is orphaned because its parent exits before it is finished, then the kernel arranges for the child's exit status to be passed back to a special system process _init_: see Sections 3.1 and 14.6). The details of how the kernel creates and destroys processes are given in Chapter 5. -Processes are scheduled for execution according to a _process-priority_ parameter. This priority is managed by a kernel-based scheduling algorithm. Users can influence the scheduling of a process by specifying a parameter (_nice_) that weights the overall scheduling priority, but are still obligated to share the underlying CPU resources according to the kernel's scheduling policy. +Processes are scheduled for execution according to a _process-priority_ parameter. +This priority is managed by a kernel-based scheduling algorithm. +Users can influence the scheduling of a process by specifying a parameter (_nice_) that weights the overall scheduling priority, but are still obligated to share the underlying CPU resources according to the kernel's scheduling policy. ==== Signals -The system defines a set of _signals_ that may be delivered to a process. Signals in 4.4BSD are modeled after hardware interrupts. A process may specify a user-level subroutine to be a _handler_ to which a signal should be delivered. When a signal is generated, it is blocked from further occurrence while it is being _caught_ by the handler. Catching a signal involves saving the current process context and building a new one in which to run the handler. The signal is then delivered to the handler, which can either abort the process or return to the executing process (perhaps after setting a global variable). If the handler returns, the signal is unblocked and can be generated (and caught) again. +The system defines a set of _signals_ that may be delivered to a process. +Signals in 4.4BSD are modeled after hardware interrupts. +A process may specify a user-level subroutine to be a _handler_ to which a signal should be delivered. +When a signal is generated, it is blocked from further occurrence while it is being _caught_ by the handler. +Catching a signal involves saving the current process context and building a new one in which to run the handler. +The signal is then delivered to the handler, which can either abort the process or return to the executing process (perhaps after setting a global variable). +If the handler returns, the signal is unblocked and can be generated (and caught) again. -Alternatively, a process may specify that a signal is to be _ignored_, or that a default action, as determined by the kernel, is to be taken. The default action of certain signals is to terminate the process. This termination may be accompanied by creation of a _core file_ that contains the current memory image of the process for use in postmortem debugging. +Alternatively, a process may specify that a signal is to be _ignored_, or that a default action, as determined by the kernel, is to be taken. +The default action of certain signals is to terminate the process. +This termination may be accompanied by creation of a _core file_ that contains the current memory image of the process for use in postmortem debugging. -Some signals cannot be caught or ignored. These signals include _SIGKILL_, which kills runaway processes, and the job-control signal _SIGSTOP_. +Some signals cannot be caught or ignored. +These signals include _SIGKILL_, which kills runaway processes, and the job-control signal _SIGSTOP_. -A process may choose to have signals delivered on a special stack so that sophisticated software stack manipulations are possible. For example, a language supporting coroutines needs to provide a stack for each coroutine. The language run-time system can allocate these stacks by dividing up the single stack provided by 4.4BSD. If the kernel does not support a separate signal stack, the space allocated for each coroutine must be expanded by the amount of space required to catch a signal. +A process may choose to have signals delivered on a special stack so that sophisticated software stack manipulations are possible. +For example, a language supporting coroutines needs to provide a stack for each coroutine. +The language run-time system can allocate these stacks by dividing up the single stack provided by 4.4BSD. +If the kernel does not support a separate signal stack, the space allocated for each coroutine must be expanded by the amount of space required to catch a signal. -All signals have the same _priority_. If multiple signals are pending simultaneously, the order in which signals are delivered to a process is implementation specific. Signal handlers execute with the signal that caused their invocation to be blocked, but other signals may yet occur. Mechanisms are provided so that processes can protect critical sections of code against the occurrence of specified signals. +All signals have the same _priority_. +If multiple signals are pending simultaneously, the order in which signals are delivered to a process is implementation specific. +Signal handlers execute with the signal that caused their invocation to be blocked, but other signals may yet occur. +Mechanisms are provided so that processes can protect critical sections of code against the occurrence of specified signals. The detailed design and implementation of signals is described in Section 4.7. ==== Process Groups and Sessions -Processes are organized into _process groups_. Process groups are used to control access to terminals and to provide a means of distributing signals to collections of related processes. A process inherits its process group from its parent process. Mechanisms are provided by the kernel to allow a process to alter its process group or the process group of its descendents. Creating a new process group is easy; the value of a new process group is ordinarily the process identifier of the creating process. +Processes are organized into _process groups_. +Process groups are used to control access to terminals and to provide a means of distributing signals to collections of related processes. +A process inherits its process group from its parent process. +Mechanisms are provided by the kernel to allow a process to alter its process group or the process group of its descendents. +Creating a new process group is easy; the value of a new process group is ordinarily the process identifier of the creating process. -The group of processes in a process group is sometimes referred to as a _job_ and is manipulated by high-level system software, such as the shell. A common kind of job created by a shell is a _pipeline_ of several processes connected by pipes, such that the output of the first process is the input of the second, the output of the second is the input of the third, and so forth. The shell creates such a job by forking a process for each stage of the pipeline, then putting all those processes into a separate process group. +The group of processes in a process group is sometimes referred to as a _job_ and is manipulated by high-level system software, such as the shell. +A common kind of job created by a shell is a _pipeline_ of several processes connected by pipes, such that the output of the first process is the input of the second, the output of the second is the input of the third, and so forth. +The shell creates such a job by forking a process for each stage of the pipeline, then putting all those processes into a separate process group. -A user process can send a signal to each process in a process group, as well as to a single process. A process in a specific process group may receive software interrupts affecting the group, causing the group to suspend or resume execution, or to be interrupted or terminated. +A user process can send a signal to each process in a process group, as well as to a single process. +A process in a specific process group may receive software interrupts affecting the group, causing the group to suspend or resume execution, or to be interrupted or terminated. -A terminal has a process-group identifier assigned to it. This identifier is normally set to the identifier of a process group associated with the terminal. A job-control shell may create a number of process groups associated with the same terminal; the terminal is the _controlling terminal_ for each process in these groups. A process may read from a descriptor for its controlling terminal only if the terminal's process-group identifier matches that of the process. If the identifiers do not match, the process will be blocked if it attempts to read from the terminal. By changing the process-group identifier of the terminal, a shell can arbitrate a terminal among several different jobs. This arbitration is called _job control_ and is described, with process groups, in Section 4.8. +A terminal has a process-group identifier assigned to it. +This identifier is normally set to the identifier of a process group associated with the terminal. +A job-control shell may create a number of process groups associated with the same terminal; the terminal is the _controlling terminal_ for each process in these groups. +A process may read from a descriptor for its controlling terminal only if the terminal's process-group identifier matches that of the process. +If the identifiers do not match, the process will be blocked if it attempts to read from the terminal. +By changing the process-group identifier of the terminal, a shell can arbitrate a terminal among several different jobs. +This arbitration is called _job control_ and is described, with process groups, in Section 4.8. -Just as a set of related processes can be collected into a process group, a set of process groups can be collected into a _session_. The main uses for sessions are to create an isolated environment for a daemon process and its children, and to collect together a user's login shell and the jobs that that shell spawns. +Just as a set of related processes can be collected into a process group, a set of process groups can be collected into a _session_. +The main uses for sessions are to create an isolated environment for a daemon process and its children, and to collect together a user's login shell and the jobs that that shell spawns. [[overview-memory-management]] === Memory Management -Each process has its own private address space. The address space is initially divided into three logical segments: _text_, _data_, and _stack_. The text segment is read-only and contains the machine instructions of a program. The data and stack segments are both readable and writable. The data segment contains the initialized and uninitialized data portions of a program, whereas the stack segment holds the application's run-time stack. On most machines, the stack segment is extended automatically by the kernel as the process executes. A process can expand or contract its data segment by making a system call, whereas a process can change the size of its text segment only when the segment's contents are overlaid with data from the filesystem, or when debugging takes place. The initial contents of the segments of a child process are duplicates of the segments of a parent process. - -The entire contents of a process address space do not need to be resident for a process to execute. If a process references a part of its address space that is not resident in main memory, the system _pages_ the necessary information into memory. When system resources are scarce, the system uses a two-level approach to maintain available resources. If a modest amount of memory is available, the system will take memory resources away from processes if these resources have not been used recently. Should there be a severe resource shortage, the system will resort to _swapping_ the entire context of a process to secondary storage. The _demand paging_ and _swapping_ done by the system are effectively transparent to processes. A process may, however, advise the system about expected future memory utilization as a performance aid. +Each process has its own private address space. +The address space is initially divided into three logical segments: _text_, _data_, and _stack_. +The text segment is read-only and contains the machine instructions of a program. +The data and stack segments are both readable and writable. +The data segment contains the initialized and uninitialized data portions of a program, whereas the stack segment holds the application's run-time stack. +On most machines, the stack segment is extended automatically by the kernel as the process executes. +A process can expand or contract its data segment by making a system call, whereas a process can change the size of its text segment only when the segment's contents are overlaid with data from the filesystem, or when debugging takes place. +The initial contents of the segments of a child process are duplicates of the segments of a parent process. + +The entire contents of a process address space do not need to be resident for a process to execute. +If a process references a part of its address space that is not resident in main memory, the system _pages_ the necessary information into memory. +When system resources are scarce, the system uses a two-level approach to maintain available resources. +If a modest amount of memory is available, the system will take memory resources away from processes if these resources have not been used recently. +Should there be a severe resource shortage, the system will resort to _swapping_ the entire context of a process to secondary storage. +The _demand paging_ and _swapping_ done by the system are effectively transparent to processes. +A process may, however, advise the system about expected future memory utilization as a performance aid. ==== BSD Memory-Management Design Decisions -The support of large sparse address spaces, mapped files, and shared memory was a requirement for 4.2BSD. An interface was specified, called _mmap_, that allowed unrelated processes to request a shared mapping of a file into their address spaces. If multiple processes mapped the same file into their address spaces, changes to the file's portion of an address space by one process would be reflected in the area mapped by the other processes, as well as in the file itself. Ultimately, 4.2BSD was shipped without the _mmap_ interface, because of pressure to make other features, such as networking, available. - -Further development of the _mmap_ interface continued during the work on 4.3BSD. Over 40 companies and research groups participated in the discussions leading to the revised architecture that was described in the Berkeley Software Architecture Manual <>. Several of the companies have implemented the revised interface <>. - -Once again, time pressure prevented 4.3BSD from providing an implementation of the interface. Although the latter could have been built into the existing 4.3BSD virtual-memory system, the developers decided not to put it in because that implementation was nearly 10 years old. Furthermore, the original virtual-memory design was based on the assumption that computer memories were small and expensive, whereas disks were locally connected, fast, large, and inexpensive. Thus, the virtual-memory system was designed to be frugal with its use of memory at the expense of generating extra disk traffic. In addition, the 4.3BSD implementation was riddled with VAX memory-management hardware dependencies that impeded its portability to other computer architectures. Finally, the virtual-memory system was not designed to support the tightly coupled multiprocessors that are becoming increasingly common and important today. - -Attempts to improve the old implementation incrementally seemed doomed to failure. A completely new design, on the other hand, could take advantage of large memories, conserve disk transfers, and have the potential to run on multiprocessors. Consequently, the virtual-memory system was completely replaced in 4.4BSD. The 4.4BSD virtual-memory system is based on the Mach 2.0 VM system <>. with updates from Mach 2.5 and Mach 3.0. It features efficient support for sharing, a clean separation of machine-independent and machine-dependent features, as well as (currently unused) multiprocessor support. Processes can map files anywhere in their address space. They can share parts of their address space by doing a shared mapping of the same file. Changes made by one process are visible in the address space of the other process, and also are written back to the file itself. Processes can also request private mappings of a file, which prevents any changes that they make from being visible to other processes mapping the file or being written back to the file itself. - -Another issue with the virtual-memory system is the way that information is passed into the kernel when a system call is made. 4.4BSD always copies data from the process address space into a buffer in the kernel. For read or write operations that are transferring large quantities of data, doing the copy can be time consuming. An alternative to doing the copying is to remap the process memory into the kernel. The 4.4BSD kernel always copies the data for several reasons: +The support of large sparse address spaces, mapped files, and shared memory was a requirement for 4.2BSD. +An interface was specified, called _mmap_, that allowed unrelated processes to request a shared mapping of a file into their address spaces. +If multiple processes mapped the same file into their address spaces, changes to the file's portion of an address space by one process would be reflected in the area mapped by the other processes, as well as in the file itself. +Ultimately, 4.2BSD was shipped without the _mmap_ interface, because of pressure to make other features, such as networking, available. + +Further development of the _mmap_ interface continued during the work on 4.3BSD. +Over 40 companies and research groups participated in the discussions leading to the revised architecture that was described in the Berkeley Software Architecture Manual <>. +Several of the companies have implemented the revised interface <>. + +Once again, time pressure prevented 4.3BSD from providing an implementation of the interface. +Although the latter could have been built into the existing 4.3BSD virtual-memory system, the developers decided not to put it in because that implementation was nearly 10 years old. +Furthermore, the original virtual-memory design was based on the assumption that computer memories were small and expensive, whereas disks were locally connected, fast, large, and inexpensive. +Thus, the virtual-memory system was designed to be frugal with its use of memory at the expense of generating extra disk traffic. +In addition, the 4.3BSD implementation was riddled with VAX memory-management hardware dependencies that impeded its portability to other computer architectures. +Finally, the virtual-memory system was not designed to support the tightly coupled multiprocessors that are becoming increasingly common and important today. + +Attempts to improve the old implementation incrementally seemed doomed to failure. +A completely new design, on the other hand, could take advantage of large memories, conserve disk transfers, and have the potential to run on multiprocessors. +Consequently, the virtual-memory system was completely replaced in 4.4BSD. +The 4.4BSD virtual-memory system is based on the Mach 2.0 VM system <>. with updates from Mach 2.5 and Mach 3.0. +It features efficient support for sharing, a clean separation of machine-independent and machine-dependent features, as well as (currently unused) multiprocessor support. +Processes can map files anywhere in their address space. +They can share parts of their address space by doing a shared mapping of the same file. +Changes made by one process are visible in the address space of the other process, and also are written back to the file itself. +Processes can also request private mappings of a file, which prevents any changes that they make from being visible to other processes mapping the file or being written back to the file itself. + +Another issue with the virtual-memory system is the way that information is passed into the kernel when a system call is made. +4.4BSD always copies data from the process address space into a buffer in the kernel. +For read or write operations that are transferring large quantities of data, doing the copy can be time consuming. +An alternative to doing the copying is to remap the process memory into the kernel. +The 4.4BSD kernel always copies the data for several reasons: * Often, the user data are not page aligned and are not a multiple of the hardware page length. * If the page is taken away from the process, it will no longer be able to reference that page. Some programs depend on the data remaining in the buffer even after those data have been written. * If the process is allowed to keep a copy of the page (as it is in current 4.4BSD semantics), the page must be made _copy-on-write_. A copy-on-write page is one that is protected against being written by being made read-only. If the process attempts to modify the page, the kernel gets a write fault. The kernel then makes a copy of the page that the process can modify. Unfortunately, the typical process will immediately try to write new data to its output buffer, forcing the data to be copied anyway. * When pages are remapped to new virtual-memory addresses, most memory-management hardware requires that the hardware address-translation cache be purged selectively. The cache purges are often slow. The net effect is that remapping is slower than copying for blocks of data less than 4 to 8 Kbyte. -The biggest incentives for memory mapping are the needs for accessing big files and for passing large quantities of data between processes. The _mmap_ interface provides a way for both of these tasks to be done without copying. +The biggest incentives for memory mapping are the needs for accessing big files and for passing large quantities of data between processes. +The _mmap_ interface provides a way for both of these tasks to be done without copying. ==== Memory Management Inside the Kernel -The kernel often does allocations of memory that are needed for only the duration of a single system call. In a user process, such short-term memory would be allocated on the run-time stack. Because the kernel has a limited run-time stack, it is not feasible to allocate even moderate-sized blocks of memory on it. Consequently, such memory must be allocated through a more dynamic mechanism. For example, when the system must translate a pathname, it must allocate a 1-Kbyte buffer to hold the name. Other blocks of memory must be more persistent than a single system call, and thus could not be allocated on the stack even if there was space. An example is protocol-control blocks that remain throughout the duration of a network connection. - -Demands for dynamic memory allocation in the kernel have increased as more services have been added. A generalized memory allocator reduces the complexity of writing code inside the kernel. Thus, the 4.4BSD kernel has a single memory allocator that can be used by any part of the system. It has an interface similar to the C library routines _malloc_ and _free_ that provide memory allocation to application programs <>. Like the C library interface, the allocation routine takes a parameter specifying the size of memory that is needed. The range of sizes for memory requests is not constrained; however, physical memory is allocated and is not paged. The free routine takes a pointer to the storage being freed, but does not require the size of the piece of memory being freed. +The kernel often does allocations of memory that are needed for only the duration of a single system call. +In a user process, such short-term memory would be allocated on the run-time stack. +Because the kernel has a limited run-time stack, it is not feasible to allocate even moderate-sized blocks of memory on it. +Consequently, such memory must be allocated through a more dynamic mechanism. +For example, when the system must translate a pathname, it must allocate a 1-Kbyte buffer to hold the name. +Other blocks of memory must be more persistent than a single system call, and thus could not be allocated on the stack even if there was space. +An example is protocol-control blocks that remain throughout the duration of a network connection. + +Demands for dynamic memory allocation in the kernel have increased as more services have been added. +A generalized memory allocator reduces the complexity of writing code inside the kernel. +Thus, the 4.4BSD kernel has a single memory allocator that can be used by any part of the system. +It has an interface similar to the C library routines _malloc_ and _free_ that provide memory allocation to application programs <>. +Like the C library interface, the allocation routine takes a parameter specifying the size of memory that is needed. +The range of sizes for memory requests is not constrained; however, physical memory is allocated and is not paged. +The free routine takes a pointer to the storage being freed, but does not require the size of the piece of memory being freed. [[overview-io-system]] === I/O System -The basic model of the UNIX I/O system is a sequence of bytes that can be accessed either randomly or sequentially. There are no _access methods_ and no _control blocks_ in a typical UNIX user process. +The basic model of the UNIX I/O system is a sequence of bytes that can be accessed either randomly or sequentially. +There are no _access methods_ and no _control blocks_ in a typical UNIX user process. -Different programs expect various levels of structure, but the kernel does not impose structure on I/O. For instance, the convention for text files is lines of ASCII characters separated by a single newline character (the ASCII line-feed character), but the kernel knows nothing about this convention. For the purposes of most programs, the model is further simplified to being a stream of data bytes, or an _I/O stream_. It is this single common data form that makes the characteristic UNIX tool-based approach work <>. An I/O stream from one program can be fed as input to almost any other program. (This kind of traditional UNIX I/O stream should not be confused with the Eighth Edition stream I/O system or with the System V, Release 3 STREAMS, both of which can be accessed as traditional I/O streams.) +Different programs expect various levels of structure, but the kernel does not impose structure on I/O. +For instance, the convention for text files is lines of ASCII characters separated by a single newline character (the ASCII line-feed character), but the kernel knows nothing about this convention. +For the purposes of most programs, the model is further simplified to being a stream of data bytes, or an _I/O stream_. +It is this single common data form that makes the characteristic UNIX tool-based approach work <>. +An I/O stream from one program can be fed as input to almost any other program. +(This kind of traditional UNIX I/O stream should not be confused with the Eighth Edition stream I/O system or with the System V, Release 3 STREAMS, both of which can be accessed as traditional I/O streams.) ==== Descriptors and I/O -UNIX processes use _descriptors_ to reference I/O streams. Descriptors are small unsigned integers obtained from the _open_ and _socket_ system calls. The _open_ system call takes as arguments the name of a file and a permission mode to specify whether the file should be open for reading or for writing, or for both. This system call also can be used to create a new, empty file. A _read_ or _write_ system call can be applied to a descriptor to transfer data. The _close_ system call can be used to deallocate any descriptor. +UNIX processes use _descriptors_ to reference I/O streams. +Descriptors are small unsigned integers obtained from the _open_ and _socket_ system calls. +The _open_ system call takes as arguments the name of a file and a permission mode to specify whether the file should be open for reading or for writing, or for both. +This system call also can be used to create a new, empty file. +A _read_ or _write_ system call can be applied to a descriptor to transfer data. +The _close_ system call can be used to deallocate any descriptor. -Descriptors represent underlying objects supported by the kernel, and are created by system calls specific to the type of object. In 4.4BSD, three kinds of objects can be represented by descriptors: files, pipes, and sockets. +Descriptors represent underlying objects supported by the kernel, and are created by system calls specific to the type of object. +In 4.4BSD, three kinds of objects can be represented by descriptors: files, pipes, and sockets. * A _file_ is a linear array of bytes with at least one name. A file exists until all its names are deleted explicitly and no process holds a descriptor for it. A process acquires a descriptor for a file by opening that file's name with the _open_ system call. I/O devices are accessed as files. * A _pipe_ is a linear array of bytes, as is a file, but it is used solely as an I/O stream, and it is unidirectional. It also has no name, and thus cannot be opened with _open_. Instead, it is created by the _pipe_ system call, which returns two descriptors, one of which accepts input that is sent to the other descriptor reliably, without duplication, and in order. The system also supports a named pipe or FIFO. A FIFO has properties identical to a pipe, except that it appears in the filesystem; thus, it can be opened using the _open_ system call. Two processes that wish to communicate each open the FIFO: One opens it for reading, the other for writing. @@ -274,106 +431,220 @@ Descriptors represent underlying objects supported by the kernel, and are create In systems before 4.2BSD, pipes were implemented using the filesystem; when sockets were introduced in 4.2BSD, pipes were reimplemented as sockets. -The kernel keeps for each process a _descriptor table_, which is a table that the kernel uses to translate the external representation of a descriptor into an internal representation. (The descriptor is merely an index into this table.) The descriptor table of a process is inherited from that process's parent, and thus access to the objects to which the descriptors refer also is inherited. The main ways that a process can obtain a descriptor are by opening or creation of an object, and by inheritance from the parent process. In addition, socket IPC allows passing of descriptors in messages between unrelated processes on the same machine. +The kernel keeps for each process a _descriptor table_, which is a table that the kernel uses to translate the external representation of a descriptor into an internal representation. +(The descriptor is merely an index into this table.) +The descriptor table of a process is inherited from that process's parent, and thus access to the objects to which the descriptors refer also is inherited. +The main ways that a process can obtain a descriptor are by opening or creation of an object, and by inheritance from the parent process. +In addition, socket IPC allows passing of descriptors in messages between unrelated processes on the same machine. -Every valid descriptor has an associated _file offset_ in bytes from the beginning of the object. Read and write operations start at this offset, which is updated after each data transfer. For objects that permit random access, the file offset also may be set with the _lseek_ system call. Ordinary files permit random access, and some devices do, as well. Pipes and sockets do not. +Every valid descriptor has an associated _file offset_ in bytes from the beginning of the object. +Read and write operations start at this offset, which is updated after each data transfer. +For objects that permit random access, the file offset also may be set with the _lseek_ system call. +Ordinary files permit random access, and some devices do, as well. +Pipes and sockets do not. -When a process terminates, the kernel reclaims all the descriptors that were in use by that process. If the process was holding the final reference to an object, the object's manager is notified so that it can do any necessary cleanup actions, such as final deletion of a file or deallocation of a socket. +When a process terminates, the kernel reclaims all the descriptors that were in use by that process. +If the process was holding the final reference to an object, the object's manager is notified so that it can do any necessary cleanup actions, such as final deletion of a file or deallocation of a socket. ==== Descriptor Management -Most processes expect three descriptors to be open already when they start running. These descriptors are 0, 1, 2, more commonly known as _standard input_, _standard output_, and _standard error_, respectively. Usually, all three are associated with the user's terminal by the login process (see Section 14.6) and are inherited through _fork_ and _exec_ by processes run by the user. Thus, a program can read what the user types by reading standard input, and the program can send output to the user's screen by writing to standard output. The standard error descriptor also is open for writing and is used for error output, whereas standard output is used for ordinary output. - -These (and other) descriptors can be mapped to objects other than the terminal; such mapping is called _I/O redirection_, and all the standard shells permit users to do it. The shell can direct the output of a program to a file by closing descriptor 1 (standard output) and opening the desired output file to produce a new descriptor 1. It can similarly redirect standard input to come from a file by closing descriptor 0 and opening the file. - -Pipes allow the output of one program to be input to another program without rewriting or even relinking of either program. Instead of descriptor 1 (standard output) of the source program being set up to write to the terminal, it is set up to be the input descriptor of a pipe. Similarly, descriptor 0 (standard input) of the sink program is set up to reference the output of the pipe, instead of the terminal keyboard. The resulting set of two processes and the connecting pipe is known as a _pipeline_. Pipelines can be arbitrarily long series of processes connected by pipes. - -The _open_, _pipe_, and _socket_ system calls produce new descriptors with the lowest unused number usable for a descriptor. For pipelines to work, some mechanism must be provided to map such descriptors into 0 and 1. The _dup_ system call creates a copy of a descriptor that points to the same file-table entry. The new descriptor is also the lowest unused one, but if the desired descriptor is closed first, _dup_ can be used to do the desired mapping. Care is required, however: If descriptor 1 is desired, and descriptor 0 happens also to have been closed, descriptor 0 will be the result. To avoid this problem, the system provides the _dup2_ system call; it is like _dup_, but it takes an additional argument specifying the number of the desired descriptor (if the desired descriptor was already open, _dup2_ closes it before reusing it). +Most processes expect three descriptors to be open already when they start running. +These descriptors are 0, 1, 2, more commonly known as _standard input_, _standard output_, and _standard error_, respectively. +Usually, all three are associated with the user's terminal by the login process (see Section 14.6) and are inherited through _fork_ and _exec_ by processes run by the user. +Thus, a program can read what the user types by reading standard input, and the program can send output to the user's screen by writing to standard output. +The standard error descriptor also is open for writing and is used for error output, whereas standard output is used for ordinary output. + +These (and other) descriptors can be mapped to objects other than the terminal; such mapping is called _I/O redirection_, and all the standard shells permit users to do it. +The shell can direct the output of a program to a file by closing descriptor 1 (standard output) and opening the desired output file to produce a new descriptor 1. +It can similarly redirect standard input to come from a file by closing descriptor 0 and opening the file. + +Pipes allow the output of one program to be input to another program without rewriting or even relinking of either program. +Instead of descriptor 1 (standard output) of the source program being set up to write to the terminal, it is set up to be the input descriptor of a pipe. +Similarly, descriptor 0 (standard input) of the sink program is set up to reference the output of the pipe, instead of the terminal keyboard. +The resulting set of two processes and the connecting pipe is known as a _pipeline_. +Pipelines can be arbitrarily long series of processes connected by pipes. + +The _open_, _pipe_, and _socket_ system calls produce new descriptors with the lowest unused number usable for a descriptor. +For pipelines to work, some mechanism must be provided to map such descriptors into 0 and 1. +The _dup_ system call creates a copy of a descriptor that points to the same file-table entry. +The new descriptor is also the lowest unused one, but if the desired descriptor is closed first, _dup_ can be used to do the desired mapping. +Care is required, however: If descriptor 1 is desired, and descriptor 0 happens also to have been closed, descriptor 0 will be the result. +To avoid this problem, the system provides the _dup2_ system call; it is like _dup_, but it takes an additional argument specifying the number of the desired descriptor (if the desired descriptor was already open, _dup2_ closes it before reusing it). ==== Devices -Hardware devices have filenames, and may be accessed by the user via the same system calls used for regular files. The kernel can distinguish a _device special file_ or _special file_, and can determine to what device it refers, but most processes do not need to make this determination. Terminals, printers, and tape drives are all accessed as though they were streams of bytes, like 4.4BSD disk files. Thus, device dependencies and peculiarities are kept in the kernel as much as possible, and even in the kernel most of them are segregated in the device drivers. +Hardware devices have filenames, and may be accessed by the user via the same system calls used for regular files. +The kernel can distinguish a _device special file_ or _special file_, and can determine to what device it refers, but most processes do not need to make this determination. +Terminals, printers, and tape drives are all accessed as though they were streams of bytes, like 4.4BSD disk files. +Thus, device dependencies and peculiarities are kept in the kernel as much as possible, and even in the kernel most of them are segregated in the device drivers. -Hardware devices can be categorized as either _structured_ or _unstructured_; they are known as _block_ or _character_ devices, respectively. Processes typically access devices through _special files_ in the filesystem. I/O operations to these files are handled by kernel-resident software modules termed _device drivers_. Most network-communication hardware devices are accessible through only the interprocess-communication facilities, and do not have special files in the filesystem name space, because the _raw-socket_ interface provides a more natural interface than does a special file. +Hardware devices can be categorized as either _structured_ or _unstructured_; they are known as _block_ or _character_ devices, respectively. +Processes typically access devices through _special files_ in the filesystem. +I/O operations to these files are handled by kernel-resident software modules termed _device drivers_. +Most network-communication hardware devices are accessible through only the interprocess-communication facilities, and do not have special files in the filesystem name space, because the _raw-socket_ interface provides a more natural interface than does a special file. -Structured or block devices are typified by disks and magnetic tapes, and include most random-access devices. The kernel supports read-modify-write-type buffering actions on block-oriented structured devices to allow the latter to be read and written in a totally random byte-addressed fashion, like regular files. Filesystems are created on block devices. +Structured or block devices are typified by disks and magnetic tapes, and include most random-access devices. +The kernel supports read-modify-write-type buffering actions on block-oriented structured devices to allow the latter to be read and written in a totally random byte-addressed fashion, like regular files. +Filesystems are created on block devices. -Unstructured devices are those devices that do not support a block structure. Familiar unstructured devices are communication lines, raster plotters, and unbuffered magnetic tapes and disks. Unstructured devices typically support large block I/O transfers. +Unstructured devices are those devices that do not support a block structure. +Familiar unstructured devices are communication lines, raster plotters, and unbuffered magnetic tapes and disks. +Unstructured devices typically support large block I/O transfers. -Unstructured files are called _character devices_ because the first of these to be implemented were terminal device drivers. The kernel interface to the driver for these devices proved convenient for other devices that were not block structured. +Unstructured files are called _character devices_ because the first of these to be implemented were terminal device drivers. +The kernel interface to the driver for these devices proved convenient for other devices that were not block structured. -Device special files are created by the _mknod_ system call. There is an additional system call, _ioctl_, for manipulating the underlying device parameters of special files. The operations that can be done differ for each device. This system call allows the special characteristics of devices to be accessed, rather than overloading the semantics of other system calls. For example, there is an _ioctl_ on a tape drive to write an end-of-tape mark, instead of there being a special or modified version of _write_. +Device special files are created by the _mknod_ system call. +There is an additional system call, _ioctl_, for manipulating the underlying device parameters of special files. +The operations that can be done differ for each device. +This system call allows the special characteristics of devices to be accessed, rather than overloading the semantics of other system calls. +For example, there is an _ioctl_ on a tape drive to write an end-of-tape mark, instead of there being a special or modified version of _write_. ==== Socket IPC -The 4.2BSD kernel introduced an IPC mechanism more flexible than pipes, based on _sockets_. A socket is an endpoint of communication referred to by a descriptor, just like a file or a pipe. Two processes can each create a socket, and then connect those two endpoints to produce a reliable byte stream. Once connected, the descriptors for the sockets can be read or written by processes, just as the latter would do with a pipe. The transparency of sockets allows the kernel to redirect the output of one process to the input of another process residing on another machine. A major difference between pipes and sockets is that pipes require a common parent process to set up the communications channel. A connection between sockets can be set up by two unrelated processes, possibly residing on different machines. - -System V provides local interprocess communication through FIFOs (also known as _named pipes_). FIFOs appear as an object in the filesystem that unrelated processes can open and send data through in the same way as they would communicate through a pipe. Thus, FIFOs do not require a common parent to set them up; they can be connected after a pair of processes are up and running. Unlike sockets, FIFOs can be used on only a local machine; they cannot be used to communicate between processes on different machines. FIFOs are implemented in 4.4BSD only because they are required by the POSIX.1 standard. Their functionality is a subset of the socket interface. - -The socket mechanism requires extensions to the traditional UNIX I/O system calls to provide the associated naming and connection semantics. Rather than overloading the existing interface, the developers used the existing interfaces to the extent that the latter worked without being changed, and designed new interfaces to handle the added semantics. The _read_ and _write_ system calls were used for byte-stream type connections, but six new system calls were added to allow sending and receiving addressed messages such as network datagrams. The system calls for writing messages include _send_, _sendto_, and _sendmsg_. The system calls for reading messages include _recv_, _recvfrom_, and _recvmsg_. In retrospect, the first two in each class are special cases of the others; _recvfrom_ and _sendto_ probably should have been added as library interfaces to _recvmsg_ and _sendmsg_, respectively. +The 4.2BSD kernel introduced an IPC mechanism more flexible than pipes, based on _sockets_. +A socket is an endpoint of communication referred to by a descriptor, just like a file or a pipe. +Two processes can each create a socket, and then connect those two endpoints to produce a reliable byte stream. +Once connected, the descriptors for the sockets can be read or written by processes, just as the latter would do with a pipe. +The transparency of sockets allows the kernel to redirect the output of one process to the input of another process residing on another machine. +A major difference between pipes and sockets is that pipes require a common parent process to set up the communications channel. +A connection between sockets can be set up by two unrelated processes, possibly residing on different machines. + +System V provides local interprocess communication through FIFOs (also known as _named pipes_). +FIFOs appear as an object in the filesystem that unrelated processes can open and send data through in the same way as they would communicate through a pipe. +Thus, FIFOs do not require a common parent to set them up; they can be connected after a pair of processes are up and running. +Unlike sockets, FIFOs can be used on only a local machine; they cannot be used to communicate between processes on different machines. +FIFOs are implemented in 4.4BSD only because they are required by the POSIX.1 standard. +Their functionality is a subset of the socket interface. + +The socket mechanism requires extensions to the traditional UNIX I/O system calls to provide the associated naming and connection semantics. +Rather than overloading the existing interface, the developers used the existing interfaces to the extent that the latter worked without being changed, and designed new interfaces to handle the added semantics. +The _read_ and _write_ system calls were used for byte-stream type connections, but six new system calls were added to allow sending and receiving addressed messages such as network datagrams. +The system calls for writing messages include _send_, _sendto_, and _sendmsg_. +The system calls for reading messages include _recv_, _recvfrom_, and _recvmsg_. +In retrospect, the first two in each class are special cases of the others; _recvfrom_ and _sendto_ probably should have been added as library interfaces to _recvmsg_ and _sendmsg_, respectively. ==== Scatter/Gather I/O -In addition to the traditional _read_ and _write_ system calls, 4.2BSD introduced the ability to do scatter/gather I/O. Scatter input uses the _readv_ system call to allow a single read to be placed in several different buffers. Conversely, the _writev_ system call allows several different buffers to be written in a single atomic write. Instead of passing a single buffer and length parameter, as is done with _read_ and _write_, the process passes in a pointer to an array of buffers and lengths, along with a count describing the size of the array. +In addition to the traditional _read_ and _write_ system calls, 4.2BSD introduced the ability to do scatter/gather I/O. +Scatter input uses the _readv_ system call to allow a single read to be placed in several different buffers. +Conversely, the _writev_ system call allows several different buffers to be written in a single atomic write. +Instead of passing a single buffer and length parameter, as is done with _read_ and _write_, the process passes in a pointer to an array of buffers and lengths, along with a count describing the size of the array. -This facility allows buffers in different parts of a process address space to be written atomically, without the need to copy them to a single contiguous buffer. Atomic writes are necessary in the case where the underlying abstraction is record based, such as tape drives that output a tape block on each write request. It is also convenient to be able to read a single request into several different buffers (such as a record header into one place and the data into another). Although an application can simulate the ability to scatter data by reading the data into a large buffer and then copying the pieces to their intended destinations, the cost of memory-to-memory copying in such cases often would more than double the running time of the affected application. +This facility allows buffers in different parts of a process address space to be written atomically, without the need to copy them to a single contiguous buffer. +Atomic writes are necessary in the case where the underlying abstraction is record based, such as tape drives that output a tape block on each write request. +It is also convenient to be able to read a single request into several different buffers (such as a record header into one place and the data into another). +Although an application can simulate the ability to scatter data by reading the data into a large buffer and then copying the pieces to their intended destinations, the cost of memory-to-memory copying in such cases often would more than double the running time of the affected application. -Just as _send_ and _recv_ could have been implemented as library interfaces to _sendto_ and _recvfrom_, it also would have been possible to simulate _read_ with _readv_ and _write_ with _writev_. However, _read_ and _write_ are used so much more frequently that the added cost of simulating them would not have been worthwhile. +Just as _send_ and _recv_ could have been implemented as library interfaces to _sendto_ and _recvfrom_, it also would have been possible to simulate _read_ with _readv_ and _write_ with _writev_. +However, _read_ and _write_ are used so much more frequently that the added cost of simulating them would not have been worthwhile. ==== Multiple Filesystem Support -With the expansion of network computing, it became desirable to support both local and remote filesystems. To simplify the support of multiple filesystems, the developers added a new virtual node or _vnode_ interface to the kernel. The set of operations exported from the vnode interface appear much like the filesystem operations previously supported by the local filesystem. However, they may be supported by a wide range of filesystem types: +With the expansion of network computing, it became desirable to support both local and remote filesystems. +To simplify the support of multiple filesystems, the developers added a new virtual node or _vnode_ interface to the kernel. +The set of operations exported from the vnode interface appear much like the filesystem operations previously supported by the local filesystem. +However, they may be supported by a wide range of filesystem types: * Local disk-based filesystems * Files imported using a variety of remote filesystem protocols * Read-only CD-ROM filesystems * Filesystems providing special-purpose interfaces -- for example, the `/proc` filesystem -A few variants of 4.4BSD, such as FreeBSD, allow filesystems to be loaded dynamically when the filesystems are first referenced by the _mount_ system call. The vnode interface is described in Section 6.5; its ancillary support routines are described in Section 6.6; several of the special-purpose filesystems are described in Section 6.7. +A few variants of 4.4BSD, such as FreeBSD, allow filesystems to be loaded dynamically when the filesystems are first referenced by the _mount_ system call. +The vnode interface is described in Section 6.5; its ancillary support routines are described in Section 6.6; several of the special-purpose filesystems are described in Section 6.7. [[overview-filesystem]] === Filesystems -A regular file is a linear array of bytes, and can be read and written starting at any byte in the file. The kernel distinguishes no record boundaries in regular files, although many programs recognize line-feed characters as distinguishing the ends of lines, and other programs may impose other structure. No system-related information about a file is kept in the file itself, but the filesystem stores a small amount of ownership, protection, and usage information with each file. +A regular file is a linear array of bytes, and can be read and written starting at any byte in the file. +The kernel distinguishes no record boundaries in regular files, although many programs recognize line-feed characters as distinguishing the ends of lines, and other programs may impose other structure. +No system-related information about a file is kept in the file itself, but the filesystem stores a small amount of ownership, protection, and usage information with each file. -A _filename_ component is a string of up to 255 characters. These filenames are stored in a type of file called a _directory_. The information in a directory about a file is called a _directory entry_ and includes, in addition to the filename, a pointer to the file itself. Directory entries may refer to other directories, as well as to plain files. A hierarchy of directories and files is thus formed, and is called a _filesystem_; +A _filename_ component is a string of up to 255 characters. These filenames are stored in a type of file called a _directory_. +The information in a directory about a file is called a _directory entry_ and includes, in addition to the filename, a pointer to the file itself. +Directory entries may refer to other directories, as well as to plain files. +A hierarchy of directories and files is thus formed, and is called a _filesystem_; .A small filesystem [[fig-small-fs]] image:fig2.png[A small filesystem] -a small one is shown in <>. Directories may contain subdirectories, and there is no inherent limitation to the depth with which directory nesting may occur. To protect the consistency of the filesystem, the kernel does not permit processes to write directly into directories. A filesystem may include not only plain files and directories, but also references to other objects, such as devices and sockets. +a small one is shown in <>. +Directories may contain subdirectories, and there is no inherent limitation to the depth with which directory nesting may occur. +To protect the consistency of the filesystem, the kernel does not permit processes to write directly into directories. +A filesystem may include not only plain files and directories, but also references to other objects, such as devices and sockets. -The filesystem forms a tree, the beginning of which is the _root directory_, sometimes referred to by the name _slash_, spelled with a single solidus character (/). The root directory contains files; in our example in Fig 2.2, it contains `vmunix`, a copy of the kernel-executable object file. It also contains directories; in this example, it contains the `usr` directory. Within the `usr` directory is the `bin` directory, which mostly contains executable object code of programs, such as the files `ls` and `vi`. +The filesystem forms a tree, the beginning of which is the _root directory_, sometimes referred to by the name _slash_, spelled with a single solidus character (/). +The root directory contains files; in our example in Fig 2.2, it contains `vmunix`, a copy of the kernel-executable object file. +It also contains directories; in this example, it contains the `usr` directory. +Within the `usr` directory is the `bin` directory, which mostly contains executable object code of programs, such as the files `ls` and `vi`. -A process identifies a file by specifying that file's _pathname_, which is a string composed of zero or more filenames separated by slash (/) characters. The kernel associates two directories with each process for use in interpreting pathnames. A process's _root directory_ is the topmost point in the filesystem that the process can access; it is ordinarily set to the root directory of the entire filesystem. A pathname beginning with a slash is called an _absolute pathname_, and is interpreted by the kernel starting with the process's root directory. +A process identifies a file by specifying that file's _pathname_, which is a string composed of zero or more filenames separated by slash (/) characters. +The kernel associates two directories with each process for use in interpreting pathnames. +A process's _root directory_ is the topmost point in the filesystem that the process can access; it is ordinarily set to the root directory of the entire filesystem. +A pathname beginning with a slash is called an _absolute pathname_, and is interpreted by the kernel starting with the process's root directory. -A pathname that does not begin with a slash is called a _relative pathname_, and is interpreted relative to the _current working directory_ of the process. (This directory also is known by the shorter names _current directory_ or _working directory_.) The current directory itself may be referred to directly by the name _dot_, spelled with a single period (`.`). The filename _dot-dot_ (`..`) refers to a directory's parent directory. The root directory is its own parent. +A pathname that does not begin with a slash is called a _relative pathname_, and is interpreted relative to the _current working directory_ of the process. +(This directory also is known by the shorter names _current directory_ or _working directory_.) +The current directory itself may be referred to directly by the name _dot_, spelled with a single period (`.`) +The filename _dot-dot_ (`..`) refers to a directory's parent directory. +The root directory is its own parent. -A process may set its root directory with the _chroot_ system call, and its current directory with the _chdir_ system call. Any process may do _chdir_ at any time, but _chroot_ is permitted only a process with superuser privileges. _Chroot_ is normally used to set up restricted access to the system. +A process may set its root directory with the _chroot_ system call, and its current directory with the _chdir_ system call. +Any process may do _chdir_ at any time, but _chroot_ is permitted only a process with superuser privileges. +_Chroot_ is normally used to set up restricted access to the system. Using the filesystem shown in Fig. 2.2, if a process has the root of the filesystem as its root directory, and has `/usr` as its current directory, it can refer to the file `vi` either from the root with the absolute pathname `/usr/bin/vi`, or from its current directory with the relative pathname `bin/vi`. -System utilities and databases are kept in certain well-known directories. Part of the well-defined hierarchy includes a directory that contains the _home directory_ for each user -- for example, `/usr/staff/mckusick` and `/usr/staff/karels` in Fig. 2.2. When users log in, the current working directory of their shell is set to the home directory. Within their home directories, users can create directories as easily as they can regular files. Thus, a user can build arbitrarily complex subhierarchies. - -The user usually knows of only one filesystem, but the system may know that this one virtual filesystem is really composed of several physical filesystems, each on a different device. A physical filesystem may not span multiple hardware devices. Since most physical disk devices are divided into several logical devices, there may be more than one filesystem per physical device, but there will be no more than one per logical device. One filesystem -- the filesystem that anchors all absolute pathnames -- is called the _root filesystem_, and is always available. Others may be mounted; that is, they may be integrated into the directory hierarchy of the root filesystem. References to a directory that has a filesystem mounted on it are converted transparently by the kernel into references to the root directory of the mounted filesystem. - -The _link_ system call takes the name of an existing file and another name to create for that file. After a successful _link_, the file can be accessed by either filename. A filename can be removed with the _unlink_ system call. When the final name for a file is removed (and the final process that has the file open closes it), the file is deleted. - -Files are organized hierarchically in _directories_. A directory is a type of file, but, in contrast to regular files, a directory has a structure imposed on it by the system. A process can read a directory as it would an ordinary file, but only the kernel is permitted to modify a directory. Directories are created by the _mkdir_ system call and are removed by the _rmdir_ system call. Before 4.2BSD, the _mkdir_ and _rmdir_ system calls were implemented by a series of _link_ and _unlink_ system calls being done. There were three reasons for adding systems calls explicitly to create and delete directories: +System utilities and databases are kept in certain well-known directories. +Part of the well-defined hierarchy includes a directory that contains the _home directory_ for each user -- for example, `/usr/staff/mckusick` and `/usr/staff/karels` in Fig. 2.2. +When users log in, the current working directory of their shell is set to the home directory. +Within their home directories, users can create directories as easily as they can regular files. +Thus, a user can build arbitrarily complex subhierarchies. + +The user usually knows of only one filesystem, but the system may know that this one virtual filesystem is really composed of several physical filesystems, each on a different device. +A physical filesystem may not span multiple hardware devices. +Since most physical disk devices are divided into several logical devices, there may be more than one filesystem per physical device, but there will be no more than one per logical device. +One filesystem -- the filesystem that anchors all absolute pathnames -- is called the _root filesystem_, and is always available. +Others may be mounted; that is, they may be integrated into the directory hierarchy of the root filesystem. +References to a directory that has a filesystem mounted on it are converted transparently by the kernel into references to the root directory of the mounted filesystem. + +The _link_ system call takes the name of an existing file and another name to create for that file. +After a successful _link_, the file can be accessed by either filename. +A filename can be removed with the _unlink_ system call. +When the final name for a file is removed (and the final process that has the file open closes it), the file is deleted. + +Files are organized hierarchically in _directories_. +A directory is a type of file, but, in contrast to regular files, a directory has a structure imposed on it by the system. +A process can read a directory as it would an ordinary file, but only the kernel is permitted to modify a directory. +Directories are created by the _mkdir_ system call and are removed by the _rmdir_ system call. +Before 4.2BSD, the _mkdir_ and _rmdir_ system calls were implemented by a series of _link_ and _unlink_ system calls being done. +There were three reasons for adding systems calls explicitly to create and delete directories: [arabic] . The operation could be made atomic. If the system crashed, the directory would not be left half-constructed, as could happen when a series of link operations were used. . When a networked filesystem is being run, the creation and deletion of files and directories need to be specified atomically so that they can be serialized. . When supporting non-UNIX filesystems, such as an MS-DOS filesystem, on another partition of the disk, the other filesystem may not support link operations. Although other filesystems might support the concept of directories, they probably would not create and delete the directories with links, as the UNIX filesystem does. Consequently, they could create and delete directories only if explicit directory create and delete requests were presented. -The _chown_ system call sets the owner and group of a file, and _chmod_ changes protection attributes. _Stat_ applied to a filename can be used to read back such properties of a file. The _fchown_, _fchmod_, and _fstat_ system calls are applied to a descriptor, instead of to a filename, to do the same set of operations. The _rename_ system call can be used to give a file a new name in the filesystem, replacing one of the file's old names. Like the directory-creation and directory-deletion operations, the _rename_ system call was added to 4.2BSD to provide atomicity to name changes in the local filesystem. Later, it proved useful explicitly to export renaming operations to foreign filesystems and over the network. +The _chown_ system call sets the owner and group of a file, and _chmod_ changes protection attributes. +_Stat_ applied to a filename can be used to read back such properties of a file. +The _fchown_, _fchmod_, and _fstat_ system calls are applied to a descriptor, instead of to a filename, to do the same set of operations. +The _rename_ system call can be used to give a file a new name in the filesystem, replacing one of the file's old names. +Like the directory-creation and directory-deletion operations, the _rename_ system call was added to 4.2BSD to provide atomicity to name changes in the local filesystem. +Later, it proved useful explicitly to export renaming operations to foreign filesystems and over the network. -The _truncate_ system call was added to 4.2BSD to allow files to be shortened to an arbitrary offset. The call was added primarily in support of the Fortran run-time library, which has the semantics such that the end of a random-access file is set to be wherever the program most recently accessed that file. Without the _truncate_ system call, the only way to shorten a file was to copy the part that was desired to a new file, to delete the old file, then to rename the copy to the original name. As well as this algorithm being slow, the library could potentially fail on a full filesystem. +The _truncate_ system call was added to 4.2BSD to allow files to be shortened to an arbitrary offset. +The call was added primarily in support of the Fortran run-time library, which has the semantics such that the end of a random-access file is set to be wherever the program most recently accessed that file. +Without the _truncate_ system call, the only way to shorten a file was to copy the part that was desired to a new file, to delete the old file, then to rename the copy to the original name. +As well as this algorithm being slow, the library could potentially fail on a full filesystem. -Once the filesystem had the ability to shorten files, the kernel took advantage of that ability to shorten large empty directories. The advantage of shortening empty directories is that it reduces the time spent in the kernel searching them when names are being created or deleted. +Once the filesystem had the ability to shorten files, the kernel took advantage of that ability to shorten large empty directories. +The advantage of shortening empty directories is that it reduces the time spent in the kernel searching them when names are being created or deleted. -Newly created files are assigned the user identifier of the process that created them and the group identifier of the directory in which they were created. A three-level access-control mechanism is provided for the protection of files. These three levels specify the accessibility of a file to +Newly created files are assigned the user identifier of the process that created them and the group identifier of the directory in which they were created. +A three-level access-control mechanism is provided for the protection of files. +These three levels specify the accessibility of a file to [arabic] . The user who owns the file @@ -382,18 +653,36 @@ Newly created files are assigned the user identifier of the process that created Each level of access has separate indicators for read permission, write permission, and execute permission. -Files are created with zero length, and may grow when they are written. While a file is open, the system maintains a pointer into the file indicating the current location in the file associated with the descriptor. This pointer can be moved about in the file in a random-access fashion. Processes sharing a file descriptor through a _fork_ or _dup_ system call share the current location pointer. Descriptors created by separate _open_ system calls have separate current location pointers. Files may have _holes_ in them. Holes are void areas in the linear extent of the file where data have never been written. A process can create these holes by positioning the pointer past the current end-of-file and writing. When read, holes are treated by the system as zero-valued bytes. - -Earlier UNIX systems had a limit of 14 characters per filename component. This limitation was often a problem. For example, in addition to the natural desire of users to give files long descriptive names, a common way of forming filenames is as `basename.extension`, where the extension (indicating the kind of file, such as `.c` for C source or `.o` for intermediate binary object) is one to three characters, leaving 10 to 12 characters for the basename. Source-code-control systems and editors usually take up another two characters, either as a prefix or a suffix, for their purposes, leaving eight to 10 characters. It is easy to use 10 or 12 characters in a single English word as a basename (e.g., ``multiplexer''). - -It is possible to keep within these limits, but it is inconvenient or even dangerous, because other UNIX systems accept strings longer than the limit when creating files, but then _truncate_ to the limit. A C language source file named `multiplexer.c` (already 13 characters) might have a source-code-control file with `s.` prepended, producing a filename `s.multiplexer` that is indistinguishable from the source-code-control file for `multiplexer.ms`, a file containing `troff` source for documentation for the C program. The contents of the two original files could easily get confused with no warning from the source-code-control system. Careful coding can detect this problem, but the long filenames first introduced in 4.2BSD practically eliminate it. +Files are created with zero length, and may grow when they are written. +While a file is open, the system maintains a pointer into the file indicating the current location in the file associated with the descriptor. +This pointer can be moved about in the file in a random-access fashion. +Processes sharing a file descriptor through a _fork_ or _dup_ system call share the current location pointer. +Descriptors created by separate _open_ system calls have separate current location pointers. +Files may have _holes_ in them. +Holes are void areas in the linear extent of the file where data have never been written. +A process can create these holes by positioning the pointer past the current end-of-file and writing. +When read, holes are treated by the system as zero-valued bytes. + +Earlier UNIX systems had a limit of 14 characters per filename component. +This limitation was often a problem. +For example, in addition to the natural desire of users to give files long descriptive names, a common way of forming filenames is as `basename.extension`, where the extension (indicating the kind of file, such as `.c` for C source or `.o` for intermediate binary object) is one to three characters, leaving 10 to 12 characters for the basename. +Source-code-control systems and editors usually take up another two characters, either as a prefix or a suffix, for their purposes, leaving eight to 10 characters. +It is easy to use 10 or 12 characters in a single English word as a basename (e.g., `multiplexer`). + +It is possible to keep within these limits, but it is inconvenient or even dangerous, because other UNIX systems accept strings longer than the limit when creating files, but then _truncate_ to the limit. +A C language source file named `multiplexer.c` (already 13 characters) might have a source-code-control file with `s.` prepended, producing a filename `s.multiplexer` that is indistinguishable from the source-code-control file for `multiplexer.ms`, a file containing `troff` source for documentation for the C program. +The contents of the two original files could easily get confused with no warning from the source-code-control system. +Careful coding can detect this problem, but the long filenames first introduced in 4.2BSD practically eliminate it. [[overview-filestore]] === Filestores -The operations defined for local filesystems are divided into two parts. Common to all local filesystems are hierarchical naming, locking, quotas, attribute management, and protection. These features are independent of how the data will be stored. 4.4BSD has a single implementation to provide these semantics. +The operations defined for local filesystems are divided into two parts. +Common to all local filesystems are hierarchical naming, locking, quotas, attribute management, and protection. +These features are independent of how the data will be stored. 4.4BSD has a single implementation to provide these semantics. -The other part of the local filesystem is the organization and management of the data on the storage media. Laying out the contents of files on the storage media is the responsibility of the filestore. 4.4BSD supports three different filestore layouts: +The other part of the local filesystem is the organization and management of the data on the storage media. +Laying out the contents of files on the storage media is the responsibility of the filestore. 4.4BSD supports three different filestore layouts: * The traditional Berkeley Fast Filesystem * The log-structured filesystem, based on the Sprite operating-system design <> @@ -401,82 +690,151 @@ The other part of the local filesystem is the organization and management of the Although the organizations of these filestores are completely different, these differences are indistinguishable to the processes using the filestores. -The Fast Filesystem organizes data into cylinder groups. Files that are likely to be accessed together, based on their locations in the filesystem hierarchy, are stored in the same cylinder group. Files that are not expected to accessed together are moved into different cylinder groups. Thus, files written at the same time may be placed far apart on the disk. +The Fast Filesystem organizes data into cylinder groups. +Files that are likely to be accessed together, based on their locations in the filesystem hierarchy, are stored in the same cylinder group. +Files that are not expected to accessed together are moved into different cylinder groups. +Thus, files written at the same time may be placed far apart on the disk. -The log-structured filesystem organizes data as a log. All data being written at any point in time are gathered together, and are written at the same disk location. Data are never overwritten; instead, a new copy of the file is written that replaces the old one. The old files are reclaimed by a garbage-collection process that runs when the filesystem becomes full and additional free space is needed. +The log-structured filesystem organizes data as a log. +All data being written at any point in time are gathered together, and are written at the same disk location. +Data are never overwritten; instead, a new copy of the file is written that replaces the old one. +The old files are reclaimed by a garbage-collection process that runs when the filesystem becomes full and additional free space is needed. -The memory-based filesystem is designed to store data in virtual memory. It is used for filesystems that need to support fast but temporary data, such as `/tmp`. The goal of the memory-based filesystem is to keep the storage packed as compactly as possible to minimize the usage of virtual-memory resources. +The memory-based filesystem is designed to store data in virtual memory. +It is used for filesystems that need to support fast but temporary data, such as `/tmp`. +The goal of the memory-based filesystem is to keep the storage packed as compactly as possible to minimize the usage of virtual-memory resources. [[overview-nfs]] === Network Filesystem -Initially, networking was used to transfer data from one machine to another. Later, it evolved to allowing users to log in remotely to another machine. The next logical step was to bring the data to the user, instead of having the user go to the data -- and network filesystems were born. Users working locally do not experience the network delays on each keystroke, so they have a more responsive environment. +Initially, networking was used to transfer data from one machine to another. +Later, it evolved to allowing users to log in remotely to another machine. +The next logical step was to bring the data to the user, instead of having the user go to the data -- and network filesystems were born. +Users working locally do not experience the network delays on each keystroke, so they have a more responsive environment. -Bringing the filesystem to a local machine was among the first of the major client-server applications. The _server_ is the remote machine that exports one or more of its filesystems. The _client_ is the local machine that imports those filesystems. From the local client's point of view, a remotely mounted filesystem appears in the file-tree name space just like any other locally mounted filesystem. Local clients can change into directories on the remote filesystem, and can read, write, and execute binaries within that remote filesystem identically to the way that they can do these operations on a local filesystem. +Bringing the filesystem to a local machine was among the first of the major client-server applications. +The _server_ is the remote machine that exports one or more of its filesystems. +The _client_ is the local machine that imports those filesystems. +From the local client's point of view, a remotely mounted filesystem appears in the file-tree name space just like any other locally mounted filesystem. +Local clients can change into directories on the remote filesystem, and can read, write, and execute binaries within that remote filesystem identically to the way that they can do these operations on a local filesystem. -When the local client does an operation on a remote filesystem, the request is packaged and is sent to the server. The server does the requested operation and returns either the requested information or an error indicating why the request was denied. To get reasonable performance, the client must cache frequently accessed data. The complexity of remote filesystems lies in maintaining cache consistency between the server and its many clients. +When the local client does an operation on a remote filesystem, the request is packaged and is sent to the server. +The server does the requested operation and returns either the requested information or an error indicating why the request was denied. +To get reasonable performance, the client must cache frequently accessed data. +The complexity of remote filesystems lies in maintaining cache consistency between the server and its many clients. -Although many remote-filesystem protocols have been developed over the years, the most pervasive one in use among UNIX systems is the Network Filesystem (NFS), whose protocol and most widely used implementation were done by Sun Microsystems. The 4.4BSD kernel supports the NFS protocol, although the implementation was done independently from the protocol specification <>. The NFS protocol is described in Chapter 9. +Although many remote-filesystem protocols have been developed over the years, the most pervasive one in use among UNIX systems is the Network Filesystem (NFS), whose protocol and most widely used implementation were done by Sun Microsystems. +The 4.4BSD kernel supports the NFS protocol, although the implementation was done independently from the protocol specification <>. +The NFS protocol is described in Chapter 9. [[overview-terminal]] === Terminals -Terminals support the standard system I/O operations, as well as a collection of terminal-specific operations to control input-character editing and output delays. At the lowest level are the terminal device drivers that control the hardware terminal ports. Terminal input is handled according to the underlying communication characteristics, such as baud rate, and according to a set of software-controllable parameters, such as parity checking. +Terminals support the standard system I/O operations, as well as a collection of terminal-specific operations to control input-character editing and output delays. +At the lowest level are the terminal device drivers that control the hardware terminal ports. +Terminal input is handled according to the underlying communication characteristics, such as baud rate, and according to a set of software-controllable parameters, such as parity checking. -Layered above the terminal device drivers are line disciplines that provide various degrees of character processing. The default line discipline is selected when a port is being used for an interactive login. The line discipline is run in _canonical mode_; input is processed to provide standard line-oriented editing functions, and input is presented to a process on a line-by-line basis. +Layered above the terminal device drivers are line disciplines that provide various degrees of character processing. +The default line discipline is selected when a port is being used for an interactive login. +The line discipline is run in _canonical mode_; input is processed to provide standard line-oriented editing functions, and input is presented to a process on a line-by-line basis. -Screen editors and programs that communicate with other computers generally run in _noncanonical mode_ (also commonly referred to as _raw mode_ or _character-at-a-time mode_). In this mode, input is passed through to the reading process immediately and without interpretation. All special-character input processing is disabled, no erase or other line editing processing is done, and all characters are passed to the program that is reading from the terminal. +Screen editors and programs that communicate with other computers generally run in _noncanonical mode_ (also commonly referred to as _raw mode_ or _character-at-a-time mode_). +In this mode, input is passed through to the reading process immediately and without interpretation. +All special-character input processing is disabled, no erase or other line editing processing is done, and all characters are passed to the program that is reading from the terminal. -It is possible to configure the terminal in thousands of combinations between these two extremes. For example, a screen editor that wanted to receive user interrupts asynchronously might enable the special characters that generate signals and enable output flow control, but otherwise run in noncanonical mode; all other characters would be passed through to the process uninterpreted. +It is possible to configure the terminal in thousands of combinations between these two extremes. +For example, a screen editor that wanted to receive user interrupts asynchronously might enable the special characters that generate signals and enable output flow control, but otherwise run in noncanonical mode; all other characters would be passed through to the process uninterpreted. On output, the terminal handler provides simple formatting services, including * Converting the line-feed character to the two-character carriage-return-line-feed sequence * Inserting delays after certain standard control characters * Expanding tabs -* Displaying echoed nongraphic ASCII characters as a two-character sequence of the form ``^C'' (i.e., the ASCII caret character followed by the ASCII character that is the character's value offset from the ASCII ``@'' character). +* Displaying echoed nongraphic ASCII characters as a two-character sequence of the form `^C` (i.e., the ASCII caret character followed by the ASCII character that is the character's value offset from the ASCII `@` character). Each of these formatting services can be disabled individually by a process through control requests. [[overview-ipc]] === Interprocess Communication -Interprocess communication in 4.4BSD is organized in _communication domains_. Domains currently supported include the _local domain_, for communication between processes executing on the same machine; the _internet domain_, for communication between processes using the TCP/IP protocol suite (perhaps within the Internet); the ISO/OSI protocol family for communication between sites required to run them; and the _XNS domain_, for communication between processes using the XEROX Network Systems (XNS) protocols. +Interprocess communication in 4.4BSD is organized in _communication domains_. +Domains currently supported include the _local domain_, for communication between processes executing on the same machine; the _internet domain_, for communication between processes using the TCP/IP protocol suite (perhaps within the Internet); the ISO/OSI protocol family for communication between sites required to run them; and the _XNS domain_, for communication between processes using the XEROX Network Systems (XNS) protocols. -Within a domain, communication takes place between communication endpoints known as _sockets_. As mentioned in Section 2.6, the _socket_ system call creates a socket and returns a descriptor; other IPC system calls are described in Chapter 11. Each socket has a type that defines its communications semantics; these semantics include properties such as reliability, ordering, and prevention of duplication of messages. +Within a domain, communication takes place between communication endpoints known as _sockets_. +As mentioned in Section 2.6, the _socket_ system call creates a socket and returns a descriptor; other IPC system calls are described in Chapter 11. +Each socket has a type that defines its communications semantics; these semantics include properties such as reliability, ordering, and prevention of duplication of messages. -Each socket has associated with it a _communication protocol_. This protocol provides the semantics required by the socket according to the latter's type. Applications may request a specific protocol when creating a socket, or may allow the system to select a protocol that is appropriate for the type of socket being created. +Each socket has associated with it a _communication protocol_. +This protocol provides the semantics required by the socket according to the latter's type. +Applications may request a specific protocol when creating a socket, or may allow the system to select a protocol that is appropriate for the type of socket being created. -Sockets may have addresses bound to them. The form and meaning of socket addresses are dependent on the communication domain in which the socket is created. Binding a name to a socket in the local domain causes a file to be created in the filesystem. +Sockets may have addresses bound to them. +The form and meaning of socket addresses are dependent on the communication domain in which the socket is created. +Binding a name to a socket in the local domain causes a file to be created in the filesystem. -Normal data transmitted and received through sockets are untyped. Data-representation issues are the responsibility of libraries built on top of the interprocess-communication facilities. In addition to transporting normal data, communication domains may support the transmission and reception of specially typed data, termed _access rights_. The local domain, for example, uses this facility to pass descriptors between processes. +Normal data transmitted and received through sockets are untyped. +Data-representation issues are the responsibility of libraries built on top of the interprocess-communication facilities. +In addition to transporting normal data, communication domains may support the transmission and reception of specially typed data, termed _access rights_. +The local domain, for example, uses this facility to pass descriptors between processes. -Networking implementations on UNIX before 4.2BSD usually worked by overloading the character-device interfaces. One goal of the socket interface was for naive programs to be able to work without change on stream-style connections. Such programs can work only if the _read_ and _write_ systems calls are unchanged. Consequently, the original interfaces were left intact, and were made to work on stream-type sockets. A new interface was added for more complicated sockets, such as those used to send datagrams, with which a destination address must be presented with each _send_ call. +Networking implementations on UNIX before 4.2BSD usually worked by overloading the character-device interfaces. +One goal of the socket interface was for naive programs to be able to work without change on stream-style connections. +Such programs can work only if the _read_ and _write_ systems calls are unchanged. +Consequently, the original interfaces were left intact, and were made to work on stream-type sockets. +A new interface was added for more complicated sockets, such as those used to send datagrams, with which a destination address must be presented with each _send_ call. -Another benefit is that the new interface is highly portable. Shortly after a test release was available from Berkeley, the socket interface had been ported to System III by a UNIX vendor (although AT&T did not support the socket interface until the release of System V Release 4, deciding instead to use the Eighth Edition stream mechanism). The socket interface was also ported to run in many Ethernet boards by vendors, such as Excelan and Interlan, that were selling into the PC market, where the machines were too small to run networking in the main processor. More recently, the socket interface was used as the basis for Microsoft's Winsock networking interface for Windows. +Another benefit is that the new interface is highly portable. +Shortly after a test release was available from Berkeley, the socket interface had been ported to System III by a UNIX vendor (although AT&T did not support the socket interface until the release of System V Release 4, deciding instead to use the Eighth Edition stream mechanism). +The socket interface was also ported to run in many Ethernet boards by vendors, such as Excelan and Interlan, that were selling into the PC market, where the machines were too small to run networking in the main processor. +More recently, the socket interface was used as the basis for Microsoft's Winsock networking interface for Windows. [[overview-network-communication]] === Network Communication -Some of the communication domains supported by the _socket_ IPC mechanism provide access to network protocols. These protocols are implemented as a separate software layer logically below the socket software in the kernel. The kernel provides many ancillary services, such as buffer management, message routing, standardized interfaces to the protocols, and interfaces to the network interface drivers for the use of the various network protocols. +Some of the communication domains supported by the _socket_ IPC mechanism provide access to network protocols. +These protocols are implemented as a separate software layer logically below the socket software in the kernel. +The kernel provides many ancillary services, such as buffer management, message routing, standardized interfaces to the protocols, and interfaces to the network interface drivers for the use of the various network protocols. -At the time that 4.2BSD was being implemented, there were many networking protocols in use or under development, each with its own strengths and weaknesses. There was no clearly superior protocol or protocol suite. By supporting multiple protocols, 4.2BSD could provide interoperability and resource sharing among the diverse set of machines that was available in the Berkeley environment. Multiple-protocol support also provides for future changes. Today's protocols designed for 10- to 100-Mbit-per-second Ethernets are likely to be inadequate for tomorrow's 1- to 10-Gbit-per-second fiber-optic networks. Consequently, the network-communication layer is designed to support multiple protocols. New protocols are added to the kernel without the support for older protocols being affected. Older applications can continue to operate using the old protocol over the same physical network as is used by newer applications running with a newer network protocol. +At the time that 4.2BSD was being implemented, there were many networking protocols in use or under development, each with its own strengths and weaknesses. +There was no clearly superior protocol or protocol suite. +By supporting multiple protocols, 4.2BSD could provide interoperability and resource sharing among the diverse set of machines that was available in the Berkeley environment. +Multiple-protocol support also provides for future changes. +Today's protocols designed for 10- to 100-Mbit-per-second Ethernets are likely to be inadequate for tomorrow's 1- to 10-Gbit-per-second fiber-optic networks. +Consequently, the network-communication layer is designed to support multiple protocols. +New protocols are added to the kernel without the support for older protocols being affected. +Older applications can continue to operate using the old protocol over the same physical network as is used by newer applications running with a newer network protocol. [[overview-network-implementation]] === Network Implementation -The first protocol suite implemented in 4.2BSD was DARPA's Transmission Control Protocol/Internet Protocol (TCP/IP). The CSRG chose TCP/IP as the first network to incorporate into the socket IPC framework, because a 4.1BSD-based implementation was publicly available from a DARPA-sponsored project at Bolt, Beranek, and Newman (BBN). That was an influential choice: The 4.2BSD implementation is the main reason for the extremely widespread use of this protocol suite. Later performance and capability improvements to the TCP/IP implementation have also been widely adopted. The TCP/IP implementation is described in detail in Chapter 13. +The first protocol suite implemented in 4.2BSD was DARPA's Transmission Control Protocol/Internet Protocol (TCP/IP). +The CSRG chose TCP/IP as the first network to incorporate into the socket IPC framework, because a 4.1BSD-based implementation was publicly available from a DARPA-sponsored project at Bolt, Beranek, and Newman (BBN). +That was an influential choice: The 4.2BSD implementation is the main reason for the extremely widespread use of this protocol suite. +Later performance and capability improvements to the TCP/IP implementation have also been widely adopted. +The TCP/IP implementation is described in detail in Chapter 13. -The release of 4.3BSD added the Xerox Network Systems (XNS) protocol suite, partly building on work done at the University of Maryland and at Cornell University. This suite was needed to connect isolated machines that could not communicate using TCP/IP. +The release of 4.3BSD added the Xerox Network Systems (XNS) protocol suite, partly building on work done at the University of Maryland and at Cornell University. +This suite was needed to connect isolated machines that could not communicate using TCP/IP. -The release of 4.4BSD added the ISO protocol suite because of the latter's increasing visibility both within and outside the United States. Because of the somewhat different semantics defined for the ISO protocols, some minor changes were required in the socket interface to accommodate these semantics. The changes were made such that they were invisible to clients of other existing protocols. The ISO protocols also required extensive addition to the two-level routing tables provided by the kernel in 4.3BSD. The greatly expanded routing capabilities of 4.4BSD include arbitrary levels of routing with variable-length addresses and network masks. +The release of 4.4BSD added the ISO protocol suite because of the latter's increasing visibility both within and outside the United States. +Because of the somewhat different semantics defined for the ISO protocols, some minor changes were required in the socket interface to accommodate these semantics. +The changes were made such that they were invisible to clients of other existing protocols. +The ISO protocols also required extensive addition to the two-level routing tables provided by the kernel in 4.3BSD. +The greatly expanded routing capabilities of 4.4BSD include arbitrary levels of routing with variable-length addresses and network masks. [[overview-operation]] === System Operation -Bootstrapping mechanisms are used to start the system running. First, the 4.4BSD kernel must be loaded into the main memory of the processor. Once loaded, it must go through an initialization phase to set the hardware into a known state. Next, the kernel must do autoconfiguration, a process that finds and configures the peripherals that are attached to the processor. The system begins running in single-user mode while a start-up script does disk checks and starts the accounting and quota checking. Finally, the start-up script starts the general system services and brings up the system to full multiuser operation. +Bootstrapping mechanisms are used to start the system running. +First, the 4.4BSD kernel must be loaded into the main memory of the processor. +Once loaded, it must go through an initialization phase to set the hardware into a known state. +Next, the kernel must do autoconfiguration, a process that finds and configures the peripherals that are attached to the processor. +The system begins running in single-user mode while a start-up script does disk checks and starts the accounting and quota checking. +Finally, the start-up script starts the general system services and brings up the system to full multiuser operation. -During multiuser operation, processes wait for login requests on the terminal lines and network ports that have been configured for user access. When a login request is detected, a login process is spawned and user validation is done. When the login validation is successful, a login shell is created from which the user can run additional processes. +During multiuser operation, processes wait for login requests on the terminal lines and network ports that have been configured for user access. +When a login request is detected, a login process is spawned and user validation is done. +When the login validation is successful, a login shell is created from which the user can run additional processes. :sectnums!: From owner-dev-commits-doc-all@freebsd.org Sun May 23 22:18:49 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B5BA6650DDC for ; Sun, 23 May 2021 22:18:49 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FpF9j4ccQz3HMr; Sun, 23 May 2021 22:18:49 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 82D771EFB8; Sun, 23 May 2021 22:18:49 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 14NMInjP029059; Sun, 23 May 2021 22:18:49 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 14NMInsd029058; Sun, 23 May 2021 22:18:49 GMT (envelope-from git) Date: Sun, 23 May 2021 22:18:49 GMT Message-Id: <202105232218.14NMInsd029058@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Sergio Carlavilla Delgado Subject: git: cc1d945bed - main - Dev model style changes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: carlavilla X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: cc1d945bedba0ceaa5fe98a554e51bfa8117d226 Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 22:18:49 -0000 The branch main has been updated by carlavilla: URL: https://cgit.FreeBSD.org/doc/commit/?id=cc1d945bedba0ceaa5fe98a554e51bfa8117d226 commit cc1d945bedba0ceaa5fe98a554e51bfa8117d226 Author: Sergio Carlavilla Delgado AuthorDate: 2021-05-23 22:18:09 +0000 Commit: Sergio Carlavilla Delgado CommitDate: 2021-05-23 22:18:09 +0000 Dev model style changes Format the book with "One Sentence per Line" --- .../content/en/books/dev-model/_index.adoc | 517 ++++++++++++++++----- 1 file changed, 394 insertions(+), 123 deletions(-) diff --git a/documentation/content/en/books/dev-model/_index.adoc b/documentation/content/en/books/dev-model/_index.adoc index 8548e082b4..42373cc592 100644 --- a/documentation/content/en/books/dev-model/_index.adoc +++ b/documentation/content/en/books/dev-model/_index.adoc @@ -64,7 +64,11 @@ toc::[] [.abstract-title] Foreword -Up until now, the FreeBSD project has released a number of described techniques to do different parts of work. However, a project model summarising how the project is structured is needed because of the increasing amount of project members. footnote:[This goes hand-in-hand with Brooks' law that adding another person to a late project will make it later since it will increase the communication needs . A project model is a tool to reduce the communication needs.] This paper will provide such a project model and is donated to the FreeBSD Documentation project where it can evolve together with the project so that it can at any point in time reflect the way the project works. It is based on [<>]. +Up until now, the FreeBSD project has released a number of described techniques to do different parts of work. +However, a project model summarising how the project is structured is needed because of the increasing amount of project members. +footnote:[This goes hand-in-hand with Brooks' law that adding another person to a late project will make it later since it will increase the communication needs . A project model is a tool to reduce the communication needs.] +This paper will provide such a project model and is donated to the FreeBSD Documentation project where it can evolve together with the project so that it can at any point in time reflect the way the project works. +It is based on [<>]. I would like to thank the following people for taking the time to explain things that were unclear to me and for proofreading the document. @@ -86,15 +90,26 @@ I would like to thank the following people for taking the time to explain things [[overview]] == Overview -A project model is a means to reduce the communications overhead in a project. As shown by [<>], increasing the number of project participants increases the communication in the project exponentionally. FreeBSD has during the past few years increased both its mass of active users and committers, and the communication in the project has risen accordingly. This project model will serve to reduce this overhead by providing an up-to-date description of the project. +A project model is a means to reduce the communications overhead in a project. +As shown by [<>], increasing the number of project participants increases the communication in the project exponentionally. +FreeBSD has during the past few years increased both its mass of active users and committers, and the communication in the project has risen accordingly. +This project model will serve to reduce this overhead by providing an up-to-date description of the project. -During the Core elections in 2002, Mark Murray stated "I am opposed to a long rule-book, as that satisfies lawyer-tendencies, and is counter to the technocentricity that the project so badly needs." [<>]. This project model is not meant to be a tool to justify creating impositions for developers, but as a tool to facilitate coordination. It is meant as a description of the project, with an overview of how the different processes are executed. It is an introduction to how the FreeBSD project works. +During the Core elections in 2002, Mark Murray stated "I am opposed to a long rule-book, as that satisfies lawyer-tendencies, and is counter to the technocentricity that the project so badly needs." +[<>]. +This project model is not meant to be a tool to justify creating impositions for developers, but as a tool to facilitate coordination. +It is meant as a description of the project, with an overview of how the different processes are executed. +It is an introduction to how the FreeBSD project works. -The FreeBSD project model will be described as of July 1st, 2004. It is based on the Niels Jørgensen's paper [<>], FreeBSD's official documents, discussions on FreeBSD mailing lists and interviews with developers. +The FreeBSD project model will be described as of July 1st, 2004. +It is based on the Niels Jørgensen's paper [<>], FreeBSD's official documents, discussions on FreeBSD mailing lists and interviews with developers. -After providing definitions of terms used, this document will outline the organisational structure (including role descriptions and communication lines), discuss the methodology model and after presenting the tools used for process control, it will present the defined processes. Finally it will outline major sub-projects of the FreeBSD project. +After providing definitions of terms used, this document will outline the organisational structure (including role descriptions and communication lines), discuss the methodology model and after presenting the tools used for process control, it will present the defined processes. +Finally it will outline major sub-projects of the FreeBSD project. -[<>] Section 1.2 and 1.3 give the vision and the architectural guidelines for the project. The vision is "To produce the best UNIX-like operating system package possible, with due respect to the original software tools ideology as well as usability, performance and stability." The architectural guidelines help determine whether a problem that someone wants to be solved is within the scope of the project +[<>] Section 1.2 and 1.3 give the vision and the architectural guidelines for the project. +The vision is "To produce the best UNIX-like operating system package possible, with due respect to the original software tools ideology as well as usability, performance and stability." +The architectural guidelines help determine whether a problem that someone wants to be solved is within the scope of the project [[definitions]] == Definitions @@ -102,22 +117,32 @@ After providing definitions of terms used, this document will outline the organi [[ref-activity]] === Activity -An "activity" is an element of work performed during the course of a project [<>]. It has an output and leads towards an outcome. Such an output can either be an input to another activity or a part of the process' delivery. +An "activity" is an element of work performed during the course of a project [<>]. +It has an output and leads towards an outcome. +Such an output can either be an input to another activity or a part of the process' delivery. [[def-process]] === Process -A "process" is a series of activities that lead towards a particular outcome. A process can consist of one or more sub-processes. An example of a process is software design. +A "process" is a series of activities that lead towards a particular outcome. +A process can consist of one or more sub-processes. +An example of a process is software design. [[ref-hat]] === Hat -A "hat" is synonymous with role. A hat has certain responsibilities in a process and for the process outcome. The hat executes activities. It is well defined what issues the hat should be contacted about by the project members and people outside the project. +A "hat" is synonymous with role. +A hat has certain responsibilities in a process and for the process outcome. +The hat executes activities. +It is well defined what issues the hat should be contacted about by the project members and people outside the project. [[ref-outcome]] === Outcome -An "outcome" is the final output of the process. This is synonymous with deliverable, that is defined as "any measurable, tangible, verifiable outcome, result or item that must be produced to complete a project or part of a project. Often used more narrowly in reference to an external deliverable, which is a deliverable that is subject to approval by the project sponsor or customer" by [<>]. Examples of outcomes are a piece of software, a decision made or a report written. +An "outcome" is the final output of the process. +This is synonymous with deliverable, that is defined as "any measurable, tangible, verifiable outcome, result or item that must be produced to complete a project or part of a project. +Often used more narrowly in reference to an external deliverable, which is a deliverable that is subject to approval by the project sponsor or customer" by [<>]. +Examples of outcomes are a piece of software, a decision made or a report written. [[ref-freebsd]] === FreeBSD @@ -149,11 +174,18 @@ The FreeBSD Project's structure (in order of descending authority) Number of committers has been determined by going through CVS logs from January 1st, 2004 to December 31st, 2004 and contributors by going through the list of contributions and problem reports. -The main resource in the FreeBSD community is its developers: the committers and contributors. It is with their contributions that the project can move forward. Regular developers are referred to as contributors. As of January 1st, 2003, there are an estimated 5500 contributors on the project. +The main resource in the FreeBSD community is its developers: the committers and contributors. +It is with their contributions that the project can move forward. +Regular developers are referred to as contributors. +As of January 1st, 2003, there are an estimated 5500 contributors on the project. -Committers are developers with the privilege of being able to commit changes. These are usually the most active developers who are willing to spend their time not only integrating their own code but integrating code submitted by the developers who do not have this privilege. They are also the developers who elect the core team, and they have access to closed discussions. +Committers are developers with the privilege of being able to commit changes. +These are usually the most active developers who are willing to spend their time not only integrating their own code but integrating code submitted by the developers who do not have this privilege. +They are also the developers who elect the core team, and they have access to closed discussions. -The project can be grouped into four distinct separate parts, and most developers will focus their involvement in one part of FreeBSD. The four parts are kernel development, userland development, ports and documentation. When referring to the base system, both kernel and userland is meant. +The project can be grouped into four distinct separate parts, and most developers will focus their involvement in one part of FreeBSD. +The four parts are kernel development, userland development, ports and documentation. +When referring to the base system, both kernel and userland is meant. This split changes our table to look like this: @@ -195,17 +227,32 @@ The FreeBSD Project's structure with committers in categories |~3000 |=== -Number of committers per area has been determined by going through CVS logs from January 1st, 2004 to December 31st, 2004. Note that many committers work in multiple areas, making the total number higher than the real number of committers. The total number of committers at that time was 269. +Number of committers per area has been determined by going through CVS logs from January 1st, 2004 to December 31st, 2004. +Note that many committers work in multiple areas, making the total number higher than the real number of committers. +The total number of committers at that time was 269. -Committers fall into three groups: committers who are only concerned with one area of the project (for instance file systems), committers who are involved only with one sub-project, and committers who commit to different parts of the code, including sub-projects. Because some committers work on different parts, the total number in the committers section of the table is higher than in the above table. +Committers fall into three groups: committers who are only concerned with one area of the project (for instance file systems), committers who are involved only with one sub-project, and committers who commit to different parts of the code, including sub-projects. +Because some committers work on different parts, the total number in the committers section of the table is higher than in the above table. -The kernel is the main building block of FreeBSD. While the userland applications are protected against faults in other userland applications, the entire system is vulnerable to errors in the kernel. This, combined with the vast amount of dependencies in the kernel and that it is not easy to see all the consequences of a kernel change, demands developers with a relative full understanding of the kernel. Multiple development efforts in the kernel also require a closer coordination than userland applications do. +The kernel is the main building block of FreeBSD. +While the userland applications are protected against faults in other userland applications, the entire system is vulnerable to errors in the kernel. +This, combined with the vast amount of dependencies in the kernel and that it is not easy to see all the consequences of a kernel change, demands developers with a relative full understanding of the kernel. +Multiple development efforts in the kernel also require a closer coordination than userland applications do. -The core utilities, known as userland, provide the interface that identifies FreeBSD, both user interface, shared libraries and external interfaces to connecting clients. Currently, 162 people are involved in userland development and maintenance, many being maintainers for their own part of the code. Maintainership will be discussed in the <> section. +The core utilities, known as userland, provide the interface that identifies FreeBSD, both user interface, shared libraries and external interfaces to connecting clients. +Currently, 162 people are involved in userland development and maintenance, many being maintainers for their own part of the code. +Maintainership will be discussed in the <> section. -Documentation is handled by <> and includes all documents surrounding the FreeBSD project, including the web pages. There were during 2004 101 people making commits to the FreeBSD Documentation Project. +Documentation is handled by <> and includes all documents surrounding the FreeBSD project, including the web pages. +There were during 2004 101 people making commits to the FreeBSD Documentation Project. -Ports is the collection of meta-data that is needed to make software packages build correctly on FreeBSD. An example of a port is the port for the web-browser Mozilla. It contains information about where to fetch the source, what patches to apply and how, and how the package should be installed on the system. This allows automated tools to fetch, build and install the package. As of this writing, there are more than 12600 ports available. footnote:[Statistics are generated by counting the number of entries in the file fetched by portsdb by April 1st, 2005. portsdb is a part of the port sysutils/portupgrade.] , ranging from web servers to games, programming languages and most of the application types that are in use on modern computers. Ports will be discussed further in the section <>. +Ports is the collection of meta-data that is needed to make software packages build correctly on FreeBSD. +An example of a port is the port for the web-browser Mozilla. +It contains information about where to fetch the source, what patches to apply and how, and how the package should be installed on the system. +This allows automated tools to fetch, build and install the package. +As of this writing, there are more than 12600 ports available. +footnote:[Statistics are generated by counting the number of entries in the file fetched by portsdb by April 1st, 2005. portsdb is a part of the port sysutils/portupgrade.] , ranging from web servers to games, programming languages and most of the application types that are in use on modern computers. +Ports will be discussed further in the section <>. [[methodology-model]] == Methodology model @@ -213,7 +260,8 @@ Ports is the collection of meta-data that is needed to make software packages bu [[development-model]] === Development model -There is no defined model for how people write code in FreeBSD. However, Niels Jørgenssen has suggested a model of how written code is integrated into the project. +There is no defined model for how people write code in FreeBSD. +However, Niels Jørgenssen has suggested a model of how written code is integrated into the project. Jørgenssen's model for change integration @@ -251,30 +299,58 @@ Jørgenssen's model for change integration The "development release" is the FreeBSD-CURRENT ("-CURRENT") branch and the "production release" is the FreeBSD-STABLE branch ("-STABLE") [<>]. -This is a model for one change, and shows that after coding, developers seek community review and try integrating it with their own systems. After integrating the change into the development release, called FreeBSD-CURRENT, it is tested by many users and developers in the FreeBSD community. After it has gone through enough testing, it is merged into the production release, called FreeBSD-STABLE. Unless each stage is finished successfully, the developer needs to go back and make modifications in the code and restart the process. To integrate a change with either -CURRENT or -STABLE is called making a commit. +This is a model for one change, and shows that after coding, developers seek community review and try integrating it with their own systems. +After integrating the change into the development release, called FreeBSD-CURRENT, it is tested by many users and developers in the FreeBSD community. +After it has gone through enough testing, it is merged into the production release, called FreeBSD-STABLE. +Unless each stage is finished successfully, the developer needs to go back and make modifications in the code and restart the process. +To integrate a change with either -CURRENT or -STABLE is called making a commit. -Jørgensen found that most FreeBSD developers work individually, meaning that this model is used in parallel by many developers on the different ongoing development efforts. A developer can also be working on multiple changes, so that while they are waiting for review or people to test one or more of their changes, they may be writing another change. +Jørgensen found that most FreeBSD developers work individually, meaning that this model is used in parallel by many developers on the different ongoing development efforts. +A developer can also be working on multiple changes, so that while they are waiting for review or people to test one or more of their changes, they may be writing another change. -As each commit represents an increment, this is a massively incremental model. The commits are in fact so frequent that during one year footnote:[The period from January 1st, 2004 to December 31st, 2004 was examined to find this number.] , 85427 commits were made, making a daily average of 233 commits. +As each commit represents an increment, this is a massively incremental model. +The commits are in fact so frequent that during one year footnote:[The period from January 1st, 2004 to December 31st, 2004 was examined to find this number.] , 85427 commits were made, making a daily average of 233 commits. -Within the "code" bracket in Jørgensen's model, each programmer has their own working style and follows their own development models. The bracket could very well have been called "development" as it includes requirements gathering and analysis, system and detailed design, implementation and verification. However, the only output from these stages is the source code or system documentation. +Within the "code" bracket in Jørgensen's model, each programmer has their own working style and follows their own development models. +The bracket could very well have been called "development" as it includes requirements gathering and analysis, system and detailed design, implementation and verification. +However, the only output from these stages is the source code or system documentation. -From a stepwise model's perspective (such as the waterfall model), the other brackets can be seen as further verification and system integration. This system integration is also important to see if a change is accepted by the community. Up until the code is committed, the developer is free to choose how much to communicate about it to the rest of the project. In order for -CURRENT to work as a buffer (so that bright ideas that had some undiscovered drawbacks can be backed out) the minimum time a commit should be in -CURRENT before merging it to -STABLE is 3 days. Such a merge is referred to as an MFC (Merge From Current). +From a stepwise model's perspective (such as the waterfall model), the other brackets can be seen as further verification and system integration. +This system integration is also important to see if a change is accepted by the community. +Up until the code is committed, the developer is free to choose how much to communicate about it to the rest of the project. +In order for -CURRENT to work as a buffer (so that bright ideas that had some undiscovered drawbacks can be backed out) the minimum time a commit should be in -CURRENT before merging it to -STABLE is 3 days. +Such a merge is referred to as an MFC (Merge From Current). -It is important to notice the word "change". Most commits do not contain radical new features, but are maintenance updates. +It is important to notice the word "change". +Most commits do not contain radical new features, but are maintenance updates. -The only exceptions from this model are security fixes and changes to features that are deprecated in the -CURRENT branch. In these cases, changes can be committed directly to the -STABLE branch. +The only exceptions from this model are security fixes and changes to features that are deprecated in the -CURRENT branch. +In these cases, changes can be committed directly to the -STABLE branch. -In addition to many people working on the project, there are many related projects to the FreeBSD Project. These are either projects developing brand new features, sub-projects or projects whose outcome is incorporated into FreeBSD footnote:[For instance, the development of the Bluetooth stack started as a sub-project until it was deemed stable enough to be merged into the -CURRENT branch. Now it is a part of the core FreeBSD system.]. These projects fit into the FreeBSD Project just like regular development efforts: they produce code that is integrated with the FreeBSD Project. However, some of them (like Ports and Documentation) have the privilege of being applicable to both branches or commit directly to both -CURRENT and -STABLE. +In addition to many people working on the project, there are many related projects to the FreeBSD Project. +These are either projects developing brand new features, sub-projects or projects whose outcome is incorporated into FreeBSD footnote:[For instance, the development of the Bluetooth stack started as a sub-project until it was deemed stable enough to be merged into the -CURRENT branch. Now it is a part of the core FreeBSD system.]. +These projects fit into the FreeBSD Project just like regular development efforts: they produce code that is integrated with the FreeBSD Project. +However, some of them (like Ports and Documentation) have the privilege of being applicable to both branches or commit directly to both -CURRENT and -STABLE. -There is no standards to how design should be done, nor is design collected in a centralised repository. The main design is that of 4.4BSD. footnote:[According to Kirk McKusick, after 20 years of developing UNIX operating systems, the interfaces are for the most part figured out. There is therefore no need for much design. However, new applications of the system and new hardware leads to some implementations being more beneficial than those that used to be preferred. One example is the introduction of web browsing that made the normal TCP/IP connection a short burst of data rather than a steady stream over a longer period of time.] As design is a part of the "Code" bracket in Jørgenssen's model, it is up to every developer or sub-project how this should be done. Even if the design should be stored in a central repository, the output from the design stages would be of limited use as the differences of methodologies would make them poorly if at all interoperable. For the overall desi gn of the project, the project relies on the sub-projects to negotiate fit interfaces between each other rather than to dictate interfacing. +There is no standards to how design should be done, nor is design collected in a centralised repository. +The main design is that of 4.4BSD. +footnote:[According to Kirk McKusick, after 20 years of developing UNIX operating systems, the interfaces are for the most part figured out. There is therefore no need for much design. However, new applications of the system and new hardware leads to some implementations being more beneficial than those that used to be preferred. One example is the introduction of web browsing that made the normal TCP/IP connection a short burst of data rather than a steady stream over a longer period of time.] +As design is a part of the "Code" bracket in Jørgenssen's model, it is up to every developer or sub-project how this should be done. +Even if the design should be stored in a central repository, the output from the design stages would be of limited use as the differences of methodologies would make them poorly if at all interoperable. +For the overall design of the project, the project relies on the sub-projects to negotiate fit interfaces between each other rather than to dictate interfacing. [[release-branches]] === Release branches -The releases of FreeBSD are best illustrated by a tree with many branches where each major branch represents a major version. Minor versions are represented by branches of the major branches. +The releases of FreeBSD are best illustrated by a tree with many branches where each major branch represents a major version. +Minor versions are represented by branches of the major branches. -In the following release tree, arrows that follow one-another in a particular direction represent a branch. Boxes with full lines and diamonds represent official releases. Boxes with dotted lines represent the development branch at that time. Security branches are represented by ovals. Diamonds differ from boxes in that they represent a fork, meaning a place where a branch splits into two branches where one of the branches becomes a sub-branch. For example, at 4.0-RELEASE the 4.0-CURRENT branch split into 4-STABLE and 5.0-CURRENT. At 4.5-RELEASE, the branch forked off a security branch called RELENG_4_5. +In the following release tree, arrows that follow one-another in a particular direction represent a branch. +Boxes with full lines and diamonds represent official releases. +Boxes with dotted lines represent the development branch at that time. +Security branches are represented by ovals. +Diamonds differ from boxes in that they represent a fork, meaning a place where a branch splits into two branches where one of the branches becomes a sub-branch. +For example, at 4.0-RELEASE the 4.0-CURRENT branch split into 4-STABLE and 5.0-CURRENT. At 4.5-RELEASE, the branch forked off a security branch called RELENG_4_5. .The FreeBSD release tree image::branches.png[Refer to table below for a screen-reader friendly version.] @@ -312,15 +388,25 @@ image::branches.png[Refer to table below for a screen-reader friendly version.] |=== -The latest -CURRENT version is always referred to as -CURRENT, while the latest -STABLE release is always referred to as -STABLE. In this figure, -STABLE refers to 4-STABLE while -CURRENT refers to 5.0-CURRENT following 5.0-RELEASE. [<>] +The latest -CURRENT version is always referred to as -CURRENT, while the latest -STABLE release is always referred to as -STABLE. +In this figure, -STABLE refers to 4-STABLE while -CURRENT refers to 5.0-CURRENT following 5.0-RELEASE. [<>] -A "major release" is always made from the -CURRENT branch. However, the -CURRENT branch does not need to fork at that point in time, but can focus on stabilising. An example of this is that following 3.0-RELEASE, 3.1-RELEASE was also a continuation of the -CURRENT-branch, and -CURRENT did not become a true development branch until this version was released and the 3-STABLE branch was forked. When -CURRENT returns to becoming a development branch, it can only be followed by a major release. 5-STABLE is predicted to be forked off 5.0-CURRENT at around 5.3-RELEASE. It is not until 5-STABLE is forked that the development branch will be branded 6.0-CURRENT. +A "major release" is always made from the -CURRENT branch. +However, the -CURRENT branch does not need to fork at that point in time, but can focus on stabilising. +An example of this is that following 3.0-RELEASE, 3.1-RELEASE was also a continuation of the -CURRENT-branch, and -CURRENT did not become a true development branch until this version was released and the 3-STABLE branch was forked. +When -CURRENT returns to becoming a development branch, it can only be followed by a major release. +5-STABLE is predicted to be forked off 5.0-CURRENT at around 5.3-RELEASE. +It is not until 5-STABLE is forked that the development branch will be branded 6.0-CURRENT. A "minor release" is made from the -CURRENT branch following a major release, or from the -STABLE branch. -Following and including, 4.3-RELEASEfootnote:[The first release this actually happened for was 4.5-RELEASE, but security branches were at the same time created for 4.3-RELEASE and 4.4-RELEASE.], when a minor release has been made, it becomes a "security branch". This is meant for organisations that do not want to follow the -STABLE branch and the potential new/changed features it offers, but instead require an absolutely stable environment, only updating to implement security updates. footnote:[There is a terminology overlap with respect to the word "stable", which leads to some confusion. The -STABLE branch is still a development branch, whose goal is to be useful for most people. If it is never acceptable for a system to get changes that are not announced at the time it is deployed, that system should run a security branch.] +Following and including, 4.3-RELEASEfootnote:[The first release this actually happened for was 4.5-RELEASE, but security branches were at the same time created for 4.3-RELEASE and 4.4-RELEASE.], when a minor release has been made, it becomes a "security branch". +This is meant for organisations that do not want to follow the -STABLE branch and the potential new/changed features it offers, but instead require an absolutely stable environment, only updating to implement security updates. footnote:[There is a terminology overlap with respect to the word "stable", which leads to some confusion. The -STABLE branch is still a development branch, whose goal is to be useful for most people. If it is never acceptable for a system to get changes that are not announced at the time it is deployed, that system should run a security branch.] -Each update to a security branch is called a "patchlevel". For every security enhancement that is done, the patchlevel number is increased, making it easy for people tracking the branch to see what security enhancements they have implemented. In cases where there have been especially serious security flaws, an entire new release can be made from a security branch. An example of this is 4.6.2-RELEASE. +Each update to a security branch is called a "patchlevel". +For every security enhancement that is done, the patchlevel number is increased, making it easy for people tracking the branch to see what security enhancements they have implemented. +In cases where there have been especially serious security flaws, an entire new release can be made from a security branch. +An example of this is 4.6.2-RELEASE. [[model-summary]] === Model summary @@ -332,13 +418,25 @@ image::freebsd-code-model.png[Refer to paragraphs below for a screen-reader frie The tree of the FreeBSD development with ongoing development efforts and continuous integration. -The tree symbolises the release versions with major versions spawning new main branches and minor versions being versions of the main branch. The top branch is the -CURRENT branch where all new development is integrated, and the -STABLE branch is the branch directly below it. Below the -STABLE branch are old, unsupported versions. +The tree symbolises the release versions with major versions spawning new main branches and minor versions being versions of the main branch. +The top branch is the -CURRENT branch where all new development is integrated, and the -STABLE branch is the branch directly below it. +Below the -STABLE branch are old, unsupported versions. -Clouds of development efforts hang over the project where developers use the development models they see fit. The product of their work is then integrated into -CURRENT where it undergoes parallel debugging and is finally merged from -CURRENT into -STABLE. Security fixes are merged from -STABLE to the security branches. +Clouds of development efforts hang over the project where developers use the development models they see fit. +The product of their work is then integrated into -CURRENT where it undergoes parallel debugging and is finally merged from -CURRENT into -STABLE. +Security fixes are merged from -STABLE to the security branches. -Many committers have a special area of responsibility. These roles are called hats. These hats can be either project roles, such as public relations officer, or maintainer for a certain area of the code. Because this is a project where people give voluntarily of their spare time, people with assigned hats are not always available. They must therefore appoint a deputy that can perform the hat's role in their absence. The other option is to have the role held by a group. +Many committers have a special area of responsibility. +These roles are called hats. +These hats can be either project roles, such as public relations officer, or maintainer for a certain area of the code. +Because this is a project where people give voluntarily of their spare time, people with assigned hats are not always available. +They must therefore appoint a deputy that can perform the hat's role in their absence. +The other option is to have the role held by a group. -Many of these hats are not formalised. Formalised hats have a charter stating the exact purpose of the hat along with its privileges and responsibilities. The writing of such charters is a new part of the project, and has thus yet to be completed for all hats. These hat descriptions are not such a formalisation, rather a summary of the role with links to the charter where available and contact addresses. +Many of these hats are not formalised. +Formalised hats have a charter stating the exact purpose of the hat along with its privileges and responsibilities. +The writing of such charters is a new part of the project, and has thus yet to be completed for all hats. +These hat descriptions are not such a formalisation, rather a summary of the role with links to the charter where available and contact addresses. [[sect-hats]] == Hats @@ -354,42 +452,55 @@ A Contributor contributes to the FreeBSD project either as a developer, as an au [[role-committer]] ==== Committer -A person who has the required privileges to add their code or documentation to the repository. A committer has made a commit within the past 12 months. [<>] An active committer is a committer who has made an average of one commit per month during that time. +A person who has the required privileges to add their code or documentation to the repository. +A committer has made a commit within the past 12 months. +[<>] An active committer is a committer who has made an average of one commit per month during that time. -It is worth noting that there are no technical barriers to prevent someone, once having gained commit privileges to the main- or a sub-project, to make commits in parts of that project's source the committer did not specifically get permission to modify. However, when wanting to make modifications to parts a committer has not been involved in before, they should read the logs to see what has happened in this area before, and also read the MAINTAINERS file to see if the maintainer of this part has any special requests on how changes in the code should be made. +It is worth noting that there are no technical barriers to prevent someone, once having gained commit privileges to the main- or a sub-project, to make commits in parts of that project's source the committer did not specifically get permission to modify. +However, when wanting to make modifications to parts a committer has not been involved in before, they should read the logs to see what has happened in this area before, and also read the MAINTAINERS file to see if the maintainer of this part has any special requests on how changes in the code should be made. [[role-core]] ==== Core Team -The core team is elected by the committers from the pool of committers and serves as the board of directors of the FreeBSD project. It promotes active contributors to committers, assigns people to well-defined hats, and is the final arbiter of decisions involving which way the project should be heading. As of July 1st, 2004, core consisted of 9 members. Elections are held every two years. +The core team is elected by the committers from the pool of committers and serves as the board of directors of the FreeBSD project. +It promotes active contributors to committers, assigns people to well-defined hats, and is the final arbiter of decisions involving which way the project should be heading. +As of July 1st, 2004, core consisted of 9 members. +Elections are held every two years. [[role-maintainer]] ==== Maintainership -Maintainership means that that person is responsible for what is allowed to go into that area of the code and has the final say should disagreements over the code occur. This involves proactive work aimed at stimulating contributions and reactive work in reviewing commits. +Maintainership means that that person is responsible for what is allowed to go into that area of the code and has the final say should disagreements over the code occur. +This involves proactive work aimed at stimulating contributions and reactive work in reviewing commits. -With the FreeBSD source comes the MAINTAINERS file that contains a one-line summary of how each maintainer would like contributions to be made. Having this notice and contact information enables developers to focus on the development effort rather than being stuck in a slow correspondence should the maintainer be unavailable for some time. +With the FreeBSD source comes the MAINTAINERS file that contains a one-line summary of how each maintainer would like contributions to be made. +Having this notice and contact information enables developers to focus on the development effort rather than being stuck in a slow correspondence should the maintainer be unavailable for some time. -If the maintainer is unavailable for an unreasonably long period of time, and other people do a significant amount of work, maintainership may be switched without the maintainer's approval. This is based on the stance that maintainership should be demonstrated, not declared. +If the maintainer is unavailable for an unreasonably long period of time, and other people do a significant amount of work, maintainership may be switched without the maintainer's approval. +This is based on the stance that maintainership should be demonstrated, not declared. Maintainership of a particular piece of code is a hat that is not held as a group. [[official-hats]] === Official Hats -The official hats in the FreeBSD Project are hats that are more or less formalised and mainly administrative roles. They have the authority and responsibility for their area. The following list shows the responsibility lines and gives a description of each hat, including who it is held by. +The official hats in the FreeBSD Project are hats that are more or less formalised and mainly administrative roles. +They have the authority and responsibility for their area. +The following list shows the responsibility lines and gives a description of each hat, including who it is held by. [[role-doc-manager]] ==== Documentation project manager <> architect is responsible for defining and following up documentation goals for the committers in the Documentation project, which they supervise. -Hat held by: The DocEng team mailto:doceng@FreeBSD.org[doceng@FreeBSD.org]. The https://www.freebsd.org/internal/doceng/[ DocEng Charter]. +Hat held by: The DocEng team mailto:doceng@FreeBSD.org[doceng@FreeBSD.org]. +The https://www.freebsd.org/internal/doceng/[ DocEng Charter]. [[role-postmaster]] ==== Postmaster -The Postmaster is responsible for mail being correctly delivered to the committers' email address. They are also responsible for ensuring that the mailing lists work and should take measures against possible disruptions of mail such as having troll-, spam- and virus-filters. +The Postmaster is responsible for mail being correctly delivered to the committers' email address. +They are also responsible for ensuring that the mailing lists work and should take measures against possible disruptions of mail such as having troll-, spam- and virus-filters. Hat currently held by: the Postmaster Team mailto:postmaster@FreeBSD.org[postmaster@FreeBSD.org]. @@ -407,7 +518,8 @@ The responsibilities of the Release Engineering Team are Further information about the development process is available in the <> section. [[role-releng]] -Hat held by: the Release Engineering team mailto:re@FreeBSD.org[re@FreeBSD.org]. The https://www.freebsd.org/releng/charter/[ Release Engineering Charter]. +Hat held by: the Release Engineering team mailto:re@FreeBSD.org[re@FreeBSD.org]. +The https://www.freebsd.org/releng/charter/[ Release Engineering Charter]. [[role-pr-cr]] ==== Public Relations & Corporate Liaison @@ -424,28 +536,35 @@ This hat is currently not occupied. [[role-security-officer]] ==== Security Officer -The Security Officer's main responsibility is to coordinate information exchange with others in the security community and in the FreeBSD project. The Security Officer is also responsible for taking action when security problems are reported and promoting proactive development behavior when it comes to security. +The Security Officer's main responsibility is to coordinate information exchange with others in the security community and in the FreeBSD project. +The Security Officer is also responsible for taking action when security problems are reported and promoting proactive development behavior when it comes to security. -Because of the fear that information about vulnerabilities may leak out to people with malicious intent before a patch is available, only the Security Officer, consisting of an officer, a deputy and two <> members, receive sensitive information about security issues. However, to create or implement a patch, the Security Officer has the Security Officer Team mailto:security-team@FreeBSD.org[security-team@FreeBSD.org] to help do the work. +Because of the fear that information about vulnerabilities may leak out to people with malicious intent before a patch is available, only the Security Officer, consisting of an officer, a deputy and two <> members, receive sensitive information about security issues. +However, to create or implement a patch, the Security Officer has the Security Officer Team mailto:security-team@FreeBSD.org[security-team@FreeBSD.org] to help do the work. [[role-repo-manager]] ==== Source Repository Manager -The Source Repository Manager is the only one who is allowed to directly modify the repository without using the <> tool. It is their responsibility to ensure that technical problems that arise in the repository are resolved quickly. The source repository manager has the authority to back out commits if this is necessary to resolve a SVN technical problem. +The Source Repository Manager is the only one who is allowed to directly modify the repository without using the <> tool. +It is their responsibility to ensure that technical problems that arise in the repository are resolved quickly. +The source repository manager has the authority to back out commits if this is necessary to resolve a SVN technical problem. Hat held by: the Source Repository Manager mailto:clusteradm@FreeBSD.org[clusteradm@FreeBSD.org]. [[role-election-manager]] ==== Election Manager -The Election Manager is responsible for the <> process. The manager is responsible for running and maintaining the election system, and is the final authority should minor unforeseen events happen in the election process. Major unforeseen events have to be discussed with the <> +The Election Manager is responsible for the <> process. +The manager is responsible for running and maintaining the election system, and is the final authority should minor unforeseen events happen in the election process. +Major unforeseen events have to be discussed with the <> Hat held only during elections. [[role-webmaster]] ==== Web site Management -The Web site Management hat is responsible for coordinating the rollout of updated web pages on mirrors around the world, for the overall structure of the primary web site and the system it is running upon. The management needs to coordinate the content with <> and acts as maintainer for the "www" tree. +The Web site Management hat is responsible for coordinating the rollout of updated web pages on mirrors around the world, for the overall structure of the primary web site and the system it is running upon. +The management needs to coordinate the content with <> and acts as maintainer for the "www" tree. Hat held by: the FreeBSD Webmasters mailto:www@FreeBSD.org[www@FreeBSD.org]. @@ -454,7 +573,8 @@ Hat held by: the FreeBSD Webmasters mailto:www@FreeBSD.org[www@FreeBSD.org]. The Ports Manager acts as a liaison between <> and the core project, and all requests from the project should go to the ports manager. -Hat held by: the Ports Management Team mailto:portmgr@FreeBSD.org[portmgr@FreeBSD.org]. The https://www.freebsd.org/portmgr/charter/[Portmgr charter]. +Hat held by: the Ports Management Team mailto:portmgr@FreeBSD.org[portmgr@FreeBSD.org]. +The https://www.freebsd.org/portmgr/charter/[Portmgr charter]. [[role-standards]] ==== Standards @@ -466,14 +586,16 @@ Hat currently held by: Garrett Wollman mailto:wollman@FreeBSD.org[wollman@FreeBS [[role-core-secretary]] ==== Core Secretary -The Core Secretary's main responsibility is to write drafts to and publish the final Core Reports. The secretary also keeps the core agenda, thus ensuring that no balls are dropped unresolved. +The Core Secretary's main responsibility is to write drafts to and publish the final Core Reports. +The secretary also keeps the core agenda, thus ensuring that no balls are dropped unresolved. Hat currently held by: {bofh}. [[role-bugmeister]] ==== Bugmeister -The Bugmeister is responsible for ensuring that the maintenance database is in working order, that the entries are correctly categorised and that there are no invalid entries. They supervise bugbusters. +The Bugmeister is responsible for ensuring that the maintenance database is in working order, that the entries are correctly categorised and that there are no invalid entries. +They supervise bugbusters. Hat currently held by: the Bugmeister Team mailto:bugmeister@FreeBSD.org[bugmeister@FreeBSD.org]. @@ -482,14 +604,16 @@ Hat currently held by: the Bugmeister Team mailto:bugmeister@FreeBSD.org[bugmeis The task of the donations liaison officer is to match the developers with needs with people or organisations willing to make a donation. -Hat held by: the Donations Liaison Office mailto:donations@FreeBSD.org[donations@FreeBSD.org]. The https://www.freebsd.org/donations/[ Donations Liaison Charter]. +Hat held by: the Donations Liaison Office mailto:donations@FreeBSD.org[donations@FreeBSD.org]. +The https://www.freebsd.org/donations/[ Donations Liaison Charter]. [[role-admin]] ==== Admin (Also called "FreeBSD Cluster Admin") -The admin team consists of the people responsible for administrating the computers that the project relies on for its distributed work and communication to be synchronised. It consists mainly of those people who have physical access to the servers. +The admin team consists of the people responsible for administrating the computers that the project relies on for its distributed work and communication to be synchronised. +It consists mainly of those people who have physical access to the servers. Hat held by: the Admin team mailto:admin@FreeBSD.org[admin@FreeBSD.org]. @@ -521,7 +645,8 @@ The person(s) or organisation whom external code comes from and whom patches are People on the mailing list where the request for review is posted. -The following section will describe the defined project processes. Issues that are not handled by these processes happen on an ad-hoc basis based on what has been customary to do in similar cases. +The following section will describe the defined project processes. +Issues that are not handled by these processes happen on an ad-hoc basis based on what has been customary to do in similar cases. [[model-processes]] == Processes @@ -529,29 +654,46 @@ The following section will describe the defined project processes. Issues that a [[proc-addrem-committer]] === Adding new and removing old committers -The Core team has the responsibility of giving and removing commit privileges to contributors. This can only be done through a vote on the core mailing list. The ports and documentation sub-projects can give commit privileges to people working on these projects, but have to date not removed such privileges. +The Core team has the responsibility of giving and removing commit privileges to contributors. +This can only be done through a vote on the core mailing list. +The ports and documentation sub-projects can give commit privileges to people working on these projects, but have to date not removed such privileges. -Normally a contributor is recommended to core by a committer. For contributors or outsiders to contact core asking to be a committer is not well thought of and is usually rejected. +Normally a contributor is recommended to core by a committer. +For contributors or outsiders to contact core asking to be a committer is not well thought of and is usually rejected. -If the area of particular interest for the developer potentially overlaps with other committers' area of maintainership, the opinion of those maintainers is sought. However, it is frequently this committer that recommends the developer. +If the area of particular interest for the developer potentially overlaps with other committers' area of maintainership, the opinion of those maintainers is sought. +However, it is frequently this committer that recommends the developer. -When a contributor is given committer status, they are assigned a mentor. The committer who recommended the new committer will, in the general case, take it upon themselves to be the new committers mentor. +When a contributor is given committer status, they are assigned a mentor. +The committer who recommended the new committer will, in the general case, take it upon themselves to be the new committers mentor. -When a contributor is given their commit bit, a <>-signed email is sent from either <>, <>, or nik@freebsd.org to both admins@freebsd.org, the assigned mentor, the new committer, and core confirming the approval of a new account. The mentor then gathers a password line, <> public key, and PGP key from the new committer and sends them to <>. When the new account is created, the mentor activates the commit bit and guides the new committer through the rest of the initial process. +When a contributor is given their commit bit, a <>-signed email is sent from either <>, <>, or nik@freebsd.org to both admins@freebsd.org, the assigned mentor, the new committer, and core confirming the approval of a new account. +The mentor then gathers a password line, <> public key, and PGP key from the new committer and sends them to <>. +When the new account is created, the mentor activates the commit bit and guides the new committer through the rest of the initial process. .Process summary: adding a new committer image::proc-add-committer.png[Refer to paragraph below for a screen-reader friendly version.] -When a contributor sends a piece of code, the receiving committer may choose to recommend that the contributor is given commit privileges. If they recommend this to core, core will vote on this recommendation. If the vote is in favour, a mentor is assigned the new committer and the new committer has to email their details to the administrators for an account to be created. After this, the new committer is all set to make their first commit. By tradition, this is by adding their name to the committers list. +When a contributor sends a piece of code, the receiving committer may choose to recommend that the contributor is given commit privileges. +If they recommend this to core, core will vote on this recommendation. +If the vote is in favour, a mentor is assigned the new committer and the new committer has to email their details to the administrators for an account to be created. +After this, the new committer is all set to make their first commit. +By tradition, this is by adding their name to the committers list. -Recall that a committer is considered to be someone who has committed code during the past 12 months. However, it is not until after 18 months of inactivity have passed that commit privileges are eligible to be revoked. [<>] There are, however, no automatic procedures for doing this. For reactions concerning commit privileges not triggered by time, see <>. +Recall that a committer is considered to be someone who has committed code during the past 12 months. +However, it is not until after 18 months of inactivity have passed that commit privileges are eligible to be revoked. +[<>] +There are, however, no automatic procedures for doing this. +For reactions concerning commit privileges not triggered by time, see <>. .Process summary: removing a committer image::proc-rm-committer.png[Refer to paragraph below for a screen-reader friendly version.] -When Core decides to clean up the committers list, they check who has not made a commit for the past 18 months. Committers who have not done so have their commit bits revoked and their account removed by the administrators. +When Core decides to clean up the committers list, they check who has not made a commit for the past 18 months. +Committers who have not done so have their commit bits revoked and their account removed by the administrators. -It is also possible for committers to request that their commit bit be retired if for some reason they are no longer going to be actively committing to the project. In this case, it can also be restored at a later time by core, should the committer ask. +It is also possible for committers to request that their commit bit be retired if for some reason they are no longer going to be actively committing to the project. +In this case, it can also be restored at a later time by core, should the committer ask. Roles in this process: @@ -566,25 +708,42 @@ Roles in this process: [[committing]] === Committing code -The committing of new or modified code is one of the most frequent processes in the FreeBSD project and will usually happen many times a day. Committing of code can only be done by a "committer". Committers commit either code written by themselves, code submitted to them, or code submitted through a <>. +The committing of new or modified code is one of the most frequent processes in the FreeBSD project and will usually happen many times a day. +Committing of code can only be done by a "committer". +Committers commit either code written by themselves, code submitted to them, or code submitted through a <>. -When code is written by the developer that is non-trivial, they should seek a code review from the community. This is done by sending mail to the relevant list asking for review. Before submitting the code for review, they should ensure it compiles correctly with the entire tree and that all relevant tests run. This is called "pre-commit test". When contributed code is received, it should be reviewed by the committer and tested the same way. +When code is written by the developer that is non-trivial, they should seek a code review from the community. +This is done by sending mail to the relevant list asking for review. +Before submitting the code for review, they should ensure it compiles correctly with the entire tree and that all relevant tests run. +This is called "pre-commit test". +When contributed code is received, it should be reviewed by the committer and tested the same way. -When a change is committed to a part of the source that has been contributed from an outside <>, the maintainer should ensure that the patch is contributed back to the vendor. This is in line with the open source philosophy and makes it easier to stay in sync with outside projects as the patches do not have to be reapplied every time a new release is made. +When a change is committed to a part of the source that has been contributed from an outside <>, the maintainer should ensure that the patch is contributed back to the vendor. +This is in line with the open source philosophy and makes it easier to stay in sync with outside projects as the patches do not have to be reapplied every time a new release is made. -After the code has been available for review and no further changes are necessary, the code is committed into the development branch, -CURRENT. If the change applies for the -STABLE branch or the other branches as well, a "Merge From Current" ("MFC") countdown is set by the committer. After the number of days the committer chose when setting the MFC have passed, an email will automatically be sent to the committer reminding them to commit it to the -STABLE branch (and possibly security branches as well). Only security critical changes should be merged to security branches. +After the code has been available for review and no further changes are necessary, the code is committed into the development branch, -CURRENT. +If the change applies for the -STABLE branch or the other branches as well, a "Merge From Current" ("MFC") countdown is set by the committer. +After the number of days the committer chose when setting the MFC have passed, an email will automatically be sent to the committer reminding them to commit it to the -STABLE branch (and possibly security branches as well). +Only security critical changes should be merged to security branches. -Delaying the commit to -STABLE and other branches allows for "parallel debugging" where the committed code is tested on a wide range of configurations. This makes changes to -STABLE to contain fewer faults and thus giving the branch its name. +Delaying the commit to -STABLE and other branches allows for "parallel debugging" where the committed code is tested on a wide range of configurations. +This makes changes to -STABLE to contain fewer faults and thus giving the branch its name. .Process summary: A committer commits code image::proc-commit.png[Refer to paragraph below for a screen-reader friendly version.] -When a committer has written a piece of code and wants to commit it, they first need to determine if it is trivial enough to go in without prior review or if it should first be reviewed by the developer community. If the code is trivial or has been reviewed and the committer is not the maintainer, they should consult the maintainer before proceeding. If the code is contributed by an outside vendor, the maintainer should create a patch that is sent back to the vendor. The code is then committed and then deployed by the users. Should they find problems with the code, this will be reported and the committer can go back to writing a patch. If a vendor is affected, they can choose to implement or ignore the patch. +When a committer has written a piece of code and wants to commit it, they first need to determine if it is trivial enough to go in without prior review or if it should first be reviewed by the developer community. +If the code is trivial or has been reviewed and the committer is not the maintainer, they should consult the maintainer before proceeding. +If the code is contributed by an outside vendor, the maintainer should create a patch that is sent back to the vendor. +The code is then committed and then deployed by the users. +Should they find problems with the code, this will be reported and the committer can go back to writing a patch. +If a vendor is affected, they can choose to implement or ignore the patch. .Process summary: A contributor commits code image::proc-contrib.png[Refer to paragraphs below and above for a screen-reader friendly version.] -The difference when a contributor makes a code contribution is that they submit the code through the Bugzilla interface. This report is picked up by the maintainer who reviews the code and commits it. +The difference when a contributor makes a code contribution is that they submit the code through the Bugzilla interface. +This report is picked up by the maintainer who reviews the code and commits it. Hats included in this process are: @@ -598,15 +757,22 @@ Hats included in this process are: [[process-core-election]] === Core election -Core elections are held at least every two years. footnote:[The first Core election was held September 2000] Nine core members are elected. New elections are held if the number of core members drops below seven. New elections can also be held should at least 1/3 of the active committers demand this. +Core elections are held at least every two years. footnote:[The first Core election was held September 2000] Nine core members are elected. +New elections are held if the number of core members drops below seven. +New elections can also be held should at least 1/3 of the active committers demand this. When an election is to take place, core announces this at least 6 weeks in advance, and appoints an election manager to run the elections. -Only committers can be elected into core. The candidates need to submit their candidacy at least one week before the election starts, but can refine their statements until the voting starts. They are presented in the http://election.uk.freebsd.org/candidates.html[candidates list]. When writing their election statements, the candidates must answer a few standard questions submitted by the election manager. +Only committers can be elected into core. +The candidates need to submit their candidacy at least one week before the election starts, but can refine their statements until the voting starts. +They are presented in the http://election.uk.freebsd.org/candidates.html[candidates list]. +When writing their election statements, the candidates must answer a few standard questions submitted by the election manager. -During elections, the rule that a committer must have committed during the 12 past months is followed strictly. Only these committers are eligible to vote. +During elections, the rule that a committer must have committed during the 12 past months is followed strictly. +Only these committers are eligible to vote. -When voting, the committer may vote once in support of up to nine nominees. The voting is done over a period of four weeks with reminders being posted on "developers" mailing list that is available to all committers. +When voting, the committer may vote once in support of up to nine nominees. +The voting is done over a period of four weeks with reminders being posted on "developers" mailing list that is available to all committers. The election results are released one week after the election ends, and the new core team takes office one week after the results have been posted. @@ -617,7 +783,9 @@ Votes and candidate statements are archived, but the archives are not publicly a .Process summary: Core elections image::proc-elections.png[Refer to paragraph below for a screen-reader friendly version.] -Core announces the election and selects an election manager who prepares the elections, and when ready, candidates can announce their candidacies through submitting their statements. The committers then vote. After the vote is over, the election results are announced and the new core team takes office. +Core announces the election and selects an election manager who prepares the elections, and when ready, candidates can announce their candidacies through submitting their statements. +The committers then vote. +After the vote is over, the election results are announced and the new core team takes office. Hats in core elections are: @@ -630,22 +798,44 @@ Hats in core elections are: [[new-features]] === Development of new features -Within the project there are sub-projects that are working on new features. These projects are generally done by one person [<>]. Every project is free to organise development as it sees fit. However, when the project is merged to the -CURRENT branch it must follow the project guidelines. When the code has been well tested in the -CURRENT branch and deemed stable enough and relevant to the -STABLE branch, it is merged to the -STABLE branch. - -The requirements of the project are given by developer wishes, requests from the community in terms of direct requests by mail, Problem Reports, commercial funding for the development of features, or contributions by the scientific community. The wishes that come within the responsibility of a developer are given to that developer who prioritises their time between the request and their wishes. A common way to do this is maintain a TODO-list maintained by the project. Items that do not come within someone's responsibility are collected on TODO-lists unless someone volunteers to take the responsibility. All requests, their distribution and follow-up are handled by the <> tool. - -Requirements analysis happens in two ways. The requests that come in are discussed on mailing lists, both within the main project and in the sub-project that the request belongs to or is spawned by the request. Furthermore, individual developers on the sub-project will evaluate the feasibility of the requests and determine the prioritisation between them. Other than archives of the discussions that have taken place, no outcome is created by this phase that is merged into the main project. - -As the requests are prioritised by the individual developers on the basis of doing what they find interesting, necessary, or are funded to do, there is no overall strategy or prioritisation of what requests to regard as requirements and following up their correct implementation. However, most developers have some shared vision of what issues are more important, and they can ask for guidelines from the release engineering team. - -The verification phase of the project is two-fold. Before committing code to the current-branch, developers request their code to be reviewed by their peers. This review is for the most part done by functional testing, but also code review is important. When the code is committed to the branch, a broader functional testing will happen, that may trigger further code review and debugging should the code not behave as expected. This second verification form may be regarded as structural verification. Although the sub-projects themselves may write formal tests such as unit tests, these are usually not collected by the main project and are usually removed before the code is committed to the current branch. footnote:[More and more tests are however performed when building the system (make world). These tests are however a very new addition and no systematic framework for these tests have yet been created.] +Within the project there are sub-projects that are working on new features. +These projects are generally done by one person [<>]. +Every project is free to organise development as it sees fit. +However, when the project is merged to the -CURRENT branch it must follow the project guidelines. +When the code has been well tested in the -CURRENT branch and deemed stable enough and relevant to the -STABLE branch, it is merged to the -STABLE branch. + +The requirements of the project are given by developer wishes, requests from the community in terms of direct requests by mail, Problem Reports, commercial funding for the development of features, or contributions by the scientific community. +The wishes that come within the responsibility of a developer are given to that developer who prioritises their time between the request and their wishes. +A common way to do this is maintain a TODO-list maintained by the project. +Items that do not come within someone's responsibility are collected on TODO-lists unless someone volunteers to take the responsibility. +All requests, their distribution and follow-up are handled by the <> tool. + +Requirements analysis happens in two ways. +The requests that come in are discussed on mailing lists, both within the main project and in the sub-project that the request belongs to or is spawned by the request. +Furthermore, individual developers on the sub-project will evaluate the feasibility of the requests and determine the prioritisation between them. +Other than archives of the discussions that have taken place, no outcome is created by this phase that is merged into the main project. + +As the requests are prioritised by the individual developers on the basis of doing what they find interesting, necessary, or are funded to do, there is no overall strategy or prioritisation of what requests to regard as requirements and following up their correct implementation. +However, most developers have some shared vision of what issues are more important, and they can ask for guidelines from the release engineering team. + +The verification phase of the project is two-fold. +Before committing code to the current-branch, developers request their code to be reviewed by their peers. +This review is for the most part done by functional testing, but also code review is important. +When the code is committed to the branch, a broader functional testing will happen, that may trigger further code review and debugging should the code not behave as expected. +This second verification form may be regarded as structural verification. +Although the sub-projects themselves may write formal tests such as unit tests, these are usually not collected by the main project and are usually removed before the code is committed to the current branch. footnote:[More and more tests are however performed when building the system (make world). These tests are however a very new addition and no systematic framework for these tests have yet been created.] [[model-maintenance]] === Maintenance -It is an advantage to the project to for each area of the source have at least one person that knows this area well. Some parts of the code have designated maintainers. Others have de-facto maintainers, and some parts of the system do not have maintainers. The maintainer is usually a person from the sub-project that wrote and integrated the code, or someone who has ported it from the platform it was written for. footnote:[sendmail and named are examples of code that has been merged from other platforms.] The maintainer's job is to make sure the code is in sync with the project the code comes from if it is contributed code, and apply patches submitted by the community or write fixes to issues that are discovered. +It is an advantage to the project to for each area of the source have at least one person that knows this area well. +Some parts of the code have designated maintainers. Others have de-facto maintainers, and some parts of the system do not have maintainers. +The maintainer is usually a person from the sub-project that wrote and integrated the code, or someone who has ported it from the platform it was written for. +footnote:[sendmail and named are examples of code that has been merged from other platforms.] +The maintainer's job is to make sure the code is in sync with the project the code comes from if it is contributed code, and apply patches submitted by the community or write fixes to issues that are discovered. -The main bulk of work that is put into the FreeBSD project is maintenance. [<>] has made a figure showing the life cycle of changes. +The main bulk of work that is put into the FreeBSD project is maintenance. +[<>] has made a figure showing the life cycle of changes. Jørgenssen's model for change integration @@ -681,23 +871,44 @@ Jørgenssen's model for change integration |code |=== -Here "development release" refers to the -CURRENT branch while "production release" refers to the -STABLE branch. The "pre-commit test" is the functional testing by peer developers when asked to do so or trying out the code to determine the status of the sub-project. "Parallel debugging" is the functional testing that can trigger more review, and debugging when the code is included in the -CURRENT branch. +Here "development release" refers to the -CURRENT branch while "production release" refers to the -STABLE branch. +The "pre-commit test" is the functional testing by peer developers when asked to do so or trying out the code to determine the status of the sub-project. +"Parallel debugging" is the functional testing that can trigger more review, and debugging when the code is included in the -CURRENT branch. -As of this writing, there were 269 committers in the project. When they commit a change to a branch, that constitutes a new release. It is very common for users in the community to track a particular branch. The immediate existence of a new release makes the changes widely available right away and allows for rapid feedback from the community. This also gives the community the response time they expect on issues that are of importance to them. This makes the community more engaged, and thus allows for more and better feedback that again spurs more maintenance and ultimately should create a better product. +As of this writing, there were 269 committers in the project. +When they commit a change to a branch, that constitutes a new release. +It is very common for users in the community to track a particular branch. +The immediate existence of a new release makes the changes widely available right away and allows for rapid feedback from the community. +This also gives the community the response time they expect on issues that are of importance to them. +This makes the community more engaged, and thus allows for more and better feedback that again spurs more maintenance and ultimately should create a better product. Before making changes to code in parts of the tree that has a history unknown to the committer, the committer is required to read the commit logs to see why certain features are implemented the way they are in order not to make mistakes that have previously either been thought through or resolved. [[model-pr]] === Problem reporting -Before FreeBSD 10, FreeBSD included a problem reporting tool called `send-pr`. Problems include bug reports, feature requests, feature enhancements and notices of new versions of external software that are included in the project. Although `send-pr` is available, users and developers are encouraged to submit issues using our https://bugs.freebsd.org/submit/[ problem report form]. - -Problem reports are sent to an email address where it is inserted into the Problem Reports maintenance database. A <> classifies the problem and sends it to the correct group or maintainer within the project. After someone has taken responsibility for the report, the report is being analysed. This analysis includes verifying the problem and thinking out a solution for the problem. Often feedback is required from the report originator or even from the FreeBSD community. Once a patch for the problem is made, the originator may be asked to try it out. Finally, the working patch is integrated into the project, and documented if applicable. It there goes through the regular maintenance cycle as described in section <>. These are the states a problem report can be in: open, analyzed, feedback, patched, suspended and closed. The suspended state is for when further progress is not possible due to the lack of information or for when the task would require s o much work that nobody is working on it at the moment. +Before FreeBSD 10, FreeBSD included a problem reporting tool called `send-pr`. +Problems include bug reports, feature requests, feature enhancements and notices of new versions of external software that are included in the project. +Although `send-pr` is available, users and developers are encouraged to submit issues using our https://bugs.freebsd.org/submit/[ problem report form]. + +Problem reports are sent to an email address where it is inserted into the Problem Reports maintenance database. +A <> classifies the problem and sends it to the correct group or maintainer within the project. +After someone has taken responsibility for the report, the report is being analysed. +This analysis includes verifying the problem and thinking out a solution for the problem. +Often feedback is required from the report originator or even from the FreeBSD community. +Once a patch for the problem is made, the originator may be asked to try it out. +Finally, the working patch is integrated into the project, and documented if applicable. +It there goes through the regular maintenance cycle as described in section <>. +These are the states a problem report can be in: open, analyzed, feedback, patched, suspended and closed. +The suspended state is for when further progress is not possible due to the lack of information or for when the task would require so much work that nobody is working on it at the moment. .Process summary: problem reporting image::proc-pr.png[Refer to paragraph below for a screen-reader friendly version.] -A problem is reported by the report originator. It is then classified by a bugbuster and handed to the correct maintainer. They verify the problem and discuss the problem with the originator until they have enough information to create a working patch. This patch is then committed and the problem report is closed. +A problem is reported by the report originator. +It is then classified by a bugbuster and handed to the correct maintainer. +They verify the problem and discuss the problem with the originator until they have enough information to create a working patch. +This patch is then committed and the problem report is closed. The roles included in this process are: @@ -710,7 +921,10 @@ The roles included in this process are: [[process-reactions]] === Reacting to misbehavior -[<>] has a number of rules that committers should follow. However, it happens that these rules are broken. The following rules exist in order to be able to react to misbehavior. They specify what actions will result in how long a suspension of the committer's commit privileges. +[<>] has a number of rules that committers should follow. +However, it happens that these rules are broken. +The following rules exist in order to be able to react to misbehavior. +They specify what actions will result in how long a suspension of the committer's commit privileges. * Committing during code freezes without the approval of the Release Engineering team - 2 days * Committing to a security branch without approval - 2 days @@ -719,9 +933,13 @@ The roles included in this process are: [<>] -For the suspensions to be efficient, any single core member can implement a suspension before discussing it on the "core" mailing list. Repeat offenders can, with a 2/3 vote by core, receive harsher penalties, including permanent removal of commit privileges. (However, the latter is always viewed as a last resort, due to its inherent tendency to create controversy.) All suspensions are posted to the "developers" mailing list, a list available to committers only. +For the suspensions to be efficient, any single core member can implement a suspension before discussing it on the "core" mailing list. +Repeat offenders can, with a 2/3 vote by core, receive harsher penalties, including permanent removal of commit privileges. +(However, the latter is always viewed as a last resort, due to its inherent tendency to create controversy.) +All suspensions are posted to the "developers" mailing list, a list available to committers only. -It is important that you cannot be suspended for making technical errors. All penalties come from breaking social etiquette. +It is important that you cannot be suspended for making technical errors. +All penalties come from breaking social etiquette. Hats involved in this process: @@ -731,9 +949,17 @@ Hats involved in this process: [[process-release-engineering]] === Release engineering -The FreeBSD project has a Release Engineering team with a principal release engineer that is responsible for creating releases of FreeBSD that can be brought out to the user community via the net or sold in retail outlets. Since FreeBSD is available on multiple platforms and releases for the different architectures are made available at the same time, the team has one person in charge of each architecture. Also, there are roles in the team responsible for coordinating quality assurance efforts, building a package set and for having an updated set of documents. When referring to the release engineer, a representative for the release engineering team is meant. +The FreeBSD project has a Release Engineering team with a principal release engineer that is responsible for creating releases of FreeBSD that can be brought out to the user community via the net or sold in retail outlets. +Since FreeBSD is available on multiple platforms and releases for the different architectures are made available at the same time, the team has one person in charge of each architecture. +Also, there are roles in the team responsible for coordinating quality assurance efforts, building a package set and for having an updated set of documents. +When referring to the release engineer, a representative for the release engineering team is meant. -When a release is coming, the FreeBSD project changes shape somewhat. A release schedule is made containing feature- and code-freezes, release of interim releases and the final release. A feature-freeze means no new features are allowed to be committed to the branch without the release engineers' explicit consent. Code-freeze means no changes to the code (like bugs-fixes) are allowed to be committed without the release engineers' explicit consent. This feature- and code-freeze is known as stabilising. During the release process, the release engineer has the full authority to revert to older versions of code and thus "back out" changes should they find that the changes are not suitable to be included in the release. +When a release is coming, the FreeBSD project changes shape somewhat. +A release schedule is made containing feature- and code-freezes, release of interim releases and the final release. +A feature-freeze means no new features are allowed to be committed to the branch without the release engineers' explicit consent. +Code-freeze means no changes to the code (like bugs-fixes) are allowed to be committed without the release engineers' explicit consent. +This feature- and code-freeze is known as stabilising. +During the release process, the release engineer has the full authority to revert to older versions of code and thus "back out" changes should they find that the changes are not suitable to be included in the release. There are three different kinds of releases: @@ -741,13 +967,30 @@ There are three different kinds of releases: . .X releases are releases of the -STABLE branch. They are scheduled to come out every 4 months. . .X.Y releases are security releases that follow the .X branch. These come out only when sufficient security fixes have been merged since the last release on that branch. New features are rarely included, and the security team is far more involved in these than in regular releases. -For releases of the -STABLE-branch, the release process starts 45 days before the anticipated release date. During the first phase, the first 15 days, the developers merge what changes they have had in -CURRENT that they want to have in the release to the release branch. When this period is over, the code enters a 15 day code freeze in which only bug fixes, documentation updates, security-related fixes and minor device driver changes are allowed. These changes must be approved by the release engineer in advance. At the beginning of the last 15 day period a release candidate is created for widespread testing. Updates are less likely to be allowed during this period, except for important bug fixes and security updates. In this final period, all releases are considered release candidates. At the end of the release process, a release is created with the new version number, including binary distributions on web sites and the creation of CD-ROM images. However, the release is not consider ed "really released" until a <>-signed message stating exactly that, is sent to the mailing list freebsd-announce; anything labelled as a "release" before that may well be in-process and subject to change before the PGP-signed message is sent. footnote:[Many commercial vendors use these images to create CD-ROMs that are sold in retail outlets.]. - -The releases of the -CURRENT-branch (that is, all releases that end with ".0") are very similar, but with twice as long timeframe. It starts 8 weeks prior to the release with announcement of the release time line. Two weeks into the release process, the feature freeze is initiated and performance tweaks should be kept to a minimum. Four weeks prior to the release, an official beta version is made available. Two weeks prior to release, the code is officially branched into a new version. This version is given release candidate status, and as with the release engineering of -STABLE, the code freeze of the release candidate is hardened. However, development on the main development branch can continue. Other than these differences, the release engineering processes are alike. +For releases of the -STABLE-branch, the release process starts 45 days before the anticipated release date. +During the first phase, the first 15 days, the developers merge what changes they have had in -CURRENT that they want to have in the release to the release branch. +When this period is over, the code enters a 15 day code freeze in which only bug fixes, documentation updates, security-related fixes and minor device driver changes are allowed. +These changes must be approved by the release engineer in advance. At the beginning of the last 15 day period a release candidate is created for widespread testing. +Updates are less likely to be allowed during this period, except for important bug fixes and security updates. +In this final period, all releases are considered release candidates. +At the end of the release process, a release is created with the new version number, including binary distributions on web sites and the creation of CD-ROM images. +However, the release is not considered "really released" until a <>-signed message stating exactly that, is sent to the mailing list freebsd-announce; anything labelled as a "release" before that may well be in-process and subject to change before the PGP-signed message is sent. footnote:[Many commercial vendors use these images to create CD-ROMs that are sold in retail outlets.]. + +The releases of the -CURRENT-branch (that is, all releases that end with ".0") are very similar, but with twice as long timeframe. +It starts 8 weeks prior to the release with announcement of the release time line. +Two weeks into the release process, the feature freeze is initiated and performance tweaks should be kept to a minimum. +Four weeks prior to the release, an official beta version is made available. +Two weeks prior to release, the code is officially branched into a new version. +This version is given release candidate status, and as with the release engineering of -STABLE, the code freeze of the release candidate is hardened. +However, development on the main development branch can continue. +Other than these differences, the release engineering processes are alike. *.0 releases go into their own branch and are aimed mainly at early adopters. The branch then goes through a period of stabilisation, and it is not until the <> decides the demands to stability have been satisfied that the branch becomes -STABLE and -CURRENT targets the next major version. While this for the majority has been with *.1 versions, this is not a demand. -Most releases are made when a given date that has been deemed a long enough time since the previous release comes. A target is set for having major releases every 18 months and minor releases every 4 months. The user community has made it very clear that security and stability cannot be sacrificed by self-imposed deadlines and target release dates. For slips of time not to become too long with regards to security and stability issues, extra discipline is required when committing changes to -STABLE. +Most releases are made when a given date that has been deemed a long enough time since the previous release comes. +A target is set for having major releases every 18 months and minor releases every 4 months. +The user community has made it very clear that security and stability cannot be sacrificed by self-imposed deadlines and target release dates. +For slips of time not to become too long with regards to security and stability issues, extra discipline is required when committing changes to -STABLE. . Make release schedule . Feature freeze @@ -764,46 +1007,64 @@ Most releases are made when a given date that has been deemed a long enough time [[tools]] == Tools -The major support tools for supporting the development process are Bugzilla, Mailman, and OpenSSH. These are externally developed tools and are commonly used in the open source world. +The major support tools for supporting the development process are Bugzilla, Mailman, and OpenSSH. +These are externally developed tools and are commonly used in the open source world. [[tool-svn]] === Subversion (SVN) -Subversion ("SVN") is a system to handle multiple versions of text files and tracking who committed what changes and why. A project lives within a "repository" and different versions are considered different "branches". +Subversion ("SVN") is a system to handle multiple versions of text files and tracking who committed what changes and why. +A project lives within a "repository" and different versions are considered different "branches". [[tool-bugzilla]] === Bugzilla -Bugzilla is a maintenance database consisting of a set of tools to track bugs at a central site. It supports the bug tracking process for sending and handling bugs as well as querying and updating the database and editing bug reports. The project uses its web interface to send "Problem Reports" to the project's central Bugzilla server. The committers also have web and command-line clients. +Bugzilla is a maintenance database consisting of a set of tools to track bugs at a central site. +It supports the bug tracking process for sending and handling bugs as well as querying and updating the database and editing bug reports. +The project uses its web interface to send "Problem Reports" to the project's central Bugzilla server. +The committers also have web and command-line clients. [[model-mailman]] === Mailman -Mailman is a program that automates the management of mailing lists. The FreeBSD Project uses it to run 16 general lists, 60 technical lists, 4 limited lists and 5 lists with SVN commit logs. It is also used for many mailing lists set up and used by other people and projects in the FreeBSD community. General lists are lists for the general public, technical lists are mainly for the development of specific areas of interest, and closed lists are for internal communication not intended for the general public. The majority of all the communication in the project goes through these 85 lists [<>, Appendix C]. +Mailman is a program that automates the management of mailing lists. +The FreeBSD Project uses it to run 16 general lists, 60 technical lists, 4 limited lists and 5 lists with SVN commit logs. +It is also used for many mailing lists set up and used by other people and projects in the FreeBSD community. +General lists are lists for the general public, technical lists are mainly for the development of specific areas of interest, and closed lists are for internal communication not intended for the general public. +The majority of all the communication in the project goes through these 85 lists [<>, Appendix C]. [[tool-pgp]] === Pretty Good Privacy -Pretty Good Privacy, better known as PGP, is a cryptosystem using a public key architecture to allow people to digitally sign and/or encrypt information in order to ensure secure communication between two parties. A signature is used when sending information out to many recipients, enabling them to verify that the information has not been tampered with before they received it. In the FreeBSD Project this is the primary means of ensuring that information has been written by the person who claims to have written it, and not altered in transit. +Pretty Good Privacy, better known as PGP, is a cryptosystem using a public key architecture to allow people to digitally sign and/or encrypt information in order to ensure secure communication between two parties. +A signature is used when sending information out to many recipients, enabling them to verify that the information has not been tampered with before they received it. +In the FreeBSD Project this is the primary means of ensuring that information has been written by the person who claims to have written it, and not altered in transit. [[tool-ssh2]] === Secure Shell -Secure Shell is a standard for securely logging into a remote system and for executing commands on the remote system. It allows other connections, called tunnels, to be established and protected between the two involved systems. This standard exists in two primary versions, and only version two is used for the FreeBSD Project. The most common implementation of the standard is OpenSSH that is a part of the project's main distribution. Since its source is updated more often than FreeBSD releases, the latest version is also available in the ports tree. +Secure Shell is a standard for securely logging into a remote system and for executing commands on the remote system. +It allows other connections, called tunnels, to be established and protected between the two involved systems. +This standard exists in two primary versions, and only version two is used for the FreeBSD Project. +The most common implementation of the standard is OpenSSH that is a part of the project's main distribution. +Since its source is updated more often than FreeBSD releases, the latest version is also available in the ports tree. [[sub-projects]] == Sub-projects -Sub-projects are formed to reduce the amount of communication needed to coordinate the group of developers. When a problem area is sufficiently isolated, most communication would be within the group focusing on the problem, requiring less communication with the groups they communicate with than were the group not isolated. +Sub-projects are formed to reduce the amount of communication needed to coordinate the group of developers. +When a problem area is sufficiently isolated, most communication would be within the group focusing on the problem, requiring less communication with the groups they communicate with than were the group not isolated. [[sub-project-ports]] === The Ports Subproject -A "port" is a set of meta-data and patches that are needed to fetch, compile and install correctly an external piece of software on a FreeBSD system. The amount of ports has grown at a tremendous rate, as shown by the following figure. +A "port" is a set of meta-data and patches that are needed to fetch, compile and install correctly an external piece of software on a FreeBSD system. +The amount of ports has grown at a tremendous rate, as shown by the following figure. .Number of ports added between 1996 and 2008 [[fig-ports]] image::portsstatus.png[Refer to tables below for a screen-reader friendly version.] -<> shows the number of ports available to FreeBSD in the period 1995 to 2008. It looks like the curve has first grown exponentially, and then from the middle of 2001 to the middle of 2007 grown linearly at a rate of about 2000 ports/year, before its growth rate gets lower. +<> shows the number of ports available to FreeBSD in the period 1995 to 2008. +It looks like the curve has first grown exponentially, and then from the middle of 2001 to the middle of 2007 grown linearly at a rate of about 2000 ports/year, before its growth rate gets lower. Approximate dates each multiple of 1000 ports is reached @@ -916,30 +1177,40 @@ Approximate number of ports at the start of each year |17900 |=== -As the external software described by the port often is under continued development, the amount of work required to maintain the ports is already large, and increasing. This has led to the ports part of the FreeBSD project gaining a more empowered structure, and is more and more becoming a sub-project of the FreeBSD project. +As the external software described by the port often is under continued development, the amount of work required to maintain the ports is already large, and increasing. +This has led to the ports part of the FreeBSD project gaining a more empowered structure, and is more and more becoming a sub-project of the FreeBSD project. -Ports has its own core team with the <> as its leader, and this team can appoint committers without FreeBSD Core's approval. Unlike in the FreeBSD Project, where a lot of maintenance frequently is rewarded with a commit bit, the ports sub-project contains many active maintainers that are not committers. +Ports has its own core team with the <> as its leader, and this team can appoint committers without FreeBSD Core's approval. +Unlike in the FreeBSD Project, where a lot of maintenance frequently is rewarded with a commit bit, the ports sub-project contains many active maintainers that are not committers. -Unlike the main project, the ports tree is not branched. Every release of FreeBSD follows the current ports collection and has thus available updated information on where to find programs and how to build them. This, however, means that a port that makes dependencies on the system may need to have variations depending on what version of FreeBSD it runs on. +Unlike the main project, the ports tree is not branched. +Every release of FreeBSD follows the current ports collection and has thus available updated information on where to find programs and how to build them. +This, however, means that a port that makes dependencies on the system may need to have variations depending on what version of FreeBSD it runs on. -With an unbranched ports repository it is not possible to guarantee that any port will run on anything other than -CURRENT and -STABLE, in particular older, minor releases. There is neither the infrastructure nor volunteer time needed to guarantee this. +With an unbranched ports repository it is not possible to guarantee that any port will run on anything other than -CURRENT and -STABLE, in particular older, minor releases. +There is neither the infrastructure nor volunteer time needed to guarantee this. For efficiency of communication, teams depending on Ports, such as the release engineering team, have their own ports liaisons. [[sub-project-documentation]] === The FreeBSD Documentation Project -The FreeBSD Documentation project was started January 1995. From the initial group of a project leader, four team leaders and 16 members, they are now a total of 44 committers. The documentation mailing list has just under 300 members, indicating that there is quite a large community around it. +The FreeBSD Documentation project was started January 1995. +From the initial group of a project leader, four team leaders and 16 members, they are now a total of 44 committers. +The documentation mailing list has just under 300 members, indicating that there is quite a large community around it. The goal of the Documentation project is to provide good and useful documentation of the FreeBSD project, thus making it easier for new users to get familiar with the system and detailing advanced features for the users. The main tasks in the Documentation project are to work on current projects in the "FreeBSD Documentation Set", and translate the documentation to other languages. -Like the FreeBSD Project, documentation is split in the same branches. This is done so that there is always an updated version of the documentation for each version. Only documentation errors are corrected in the security branches. +Like the FreeBSD Project, documentation is split in the same branches. +This is done so that there is always an updated version of the documentation for each version. +Only documentation errors are corrected in the security branches. Like the ports sub-project, the Documentation project can appoint documentation committers without FreeBSD Core's approval. [<>]. -The Documentation project has link:{fdp-primer}[a primer]. This is used both to introduce new project members to the standard tools and syntaxes and to act as a reference when working on the project. +The Documentation project has link:{fdp-primer}[a primer]. +This is used both to introduce new project members to the standard tools and syntaxes and to act as a reference when working on the project. :sectnums!: From owner-dev-commits-doc-all@freebsd.org Sun May 23 22:28:38 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B140565084A for ; Sun, 23 May 2021 22:28:38 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FpFP24Rvlz3MFD for ; Sun, 23 May 2021 22:28:38 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1621808918; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dSiI/uxO7yA3ZcHhi5/ixW7zjF5DVA7NmKyndCwTPP0=; b=HcWE+e+kopx1gO2Kzl5VqlfSUy1uXm/k0sVu3h9mhVXI4jr56c28ETcma/HKLHhcQzUf69 rUI+76K27UV8To01V00q+qC5lTkSljbIJpFs7gDRSdHjwVERZN46cB3C5pkKaXVMVGYj7v ABl0c0Dib7f86foocZBRwpBqnTy+cRoikLkM86eOag0q37PytiPo/KEQlvsRurDO6b2kkH PqLTBLKfDojKsVwbwRs6pWmJWJwim7kiywBVjwpKckyQjXzzpuYlpSZk4Oija8/kEEf6cd J1T2eGphCBwIxTYFbK2MzKL3pAQU4bLBn2lVtacTANqdZRCveF6XPQGG40yebw== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 8403A85D6; Sun, 23 May 2021 22:28:38 +0000 (UTC) Date: Mon, 24 May 2021 00:28:38 +0200 From: Daniel Ebdrup Jensen To: dev-commits-doc-all@FreeBSD.org Subject: Re: git: adda9a6066 - main - Link to the new pgpkeys.txt file in articles and books Message-ID: <20210523222838.t2rxbg7tjxv5zllq@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , dev-commits-doc-all@FreeBSD.org References: <202105231934.14NJYq7W016191@gitrepo.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ym3bfzszxavrlmc2" Content-Disposition: inline In-Reply-To: <202105231934.14NJYq7W016191@gitrepo.freebsd.org> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1621808918; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dSiI/uxO7yA3ZcHhi5/ixW7zjF5DVA7NmKyndCwTPP0=; b=ofYuOfFjNCqM6tBfEv4HRKY6LgI+Nneyf3zvug61riG1kmPNLIYbVI/vpVXTKN9MlGM4dp 5wa+sWIW3Xq3haDvunC2FV1x6ASu6866Eobmm4zQeQYBsK5jyBTN34/Kn+TWCv6/7W3VHD aSinqUZVjCT6Oj2MWAG2SB9KY9XTNrOFiY7PBhyPjIDR/6CoNYIBfGrR2qvWzxdIi2zTqq qIDkUQVl75qNI0QWo5N8Y8BK/c9woeSUNzsSPnxHMZc4/bUugCtPl1RYZDy9P+JQDPYPvB nemRWHL7slYmGlNTOBt0tWeOSgVLV5SK/yncW2mnweiKkTNdmiB768gAyHbTuw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1621808918; a=rsa-sha256; cv=none; b=RimaS/OuwcuLrhh4B22ASJIdbhwOgIsc7Slq5llRc3qFxJ3hQw2qcY8b3xlhamsJoT9lqq lXL62vRIosRZ1WH7cpd9I3THI2i72iov/+gQ3ppAdpi4t7TbB1Bdch2U2OslUFpicpzL3z UemJuJ2XKjo1RYEqMQeVvi2vzBbwy9aCMD9oarlIqKsZY2zWrSzTfnYkkkDHSukNsaO2TB LYDbkXdEGVE+x8siVvi/R5Ta7x1+PayRO9AUx5J+3uhbFnIwAzu/GwGoltemkoSfHunJXQ cfFaC75m/9mf7477XUGhYPfKzbFUWcgcUhP8f3uzXcqlURDJre28PuKJY0+m0Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 22:28:38 -0000 --ym3bfzszxavrlmc2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Sun, May 23, 2021 at 07:34:52PM +0000, Sergio Carlavilla Delgado wrote: >The branch main has been updated by carlavilla: > >URL: https://cgit.FreeBSD.org/doc/commit/?id=adda9a606635e898972fe88170ae51c76b02fc02 > >commit adda9a606635e898972fe88170ae51c76b02fc02 >Author: Sergio Carlavilla Delgado >AuthorDate: 2021-05-23 19:33:46 +0000 >Commit: Sergio Carlavilla Delgado >CommitDate: 2021-05-23 19:33:46 +0000 > > Link to the new pgpkeys.txt file in articles and books > > Link in articles and books to the new pgpkeys.txt file > Remove all AsciiDoc syntax in pgpkeys.txt > > PR: 254636 > Submitted by: dinoex@ Hi Sergio, Has the build just not updated yet, or is the file still not working? When I try to view it in my browser, it cuts off mid-key for ashish@ (and the key block is clearly too long to be a real PGP key block unless it contains an entire book as the passphrase). When I try to grab it with fetch on my local machine, fetch on freefall, or curl on a random Linux machine, all report that the file is being truncated (but each download appaers to be truncated at different amounts, which is confusing). Yours, Daniel Ebdrup Jensen --ym3bfzszxavrlmc2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmCq1xZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87oh9Qf/aGgSXAlb+gk0A5cF9cj7xVM6KzYmrcxP6pJaetmJgUrKP4xJ9TepMOt6 qvROKJvOcVJfcjzS0FkcFgUoWTRaGXBIkrXL3Umw+HcxWOIevor8Kz2tx493x0ze PjOQqT2IMCzXBfpT7JgTEsXfBuLIAg1SEE92iY8JI8nbi3uB88b2jFzUFwtz4gNF SQRb0AzFRVuIZpsC8TCkn764wlRUotsiRNJjx6qlv+o86cufn2xZbbYX0Q92qBva B6JlRd+xJN+R9ZEihlydlm0wkbtSX57deoaSL5Y9FUohxLUDr5Jqph2nTxYARnYe htbfN4W5w6qyH58rE5kJM9Kws/l2Xg== =9orP -----END PGP SIGNATURE----- --ym3bfzszxavrlmc2-- From owner-dev-commits-doc-all@freebsd.org Sun May 23 22:33:43 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E36966507DF for ; Sun, 23 May 2021 22:33:43 +0000 (UTC) (envelope-from carlavilla@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FpFVv5tpnz3R03; Sun, 23 May 2021 22:33:43 +0000 (UTC) (envelope-from carlavilla@freebsd.org) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: carlavilla) by smtp.freebsd.org (Postfix) with ESMTPSA id AFC3E8B; Sun, 23 May 2021 22:33:43 +0000 (UTC) (envelope-from carlavilla@freebsd.org) Received: by mail-ed1-f46.google.com with SMTP id t15so29711821edr.11; Sun, 23 May 2021 15:33:43 -0700 (PDT) X-Gm-Message-State: AOAM5328fjDSPlxdi8XrcACMKyBg3DC1G63guIUGmnBrLZK9xp3wjVnG oU7mnFb4h5bb2E8v9lKjALB+BjOZukRbHKFie+g= X-Google-Smtp-Source: ABdhPJwYq7GO6Wqd/z0a9Ja9Mj7qhM+Y/xgyvnvjvB287yogmom8w6SLlZHs1Hw5jKUDN+yxCU8eTP4iN8/8WfLHp+Y= X-Received: by 2002:aa7:d890:: with SMTP id u16mr22535902edq.49.1621809222671; Sun, 23 May 2021 15:33:42 -0700 (PDT) MIME-Version: 1.0 References: <202105231934.14NJYq7W016191@gitrepo.freebsd.org> <20210523222838.t2rxbg7tjxv5zllq@nerd-thinkpad.local> In-Reply-To: <20210523222838.t2rxbg7tjxv5zllq@nerd-thinkpad.local> From: Sergio Carlavilla Date: Mon, 24 May 2021 00:33:31 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: git: adda9a6066 - main - Link to the new pgpkeys.txt file in articles and books To: Daniel Ebdrup Jensen , dev-commits-doc-all@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 22:33:44 -0000 On Mon, 24 May 2021 at 00:28, Daniel Ebdrup Jensen wrote: > > On Sun, May 23, 2021 at 07:34:52PM +0000, Sergio Carlavilla Delgado wrote: > >The branch main has been updated by carlavilla: > > > >URL: https://cgit.FreeBSD.org/doc/commit/?id=adda9a606635e898972fe88170ae51c76b02fc02 > > > >commit adda9a606635e898972fe88170ae51c76b02fc02 > >Author: Sergio Carlavilla Delgado > >AuthorDate: 2021-05-23 19:33:46 +0000 > >Commit: Sergio Carlavilla Delgado > >CommitDate: 2021-05-23 19:33:46 +0000 > > > > Link to the new pgpkeys.txt file in articles and books > > > > Link in articles and books to the new pgpkeys.txt file > > Remove all AsciiDoc syntax in pgpkeys.txt > > > > PR: 254636 > > Submitted by: dinoex@ > > Hi Sergio, > > Has the build just not updated yet, or is the file still not > working? > > When I try to view it in my browser, it cuts off mid-key for > ashish@ (and the key block is clearly too long to be a real PGP key > block unless it contains an entire book as the passphrase). > > When I try to grab it with fetch on my local machine, fetch on > freefall, or curl on a random Linux machine, all report that the > file is being truncated (but each download appaers to be truncated > at different amounts, which is confusing). > > Yours, > Daniel Ebdrup Jensen Hi Daniel, I just downloaded the file using cURL and it works well. Can you try with cURL please? The command: curl https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt --output pgpkeys.txt Bye!