From owner-freebsd-arch@FreeBSD.ORG Sun Jul 1 13:32:55 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8A33106566B for ; Sun, 1 Jul 2012 13:32:55 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7E9178FC17 for ; Sun, 1 Jul 2012 13:32:55 +0000 (UTC) Received: by dadv36 with SMTP id v36so6862741dad.13 for ; Sun, 01 Jul 2012 06:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=T44tSYt/XRiKjXAI3duct3dxhxbYH4oy9Ibp/3h5zmk=; b=k/sfykKoFnskNO5Gi1UyHhm+F7puLj09qCaH602Orns/e4Ihgn4nS4SuJERmEX0+fS akOVHPxPm49UCQy5kwQQ0knAVHv+kDHJhawkyY5hHTPOG4EViOFIQBgeEon1MMHQFpxr /11+F9JFk8AOlPlM6iV8L3o+LH4ij/2mMM5h0uPs+i+MbTbUU9TNG/bqmKFXOXb7Y/2b Np4ay87Kkap+sxVG6h3BzjJaxuCZsA+OqEoKeHltlkRY4Ns2DGjbZ1lM0NXCsXRnFUZk ZcT+KlF5t8YIQNcfPyCN4G350tsbXda2khxwpzcvL9dKF1nVQ7/NTwADWyRgzJQ1fRBK BPMg== MIME-Version: 1.0 Received: by 10.68.190.102 with SMTP id gp6mr22661858pbc.5.1341149575027; Sun, 01 Jul 2012 06:32:55 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.66.82.201 with HTTP; Sun, 1 Jul 2012 06:32:54 -0700 (PDT) Date: Sun, 1 Jul 2012 15:32:54 +0200 X-Google-Sender-Auth: aBsBHF9gL_fAQV53xCd4jrxbg9I Message-ID: From: Davide Italiano To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [RFC/RFT] callout(9): major changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 13:32:55 -0000 Howdy. As part of the Google Summer of Code project, in the last weeks, I worked on some changes in the callout(9) subsystem, under the mentorship of Alexander Motin (mav@). The projects aims to adapt the callout() backend in order to exploit better precision allowed by the recently introducted eventtimers(4/9) subsystem. A patch may be found here: http://people.freebsd.org/~davide/callout_patch.diff If you want to try the code may be found in FreeBSD svn projects/ repository: http://svnweb.freebsd.org/base/projects/calloutng/ At the time of writing, the code cannot be considered ready for hit the tree, some work is still missing, but some goals have been reached. In particular: - The callout(9) backend was completely switched from a tick-based approach to a tickless one. - The code has been integrated with the eventtimers - An experimental new KPI has been introduced so that timeouts for callout_* may be specified also in terms of bintime other than ticks, as previously allowed - Support for execution of callouts from hw interrupt context has been introduced - In order to prove effectiveness of the approach, some consumers (in particular sleep/pool/select) have been ported to the new KPI, and the changes have been microbenchmarked - Some experiments of event aggregation have been done, as well as the definition of new KPI in which consumers may specify granularity at which events may be aggregated. For my benchmarks I used the same program luigi@ has recently used, even though results are a bit different (http://lists.freebsd.org/pipermail/freebsd-arch/2012-February/012413.html). Just a bit of results: Sequential usleep(): This graph shows on the x-axes the timeout se and on y-axes the real sleep time (in the range [1;1000]). Timeout is increased sequentially by one unit every iteration. Green line represents the "ideal" case, Red line represents results after the changes made. http://people.freebsd.org/~davide/sequential_new.png Random sleep(): same as before, but in this case I plotted the delta among the expected sleep time and the actual sleep time. http://people.freebsd.org/~davide/delta_random.png Random select(): http://people.freebsd.org/~davide/delta_random.png I'd like to have some feedback/comments on the implementative choices I've done, as well as on the new defined KPI or future directions. If you've any question, feel free to ask. Davide From owner-freebsd-arch@FreeBSD.ORG Sun Jul 1 16:32:38 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08E2A1065670 for ; Sun, 1 Jul 2012 16:32:38 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D1B758FC0C for ; Sun, 1 Jul 2012 16:32:37 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so7140226pbb.13 for ; Sun, 01 Jul 2012 09:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=91AFT6xXPPD9vcWxW//1Ht6lH/aU5QV7REcC9A/J+gk=; b=BNRd2vtyPrFVGOLA85oIQhVIBOvgFWRXL1MyRBo2/o95uxl4NUTwq84iGChZlp4uyH +zMkdrXHCb4Jt0wNP3DmP7bSlH3dK8ISJqJtRrEpRCRYyCT3ZQQXoAMvn6Y7GjNtqciL sarJUx8m1w1ziraIoUhjWsAvMcl4QacLeD8raftHX3DIdKPohjlUEWyoE27mmikEQ0Kz ibhaHUzFmMxJ8GMtFV1viXn6FEv1sovaATMjHbsCYxVfiffNQr7GB1ybUfTlRXZUtEBN aszRFrxvcwT1crxXTQ6iYd0bi8VQJNmcXIW6+iRnND+HgbliYamE1F0V1xlQQ59qiPSa QUaA== MIME-Version: 1.0 Received: by 10.68.228.102 with SMTP id sh6mr23031334pbc.134.1341160357596; Sun, 01 Jul 2012 09:32:37 -0700 (PDT) Received: by 10.66.82.201 with HTTP; Sun, 1 Jul 2012 09:32:37 -0700 (PDT) In-Reply-To: References: Date: Sun, 1 Jul 2012 18:32:37 +0200 Message-ID: From: Davide Italiano To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [RFC/RFT] callout(9): major changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 16:32:38 -0000 On Sun, Jul 1, 2012 at 3:32 PM, Davide Italiano wrote: > Howdy. > As part of the Google Summer of Code project, in the last weeks, I > worked on some changes in the callout(9) subsystem, under the > mentorship of Alexander Motin (mav@). > The projects aims to adapt the callout() backend in order to exploit > better precision allowed by the recently introducted eventtimers(4/9) > subsystem. > A patch may be found here: http://people.freebsd.org/~davide/callout_patch.diff > If you want to try the code may be found in FreeBSD svn projects/ > repository: http://svnweb.freebsd.org/base/projects/calloutng/ > At the time of writing, the code cannot be considered ready for hit > the tree, some work is still missing, but some goals have been > reached. In particular: > > - The callout(9) backend was completely switched from a tick-based > approach to a tickless one. > - The code has been integrated with the eventtimers > - An experimental new KPI has been introduced so that timeouts for > callout_* may be specified also in terms of bintime other than ticks, > as previously allowed > - Support for execution of callouts from hw interrupt context has been > introduced > - In order to prove effectiveness of the approach, some consumers (in > particular sleep/pool/select) have been ported to the new KPI, and the > changes have been microbenchmarked > - Some experiments of event aggregation have been done, as well as the > definition of new KPI in which consumers may specify granularity at > which events may be aggregated. > > For my benchmarks I used the same program luigi@ has recently used, > even though results are a bit different > (http://lists.freebsd.org/pipermail/freebsd-arch/2012-February/012413.html). > Just a bit of results: > Sequential usleep(): > This graph shows on the x-axes the timeout se and on y-axes the real > sleep time (in the range [1;1000]). Timeout is increased sequentially > by one unit every iteration. Green line represents the "ideal" case, > Red line represents results after the changes made. > http://people.freebsd.org/~davide/sequential_new.png > Random sleep(): > same as before, but in this case I plotted the delta among the > expected sleep time and the actual sleep time. > http://people.freebsd.org/~davide/delta_random.png > Random select(): > http://people.freebsd.org/~davide/delta_random.png Sorry, this is the correct link for random select() results: http://people.freebsd.org/~davide/random_new.png > > I'd like to have some feedback/comments on the implementative choices > I've done, as well as on the new defined KPI or future directions. > If you've any question, feel free to ask. > > Davide Davide From owner-freebsd-arch@FreeBSD.ORG Sun Jul 1 21:12:15 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 498321065678; Sun, 1 Jul 2012 21:12:15 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 231A08FC21; Sun, 1 Jul 2012 21:12:15 +0000 (UTC) Received: from [192.168.2.58] (wifi.xcllnt.net [70.36.220.6] (may be forged)) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q61LC7TY081856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Jul 2012 14:12:11 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120627235945.GE243@lor.one-eyed-alien.net> Date: Sun, 1 Jul 2012 14:12:07 -0700 Content-Transfer-Encoding: 7bit Message-Id: <9BB38D52-3CB9-44CE-B1BD-85DFAD6A1176@xcllnt.net> References: <20120626063017.D05DA58081@chaos.jnpr.net> <86wr2uwdgf.fsf@ds4.des.no> <20120626161605.5082A58081@chaos.jnpr.net> <20120627235945.GE243@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1278) Cc: Tim Kientzle , Dag-Erling Sm?rgrav , freebsd-arch@freebsd.org, "Simon J. Gerraty" Subject: Re: Allow user install X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 21:12:15 -0000 On Jun 27, 2012, at 4:59 PM, Brooks Davis wrote: > On Tue, Jun 26, 2012 at 09:16:05AM -0700, Simon J. Gerraty wrote: >> >> On Tue, 26 Jun 2012 08:18:05 -0700, Tim Kientzle writes: >>> Better idea: have the build write a textual description of the >>> tar entries. That description can then be fed to tar to build >>> the actual tarball. >> >> Yes, that's what we do - manifest files that tar and other tools use to >> produce the install images. >> >>> The description format that tar already supports is a variant >>> mtree format borrowed from NetBSD. Each line specifies >>> the tar entry fields (filename, owner, permissions, etc) and >>> the filename where the file contents are stored. >> >> Yes, we've added that support to makefs - I believe it is already in >> -current. There's still quite a bit to do. > > It's there except that makefs uses the FreeBSD mtree code which doesn't > support the crucial absolute path support in NetBSD's mtree. ? I wrote the code and no, it doesn't use FreeBSD mtree code and yes, it supports absolute pathnames: : cp = strchr(pathspec, '/'); if (cp != NULL) { /* Absolute pathname */ mtree_current = mtree_root; : The code should be compatible with libarchive. Maybe there's a bug? -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Sun Jul 1 21:13:33 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CBD106564A; Sun, 1 Jul 2012 21:13:33 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id C11D98FC16; Sun, 1 Jul 2012 21:13:33 +0000 (UTC) Received: from [192.168.2.58] (wifi.xcllnt.net [70.36.220.6] (may be forged)) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q61LDUVk084654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Jul 2012 14:13:32 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120628182557.GA15593@lor.one-eyed-alien.net> Date: Sun, 1 Jul 2012 14:13:30 -0700 Content-Transfer-Encoding: 7bit Message-Id: <2B2E5252-37AD-4EB1-B31D-E37470E3F31F@xcllnt.net> References: <20120626063017.D05DA58081@chaos.jnpr.net> <86wr2uwdgf.fsf@ds4.des.no> <20120626161605.5082A58081@chaos.jnpr.net> <20120627235945.GE243@lor.one-eyed-alien.net> <52A78E4A-948B-4A79-A95D-0FC7D225BC00@kientzle.com> <20120628182557.GA15593@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1278) Cc: "Simon J. Gerraty" , Tim Kientzle , freebsd-arch@freebsd.org, Dag-Erling Sm?rgrav Subject: Re: Allow user install X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 21:13:34 -0000 On Jun 28, 2012, at 11:25 AM, Brooks Davis wrote: > On Wed, Jun 27, 2012 at 09:12:39PM -0700, Tim Kientzle wrote: >> >> On Jun 27, 2012, at 4:59 PM, Brooks Davis wrote: >> >>> On Tue, Jun 26, 2012 at 09:16:05AM -0700, Simon J. Gerraty wrote: >>>> >>>> On Tue, 26 Jun 2012 08:18:05 -0700, Tim Kientzle writes: >>>>> Better idea: have the build write a textual description of the >>>>> tar entries. That description can then be fed to tar to build >>>>> the actual tarball. >>>> >>>> Yes, that's what we do - manifest files that tar and other tools use to >>>> produce the install images. >>>> >>>>> The description format that tar already supports is a variant >>>>> mtree format borrowed from NetBSD. Each line specifies >>>>> the tar entry fields (filename, owner, permissions, etc) and >>>>> the filename where the file contents are stored. >>>> >>>> Yes, we've added that support to makefs - I believe it is already in >>>> -current. There's still quite a bit to do. >>> >>> It's there except that makefs uses the FreeBSD mtree code which doesn't >>> support the crucial absolute path support in NetBSD's mtree. >> >> If it helps: libarchive can read NetBSD's mtree format. > > I actually found this because I wanted to use libarchive's mtree output > as input to makefs. Can you give me the test case. I did that too and it worked for me. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Mon Jul 2 14:46:05 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69F38106566B; Mon, 2 Jul 2012 14:46:05 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 0F85E8FC18; Mon, 2 Jul 2012 14:46:03 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id q62EYIGp074767; Mon, 2 Jul 2012 09:34:19 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id q62EYICH074766; Mon, 2 Jul 2012 09:34:18 -0500 (CDT) (envelope-from brooks) Date: Mon, 2 Jul 2012 09:34:18 -0500 From: Brooks Davis To: Marcel Moolenaar Message-ID: <20120702143418.GA74604@lor.one-eyed-alien.net> References: <20120626063017.D05DA58081@chaos.jnpr.net> <86wr2uwdgf.fsf@ds4.des.no> <20120626161605.5082A58081@chaos.jnpr.net> <20120627235945.GE243@lor.one-eyed-alien.net> <9BB38D52-3CB9-44CE-B1BD-85DFAD6A1176@xcllnt.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <9BB38D52-3CB9-44CE-B1BD-85DFAD6A1176@xcllnt.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Tim Kientzle , freebsd-arch@freebsd.org, Brooks Davis , Dag-Erling Sm?rgrav , "Simon J. Gerraty" Subject: Re: Allow user install X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 14:46:05 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 01, 2012 at 02:12:07PM -0700, Marcel Moolenaar wrote: >=20 > On Jun 27, 2012, at 4:59 PM, Brooks Davis wrote: >=20 > > On Tue, Jun 26, 2012 at 09:16:05AM -0700, Simon J. Gerraty wrote: > >>=20 > >> On Tue, 26 Jun 2012 08:18:05 -0700, Tim Kientzle writes: > >>> Better idea: have the build write a textual description of the > >>> tar entries. That description can then be fed to tar to build > >>> the actual tarball. > >>=20 > >> Yes, that's what we do - manifest files that tar and other tools use to > >> produce the install images. > >>=20 > >>> The description format that tar already supports is a variant > >>> mtree format borrowed from NetBSD. Each line specifies > >>> the tar entry fields (filename, owner, permissions, etc) and > >>> the filename where the file contents are stored. > >>=20 > >> Yes, we've added that support to makefs - I believe it is already in > >> -current. There's still quite a bit to do. > >=20 > > It's there except that makefs uses the FreeBSD mtree code which doesn't > > support the crucial absolute path support in NetBSD's mtree. >=20 > ? >=20 > I wrote the code and no, it doesn't use FreeBSD mtree code and yes, > it supports absolute pathnames: >=20 > : > cp =3D strchr(pathspec, '/'); =20 > if (cp !=3D NULL) { > /* Absolute pathname */ > mtree_current =3D mtree_root; > =20 > : >=20 > The code should be compatible with libarchive. > Maybe there's a bug? On the first point, two files are used from ../mtree: $ ident makefs | grep mtree $FreeBSD: head/usr.sbin/makefs/mtree.c 223306 2011-06-19 18:34:49Z mar= cel $ $FreeBSD: head/usr.sbin/mtree/misc.c 160083 2006-07-03 10:55:22Z maxim= $ $FreeBSD: head/usr.sbin/mtree/spec.c 229403 2012-01-03 18:51:58Z ed $ Here's the failure: $ mkdir foo $ touch foo/bar $ cd foo $ tar cf ../foo.mtree --format mtree --options mtree:use-set . $ cd .. $ cat foo.mtree #mtree /set type=3Dfile uname=3Dbrooks uid=3D1001 gname=3Dbrooks gid=3D1001 mode= =3D644 =2E time=3D1341239212.0 mode=3D755 type=3Ddir =2E/bar time=3D1341239166.0 size=3D0 =2E/ormat time=3D1341239212.0 size=3D2048 $ makefs -s 1m -F foo.mtree foo.img foo makefs: line 4: slash character in file name and the source of the failure. $ grep "slash character in file name" /usr/src/usr.sbin/mtree/* /usr/src/usr.sbin/mtree/spec.c: errx(1, "line %d: slash character in file= name", -- Brooks --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFP8bFpXY6L6fI4GtQRAtgbAJ0SH8spjZCx26KrQZoQNDFp/7HtDwCgklHm zC01r8uz/OyKrf/3ynqpiuA= =RJV4 -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From owner-freebsd-arch@FreeBSD.ORG Mon Jul 2 14:53:43 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 125E41065670; Mon, 2 Jul 2012 14:53:43 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 975818FC16; Mon, 2 Jul 2012 14:53:42 +0000 (UTC) Received: from dhcp-192-168-2-58.wifi.xcllnt.net (wifi.xcllnt.net [70.36.220.6] (may be forged)) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q62ErXfe004652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Jul 2012 07:53:39 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120702143418.GA74604@lor.one-eyed-alien.net> Date: Mon, 2 Jul 2012 07:53:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <43C6B281-C2DD-429D-AE9E-24A52184C7FA@xcllnt.net> References: <20120626063017.D05DA58081@chaos.jnpr.net> <86wr2uwdgf.fsf@ds4.des.no> <20120626161605.5082A58081@chaos.jnpr.net> <20120627235945.GE243@lor.one-eyed-alien.net> <9BB38D52-3CB9-44CE-B1BD-85DFAD6A1176@xcllnt.net> <20120702143418.GA74604@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1278) Cc: Tim Kientzle , Dag-Erling Sm?rgrav , freebsd-arch@freebsd.org, "Simon J. Gerraty" Subject: Re: Allow user install X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 14:53:43 -0000 On Jul 2, 2012, at 7:34 AM, Brooks Davis wrote: > On Sun, Jul 01, 2012 at 02:12:07PM -0700, Marcel Moolenaar wrote: >>=20 >> On Jun 27, 2012, at 4:59 PM, Brooks Davis wrote: >>=20 >>> On Tue, Jun 26, 2012 at 09:16:05AM -0700, Simon J. Gerraty wrote: >>>>=20 >>>> On Tue, 26 Jun 2012 08:18:05 -0700, Tim Kientzle writes: >>>>> Better idea: have the build write a textual description of the >>>>> tar entries. That description can then be fed to tar to build >>>>> the actual tarball. >>>>=20 >>>> Yes, that's what we do - manifest files that tar and other tools = use to >>>> produce the install images. >>>>=20 >>>>> The description format that tar already supports is a variant >>>>> mtree format borrowed from NetBSD. Each line specifies >>>>> the tar entry fields (filename, owner, permissions, etc) and >>>>> the filename where the file contents are stored. >>>>=20 >>>> Yes, we've added that support to makefs - I believe it is already = in >>>> -current. There's still quite a bit to do. >>>=20 >>> It's there except that makefs uses the FreeBSD mtree code which = doesn't >>> support the crucial absolute path support in NetBSD's mtree. >>=20 >> ? >>=20 >> I wrote the code and no, it doesn't use FreeBSD mtree code and yes, >> it supports absolute pathnames: >>=20 >> : >> cp =3D strchr(pathspec, '/'); =20 >> if (cp !=3D NULL) { >> /* Absolute pathname */ >> mtree_current =3D mtree_root; >>=20 >> : >>=20 >> The code should be compatible with libarchive. >> Maybe there's a bug? >=20 > On the first point, two files are used from ../mtree: >=20 > $ ident makefs | grep mtree > $FreeBSD: head/usr.sbin/makefs/mtree.c 223306 2011-06-19 18:34:49Z = marcel $ > $FreeBSD: head/usr.sbin/mtree/misc.c 160083 2006-07-03 10:55:22Z = maxim $ > $FreeBSD: head/usr.sbin/mtree/spec.c 229403 2012-01-03 18:51:58Z = ed $ >=20 > Here's the failure: >=20 > $ mkdir foo > $ touch foo/bar > $ cd foo > $ tar cf ../foo.mtree --format mtree --options mtree:use-set . > $ cd .. > $ cat foo.mtree > #mtree > /set type=3Dfile uname=3Dbrooks uid=3D1001 gname=3Dbrooks gid=3D1001 = mode=3D644 > . time=3D1341239212.0 mode=3D755 type=3Ddir > ./bar time=3D1341239166.0 size=3D0 > ./ormat time=3D1341239212.0 size=3D2048 > $ makefs -s 1m -F foo.mtree foo.img foo > makefs: line 4: slash character in file name >=20 > and the source of the failure. >=20 > $ grep "slash character in file name" /usr/src/usr.sbin/mtree/* > /usr/src/usr.sbin/mtree/spec.c: errx(1, "line = %d: slash character in file name", >=20 Your invocations is still based on directory scanning and with the -F option you can provide overrides. This is not the mtree support I added -- that eliminates directory scanning and the -F option has no effect. Use as follows: makefs -s 1m foo.img foo.mtree See also man makefs FYI, --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Tue Jul 3 14:46:54 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B6CE106564A; Tue, 3 Jul 2012 14:46:54 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id ECA798FC12; Tue, 3 Jul 2012 14:46:53 +0000 (UTC) Received: from [209.249.190.124] (port=16639 helo=punk.neville-neil.com.neville-neil.com) by vps.hungerhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1Sm4NR-0000pA-Do; Tue, 03 Jul 2012 10:46:53 -0400 Date: Tue, 03 Jul 2012 10:48:19 -0400 Message-ID: <86obnwdhos.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: "David O'Brien" In-Reply-To: <20120703051135.GA69017@dragon.NUXI.org> References: <20120702210438.GA85618@dragon.NUXI.org> <1341270626.1322.YahooMailClassic@web113509.mail.gq1.yahoo.com> <20120703051135.GA69017@dragon.NUXI.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/23.4 (amd64-portbld-freebsd10.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: arch@freebsd.org, Pedro Giffuni Subject: Re: svn commit: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/c... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 14:46:54 -0000 FYI I moved this to arch@ At Mon, 2 Jul 2012 22:11:35 -0700, David O'Brien wrote: > > That may be the case -- but what is the likelihood there would be code > from that effort we would want? Vs. the real brain-share of DTrace > which commits into Illumos? Isn't it much more likely we would want > their innovations? I think that for now a dual tree approach is OK. An extra vendor directory doesn't cost us anything. If opensolaris is ever truly dead to us we can cut the dead branch from our tree. > > I think Martin Matuska did exactly the right thing: > > he created the illumos vendor branch starting from > > the opensolaris branch. > > I don't disagree in principle, but I feel it should have been an > 'svn rename' not 'svn copy'. > > You didn't suggest or comment on the SCM operations having two > "vendors" puts us in. I don't think you can make precise statements > about an illumos vendor branch without considering those. I'm wondering what you're thinking here. I'm not a whiz with our current SCM and I will be dealing with both of these trees so I'd like to know what you're thinking. Also, I am hoping that in the illumos tree we can clean up a few of the things that many people don't like about our opensolaris tree. > > Concerning ZFS: the main developer of the encryption stuff > > did stay at Oracle. At this time that code will not be seen > > in the open (apparently there was a Solaris 11 source leak > > but that's not something we can touch), but we just never > > know. > > We can always figure out something *if* it comes to pass that > there is a code drop from Oracle that we want to consume. > > I believe the question which code base are we *most likely* > to pull technology from. The proof to date in an 'svn log' > of our repo is Illumos. > > > > > Doesn't this commit of yours which brought in new DTrace > > > work by Joyent > > > (likely Brendan Gregg or Bryan Cantrill) show this point? > > > > > > Perhaps we should do an 'svn move' of > > > '^/vendor{,-sys}/opensolaris' > > > to '^/vendor{,-sys}/illumos'? > > > > Illumos is a fork so svn copy works just fine for this, plus > > copying is a very cheap operation in SVN. > > That misses my point. Yes, copying is a very cheap operation in SVN. > (so is 'svn rename') > > The issue is should we have _two_ vendors that we are attempting to > merge into the same files within HEAD? I think that if we can get the illumos tree in shape for 10.x then that will be the main vendor that we draw from, with bugs fixes that wind up in opensolaris as the second ran. I don't see any reason not to draw from both communities, if we can. Best, George From owner-freebsd-arch@FreeBSD.ORG Tue Jul 3 14:48:49 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5CFB106564A; Tue, 3 Jul 2012 14:48:49 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 907C18FC1C; Tue, 3 Jul 2012 14:48:49 +0000 (UTC) Received: from [209.249.190.124] (port=62228 helo=punk.neville-neil.com.neville-neil.com) by vps.hungerhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1Sm4PJ-0001vI-3C; Tue, 03 Jul 2012 10:48:49 -0400 Date: Tue, 03 Jul 2012 10:50:15 -0400 Message-ID: <86mx3gdhlk.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: "David O'Brien" In-Reply-To: <20120702210931.GB85618@dragon.NUXI.org> References: <1340992732.19144.YahooMailClassic@web113501.mail.gq1.yahoo.com> <4FF11659.8060405@FreeBSD.org> <20120702210931.GB85618@dragon.NUXI.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/23.4 (amd64-portbld-freebsd10.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: pfg@FreeBSD.org, arch@freebsd.org, Doug Barton Subject: Re: svn commit: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/c... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 14:48:49 -0000 Again, moving to arch@ At Mon, 2 Jul 2012 14:09:31 -0700, David O'Brien wrote: > > On Sun, Jul 01, 2012 at 08:32:41PM -0700, Doug Barton wrote: > > On 06/29/2012 10:58, Pedro Giffuni wrote: > > > Now .. David pointed out I am not respecting the code > > > provenance since I didn't add them to the opensolaris > > > vendor area, but these files are copyrighted Joyent > > > Inc (not even Illumos) so I cannot put them there > > > unless we create a new vendor for Joyent > > > > Creating a new vendor area would be the right solution, yes. > > I totally disagree -- it will cause a real pain merging. > > Think about it -- if we import a new code drop of uts/common/fs/zfs/*.c into > '^/vendor-sys/illumos', how do we merge that to HEAD? > > I don't believe 'svn merge -c ' will work because we already have a > different uts/common/fs/zfs/*.c from ^/vendor-sys/opensolaris. > > I think we either need to just call Illumos OpenSolaris for these > purposes, or 'svn move opensolaris illumos'. > > I think this needs to be discussed with the Repo Meisters. I actually agree with Doug here, but not strongly, I'd prefer to be better educated about this topic. Do our Repo Meisters read arch@? Best, George From owner-freebsd-arch@FreeBSD.ORG Tue Jul 3 14:55:19 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB8521065673 for ; Tue, 3 Jul 2012 14:55:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6CCCB8FC17 for ; Tue, 3 Jul 2012 14:55:19 +0000 (UTC) Received: by yenl8 with SMTP id l8so6338090yen.13 for ; Tue, 03 Jul 2012 07:55:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=8BM6rl1jlQ/IHmdK4/lYQoEIktjkHxpq1Ia4MUf++cw=; b=LrpgUKrE70GjUUYhAl1a53ZD9scqDjrPiVcCKQaXGmvLvtnq+7dCsuKTD2pDADdoPY jHHr33kiCCXEoump5lHrq6hUg8pPhiYfMbzSlQtRZAYBbm+sYtbxK0vxs6IJgd8T/2F7 7HnOn2IRU8/F9Wj4EzNnaIoJuOVgS4Q4UVbtcG1ur6/2mSF7/WhtKO1MymbwhIGsPQ6i QrghYDsAsnWqimKArEJa09IDesyHEaQjOij2ZkpYjIMm96UORkoFUkaIajRag+yQP81N Z0Kj6djx3OrGuBNsB8zGx9ewOc/0LiUKSLQKJuO8nuo15DeZP2QBKtcA8TRzMKm5FNZ6 aoLg== Received: by 10.68.203.73 with SMTP id ko9mr7859360pbc.66.1341327318506; Tue, 03 Jul 2012 07:55:18 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ns5sm15716720pbb.26.2012.07.03.07.55.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jul 2012 07:55:18 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <86mx3gdhlk.wl%gnn@neville-neil.com> Date: Tue, 3 Jul 2012 08:55:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1340992732.19144.YahooMailClassic@web113501.mail.gq1.yahoo.com> <4FF11659.8060405@FreeBSD.org> <20120702210931.GB85618@dragon.NUXI.org> <86mx3gdhlk.wl%gnn@neville-neil.com> To: gnn@freebsd.org X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlSF7mx8o5ZhcAdXq9lN3JR+KNBIIpAxA9xIOcfVzvKnZaM/W/ymWTdqfkl2PbIggAxu1cS Cc: Doug Barton , arch@freebsd.org, pfg@FreeBSD.org, David O'Brien Subject: Re: svn commit: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/c... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 14:55:19 -0000 On Jul 3, 2012, at 8:50 AM, gnn@freebsd.org wrote: > Again, moving to arch@ >=20 > At Mon, 2 Jul 2012 14:09:31 -0700, > David O'Brien wrote: >>=20 >> On Sun, Jul 01, 2012 at 08:32:41PM -0700, Doug Barton wrote: >>> On 06/29/2012 10:58, Pedro Giffuni wrote: >>>> Now .. David pointed out I am not respecting the code >>>> provenance since I didn't add them to the opensolaris >>>> vendor area, but these files are copyrighted Joyent >>>> Inc (not even Illumos) so I cannot put them there >>>> unless we create a new vendor for Joyent >>>=20 >>> Creating a new vendor area would be the right solution, yes. >>=20 >> I totally disagree -- it will cause a real pain merging. >>=20 >> Think about it -- if we import a new code drop of = uts/common/fs/zfs/*.c into >> '^/vendor-sys/illumos', how do we merge that to HEAD? >>=20 >> I don't believe 'svn merge -c ' will work because we already = have a >> different uts/common/fs/zfs/*.c from ^/vendor-sys/opensolaris. >>=20 >> I think we either need to just call Illumos OpenSolaris for these >> purposes, or 'svn move opensolaris illumos'. >>=20 >> I think this needs to be discussed with the Repo Meisters. >=20 > I actually agree with Doug here, but not strongly, I'd prefer to be > better educated about this topic. Do our Repo Meisters read arch@? I agree with Doug as well. I think that transitioning from one vendor = tree to the other is the right thing to do. Unless we have good, = concrete reasons not to do this, I think the default assumption should = be this is a good idea. I believe that svn merge -c XXX will work because of how mergenotes = work, but I'd appreciate confirmation from our repo masters. I think that having the two different sources is a good thing, should = OpenSolaris ever come back to live and be a viable source of imports. = We need to keep that option open, unless doing so has a real, = demonstrable harm. Warner= From owner-freebsd-arch@FreeBSD.ORG Tue Jul 3 15:09:42 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8BEA106564A for ; Tue, 3 Jul 2012 15:09:42 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm16-vm0.bullet.mail.sp2.yahoo.com (nm16-vm0.bullet.mail.sp2.yahoo.com [98.139.91.210]) by mx1.freebsd.org (Postfix) with SMTP id 335CA8FC15 for ; Tue, 3 Jul 2012 15:09:42 +0000 (UTC) Received: from [72.30.22.78] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jul 2012 15:09:36 -0000 Received: from [98.139.91.3] by tm12.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jul 2012 15:09:36 -0000 Received: from [127.0.0.1] by omp1003.mail.sp2.yahoo.com with NNFMP; 03 Jul 2012 15:09:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 548537.32269.bm@omp1003.mail.sp2.yahoo.com Received: (qmail 91984 invoked by uid 60001); 3 Jul 2012 15:09:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1341328176; bh=2/9bjUDRn/4G8ZEAd1Ay0G0zi5PcMvgKo8lJyv54Lnk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=T/kPXO/uV5r2JiepoXrrWbi3YDErOz+ptUzyuscVdB/d7ZEsv9jF5/LIy5EdkobQlhgyaBgxcfS6ibf0FuMLus8UmvzVeEkXTHPFRj875JxVu01zw4Uk2Y0SdmbSSjxXt2u4HhjaqGor9th8yLlVV9hbU8ri8ZVAzjW3c6d62dk= X-YMail-OSG: wr2WtuYVM1kLmwxhxMF7K2p22N39jxH6LpWL0qsUqkbAwEt CtGwUGf3xkQ50gA3Z2Roe.UbcQkdOStkmNMQ0HhffPCMPgziDlP4UUTfn0.U 72QojLpF93KsNsCxTB59odWuNDPwRmP7GkoO3y8yVMOQDW.p5ieNyw51tpvW fZ6Tad9slC62ozpIEu1SBR_QQGrb9CTBlhzE5xLSAvBOlzU5mLrvHpcpHOVA 9mvlbhg.49IChMyGATzvknvK4PEiiqn5qpdYATgAlY1pOB.kXvkR9dtEiVlJ jNQnfJ5YbD4FkcYxLqqjwpBO9VY04mhj5JvBIIOC_OCf.CULAND7694p4TOo olTSyPADfdOsyv314PT8PhR8uQeecp1af3wG.fNXaNx9baqoW4yT3WEF_3qU s5XvC8zeN5SUiKYFhWzXQGOYNrVeH1ok8okuKt8dZ3tznaYDg.Hp.FsTwF.R vrsPt Received: from [200.118.157.7] by web113519.mail.gq1.yahoo.com via HTTP; Tue, 03 Jul 2012 08:09:35 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.118.349524 Message-ID: <1341328175.90641.YahooMailClassic@web113519.mail.gq1.yahoo.com> Date: Tue, 3 Jul 2012 08:09:35 -0700 (PDT) From: Pedro Giffuni To: David O'Brien , gnn@freebsd.org In-Reply-To: <86mx3gdhlk.wl%gnn@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, Doug Barton Subject: Re: svn commit: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/c... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfg@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:09:42 -0000 =0A=0A--- Mar 3/7/12, gnn@freebsd.org ha scritto:=0A...= =0A> Again, moving to arch@=0A> =0A> At Mon, 2 Jul 2012 14:09:31 -0700,=0A>= David O'Brien wrote:=0A> > =0A> > On Sun, Jul 01, 2012 at 08:32:41PM -0700= , Doug Barton=0A> wrote:=0A> > > On 06/29/2012 10:58, Pedro Giffuni wrote:= =0A> > > > Now .. David pointed out I am not respecting the code=0A> > > > = provenance since I didn't add them to the opensolaris=0A> > > > vendor area= , but these files are copyrighted Joyent=0A> > > > Inc (not even Illumos) s= o I cannot put them there=0A> > > > unless we create a new vendor for Joyen= t=0A> > > =0A> > > Creating a new vendor area would be the right solution, = yes.=0A> > =0A> > I totally disagree -- it will cause a real pain merging.= =0A> > =0A=0AThe idea was to keep in order the code provenance issue.=0AIll= umos is not a vendor: the changes are copyrighted=0Aindividually by Nexenta= , Joyent, Delphix and others=0Aand if we want to track IP property for what= ever reason=0Ait's convenient to have it separate from the OpenSolaris=0Ast= uff.=0A=0AConcerning the multiple vendor issue if time proves that=0Aopenso= laris is dead then we don't have a problem and we=0Acan just drop that bran= ch. I suspect that if OpenSolaris=0Asomehow resurrects Illumos will have to= deal with it too.=0A(so yes, I guess I am starting to agree with David).= =0A=0A> > Think about it -- if we import a new code drop of=0A> > uts/commo= n/fs/zfs/*.c into=0A> > '^/vendor-sys/illumos', how do we merge that to HEA= D?=0A> > =0A> > I don't believe 'svn merge -c ' will work=0A> > becaus= e we already have a=0A> > different uts/common/fs/zfs/*.c from ^/vendor-sys= /opensolaris.=0A> > =0A> > I think we either need to just call Illumos Open= Solaris for these=0A> > purposes, or 'svn move opensolaris illumos'.=0A> > = =0A> > I think this needs to be discussed with the Repo Meisters.=0A> =0A> = I actually agree with Doug here, but not strongly, I'd prefer to be=0A> bet= ter educated about this topic.=A0 Do our Repo Meisters=0A> read arch@?=0A> = =0A=0ADoing a copy we preserve the opensolaris branch information,=0Adoing = a rename we can always branch a new opensolaris again=0Afrom a specific rev= ision if we want to.=0A=0AFWIW, I think it's actually the same to do a copy= or a rename,=0Abut I guess I can be re-educated too.=0A=0AThe "svn copy" w= as already done though so I wonder if=0Areworking it is really necessary.= =0A=0APedro. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 3 15:27:39 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F5B9106564A; Tue, 3 Jul 2012 15:27:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id F1D098FC08; Tue, 3 Jul 2012 15:27:38 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6C030B985; Tue, 3 Jul 2012 11:27:38 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 3 Jul 2012 11:27:37 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <1340992732.19144.YahooMailClassic@web113501.mail.gq1.yahoo.com> <86mx3gdhlk.wl%gnn@neville-neil.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207031127.37765.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jul 2012 11:27:38 -0400 (EDT) Cc: Doug Barton , arch@freebsd.org, gnn@freebsd.org, pfg@freebsd.org Subject: Re: svn commit: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/c... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:27:39 -0000 On Tuesday, July 03, 2012 10:55:11 AM Warner Losh wrote: > On Jul 3, 2012, at 8:50 AM, gnn@freebsd.org wrote: > > Again, moving to arch@ > > > > At Mon, 2 Jul 2012 14:09:31 -0700, > > > > David O'Brien wrote: > >> On Sun, Jul 01, 2012 at 08:32:41PM -0700, Doug Barton wrote: > >>> On 06/29/2012 10:58, Pedro Giffuni wrote: > >>>> Now .. David pointed out I am not respecting the code > >>>> provenance since I didn't add them to the opensolaris > >>>> vendor area, but these files are copyrighted Joyent > >>>> Inc (not even Illumos) so I cannot put them there > >>>> unless we create a new vendor for Joyent > >>> > >>> Creating a new vendor area would be the right solution, yes. > >> > >> I totally disagree -- it will cause a real pain merging. > >> > >> Think about it -- if we import a new code drop of uts/common/fs/zfs/*.c > >> into '^/vendor-sys/illumos', how do we merge that to HEAD? > >> > >> I don't believe 'svn merge -c ' will work because we already have a > >> different uts/common/fs/zfs/*.c from ^/vendor-sys/opensolaris. > >> > >> I think we either need to just call Illumos OpenSolaris for these > >> purposes, or 'svn move opensolaris illumos'. > >> > >> I think this needs to be discussed with the Repo Meisters. > > > > I actually agree with Doug here, but not strongly, I'd prefer to be > > better educated about this topic. Do our Repo Meisters read arch@? > > I agree with Doug as well. I think that transitioning from one vendor tree > to the other is the right thing to do. Unless we have good, concrete > reasons not to do this, I think the default assumption should be this is a > good idea. > > I believe that svn merge -c XXX will work because of how mergenotes work, > but I'd appreciate confirmation from our repo masters. I believe this will work fine. svn merge is a bit of a glorified "diff | patch" so it just extracts the diff for change XXX and applies it (but with some extra checking with mergeinfo to see if XXX is already applied). I believe you could even do "normal" vendor merges (no -c XXX arg) from both places (though you might have to resolve conflicts), and svn will just maintain two pieces of mergeinfo, one for each source. Given that, I think it would be premature to remove the opensolaris vendor area, but that doing a copy and leaving both vendor areas available is appropriate for now. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jul 3 15:27:39 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F5B9106564A; Tue, 3 Jul 2012 15:27:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id F1D098FC08; Tue, 3 Jul 2012 15:27:38 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6C030B985; Tue, 3 Jul 2012 11:27:38 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 3 Jul 2012 11:27:37 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <1340992732.19144.YahooMailClassic@web113501.mail.gq1.yahoo.com> <86mx3gdhlk.wl%gnn@neville-neil.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207031127.37765.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jul 2012 11:27:38 -0400 (EDT) Cc: Doug Barton , arch@freebsd.org, gnn@freebsd.org, pfg@freebsd.org Subject: Re: svn commit: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/c... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:27:39 -0000 On Tuesday, July 03, 2012 10:55:11 AM Warner Losh wrote: > On Jul 3, 2012, at 8:50 AM, gnn@freebsd.org wrote: > > Again, moving to arch@ > > > > At Mon, 2 Jul 2012 14:09:31 -0700, > > > > David O'Brien wrote: > >> On Sun, Jul 01, 2012 at 08:32:41PM -0700, Doug Barton wrote: > >>> On 06/29/2012 10:58, Pedro Giffuni wrote: > >>>> Now .. David pointed out I am not respecting the code > >>>> provenance since I didn't add them to the opensolaris > >>>> vendor area, but these files are copyrighted Joyent > >>>> Inc (not even Illumos) so I cannot put them there > >>>> unless we create a new vendor for Joyent > >>> > >>> Creating a new vendor area would be the right solution, yes. > >> > >> I totally disagree -- it will cause a real pain merging. > >> > >> Think about it -- if we import a new code drop of uts/common/fs/zfs/*.c > >> into '^/vendor-sys/illumos', how do we merge that to HEAD? > >> > >> I don't believe 'svn merge -c ' will work because we already have a > >> different uts/common/fs/zfs/*.c from ^/vendor-sys/opensolaris. > >> > >> I think we either need to just call Illumos OpenSolaris for these > >> purposes, or 'svn move opensolaris illumos'. > >> > >> I think this needs to be discussed with the Repo Meisters. > > > > I actually agree with Doug here, but not strongly, I'd prefer to be > > better educated about this topic. Do our Repo Meisters read arch@? > > I agree with Doug as well. I think that transitioning from one vendor tree > to the other is the right thing to do. Unless we have good, concrete > reasons not to do this, I think the default assumption should be this is a > good idea. > > I believe that svn merge -c XXX will work because of how mergenotes work, > but I'd appreciate confirmation from our repo masters. I believe this will work fine. svn merge is a bit of a glorified "diff | patch" so it just extracts the diff for change XXX and applies it (but with some extra checking with mergeinfo to see if XXX is already applied). I believe you could even do "normal" vendor merges (no -c XXX arg) from both places (though you might have to resolve conflicts), and svn will just maintain two pieces of mergeinfo, one for each source. Given that, I think it would be premature to remove the opensolaris vendor area, but that doing a copy and leaving both vendor areas available is appropriate for now. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jul 3 18:21:21 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C745106566C; Tue, 3 Jul 2012 18:21:21 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5CB348FC0A; Tue, 3 Jul 2012 18:21:21 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id q63ILJnZ076611; Tue, 3 Jul 2012 11:21:19 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.5/Submit) id q63ILJwM076608; Tue, 3 Jul 2012 11:21:19 -0700 (PDT) (envelope-from obrien) Date: Tue, 3 Jul 2012 11:21:19 -0700 From: "David O'Brien" To: Warner Losh Message-ID: <20120703182118.GA70183@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Warner Losh , gnn@freebsd.org, pfg@FreeBSD.org, arch@freebsd.org, Doug Barton References: <1340992732.19144.YahooMailClassic@web113501.mail.gq1.yahoo.com> <4FF11659.8060405@FreeBSD.org> <20120702210931.GB85618@dragon.NUXI.org> <86mx3gdhlk.wl%gnn@neville-neil.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: gnn@freebsd.org, pfg@freebsd.org, Doug Barton , arch@freebsd.org Subject: Re: svn commit: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/c... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 18:21:21 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 03, 2012 at 08:55:11AM -0600, Warner Losh wrote: > On Jul 3, 2012, at 8:50 AM, gnn@freebsd.org wrote: > > At Mon, 2 Jul 2012 14:09:31 -0700, David O'Brien wrote: > >> On Sun, Jul 01, 2012 at 08:32:41PM -0700, Doug Barton wrote: > >>> On 06/29/2012 10:58, Pedro Giffuni wrote: > >>>> Now .. David pointed out I am not respecting the code > >>>> provenance since I didn't add them to the opensolaris > >>>> vendor area, but these files are copyrighted Joyent > >>>> Inc (not even Illumos) so I cannot put them there > >>>> unless we create a new vendor for Joyent > >>> > >>> Creating a new vendor area would be the right solution, yes. > >> > >> I totally disagree -- it will cause a real pain merging. ... > > I actually agree with Doug here, but not strongly, I'd prefer to be > > better educated about this topic. Do our Repo Meisters read arch@? > > I agree with Doug as well. I think that transitioning from one vendor > tree to the other is the right thing to do. Unless we have good, > concrete reasons not to do this, I think the default assumption should > be this is a good idea. FYI, When I disagreed with Doug it was for a "new" vendor tree vs. a renamed (moved) one. In other words I disagree with having two vendor trees. > I believe that svn merge -c XXX will work because of how mergenotes > work, but I'd appreciate confirmation from our repo masters. Please see below. I'm almost sure it will not work in what would be likely situation. I expect 'svn merge -c' will likely have svn telling you it cannot find the previous revision. > I think that having the two different sources is a good thing, should > OpenSolaris ever come back to live and be a viable source of imports. > We need to keep that option open, We're never totally shut off from any option. Even if we 'svn delete vendor/opensolaris' and then later want to do an import from Oracle, we (or Repo Meisters) can resurrect it in the manner that is best for that time. But leaving vendor/opensolaris alive now, makes it too easy for someone to import there that isn't aware of the issues. > unless doing so has a real, demonstrable harm. I set up a test repository to show what I am concerned of. I used Figlet (/usr/ports/misc/figlet) as it had a fork when the original author moved on. I then did an import as if the original author returned to his own line of figlet. Roughly: 1. Import figlet 2.2.1 into vendor/figlet 2. Merge 2.2.1 to head/contrib/figlet 3. Import figlet 2.2.2 into vendor/figlet 4. Merge 2.2.2 to head/contrib/figlet 5. Copy vendor/figlet to vendor/figlet-NG [fork] 6. Import figlet 2.2.3 into vendor/figlet-NG 7. Merge 2.2.3 to head/contrib/figlet 8. Import figlet 2.2.4 into vendor/figlet [return of original author] 9. Merge 2.2.4 to head/contrib/figlet This lead to Summary of conflicts: Text conflicts: 6 Tree conflicts: 6 Which is the problem -- what do you do with the tree conflicts? Tree conflicts are quite different from the usual textual conflicts. Please see http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html Note the examples there are more simplistic than our situation. When the 2nd vendor does an new release and it is merged in, you'll get another set of tree conflicts. One thing to keep in mind with SCM's more advanced than CVS is objects are not the same just because their file names are the same. An object has a clear ancestry. Just because I am "David O'Brien", doesn't mean another "David O'Brien" of a different mother is just a newer version of me. One way to deal with this is to use "merge --ignore-ancestry". Please see http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.ancestry which directly talks to our situation. But, I really don't think we want to use --ignore-ancestry. Per the docs, it disables merge tracking (svn:mergeinfo is not considered when svn merge is determining what revisions to merge, nor is svn:mergeinfo recorded to describe the merge). It turns the 'svn merge' into a more textual 3-way diff + patch. And even if we were OK with this, we would have a very hard time documenting and getting the word out to everyone that should know about it. (i.e., every committer that ever wants to bring in new Solaris-family technologies) The other way is essentially to 'svn delete' the tree conflicts in head/vendor/figlet before doing the merge and let the merge put in files of a totally different ancestry. Then when the same tree conflicts occur again when importing from the other vendor we do the same. So we wind up with a ping-pong of ancestry and one cannot readily read the commit history of these files. Also note the textual conflicts where there should have been zero -- I made no text changes within head/contrib/figlet. I'll attach the set of commands and the 'script out sh -x' run of that so folks can first-hand test this. -- -- David (obrien@FreeBSD.org) --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=two-vendor-treeconflict-cmds mkdir /usr/obj/tmp svnadmin create /usr/obj/tmp/TEST-repo export R='file:///usr/obj/tmp/TEST-repo' svn co $R TEST cd TEST mkdir -p head/contrib vendor/figlet svn add * svn ci -m 'set up basic dirs' tar xf /usr/ports/distfiles/figlet221.tar.gz svn import -m 'Import Figlet version 2.2.1' figlet221 $R/vendor/figlet/dist svn copy -m 'Tag the Figlet 2.2.1 import' $R/vendor/figlet/dist $R/vendor/figlet/2.2.1 svn copy -m 'Copy import to HEAD' $R/vendor/figlet/dist $R/head/contrib/figlet svn up tar xf /usr/ports/distfiles/figlet222.tar.gz svn-vendorimport.sh figlet222 vendor/figlet/dist svn ci -m 'Import Figlet version 2.2.2' vendor/figlet/dist svn copy -m 'Tag the Figlet 2.2.2 import' $R/vendor/figlet/dist $R/vendor/figlet/2.2.2 svn up svn merge ^/vendor/figlet/dist head/contrib/figlet svn ci -m 'Merge Figlet 2.2.2 to HEAD' head ############ NEW VENDOR ################### svn copy -m 'The New Gen folks took over Figlet' $R/vendor/figlet $R/vendor/figlet-NG svn up tar xf /usr/ports/distfiles/figlet-2.2.3.tar.gz svn-vendorimport.sh figlet-2.2.3 vendor/figlet-NG/dist svn ci -m 'Import Figlet NG version 2.2.3' vendor/figlet-NG svn copy -m 'Tag the Figlet NG 2.2.3 import' $R/vendor/figlet-NG/dist $R/vendor/figlet-NG/2.2.2 svn up svn merge ^/vendor/figlet-NG/dist head/contrib/figlet svn ci -m 'Merge Figlet 2.2.3 to HEAD' head svn up ############ BACK TO OLD VENDOR ################### tar xf /usr/ports/distfiles/figlet-2.2.4.tar.gz svn-vendorimport.sh figlet-2.2.4 vendor/figlet/dist svn ci -m 'Import Figlet version 2.2.4 (Author returns!)' vendor/figlet svn copy -m 'Tag the Figlet 2.2.4 (Author returns!) import' $R/vendor/figlet/dist $R/vendor/figlet/2.2.4 svn merge ^/vendor/figlet/dist head/contrib/figlet --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="typescript.two-vendor-treeconflict-cmds" Script started on Tue Jul 3 11:18:55 2012 sh -x /tmp/two-vendor-treeconflict-cmds + mkdir /usr/obj/tmp mkdir: /usr/obj/tmp: File exists + svnadmin create /usr/obj/tmp/TEST-repo + export R=file:///usr/obj/tmp/TEST-repo + svn co file:///usr/obj/tmp/TEST-repo TEST Checked out revision 0. + cd TEST + mkdir -p head/contrib vendor/figlet + svn add head vendor A head A head/contrib A vendor A vendor/figlet + svn ci -m 'set up basic dirs' Adding head Adding head/contrib Adding vendor Adding vendor/figlet Committed revision 1. + tar xf /usr/ports/distfiles/figlet221.tar.gz + svn import -m 'Import Figlet version 2.2.1' figlet221 file:///usr/obj/tmp/TEST-repo/vendor/figlet/dist Adding figlet221/showfigfonts Adding figlet221/Artistic-license.txt Adding figlet221/zipio.h Adding figlet221/getopt.c Adding figlet221/crc.c Adding figlet221/fonts Adding figlet221/fonts/hz.flc Adding figlet221/fonts/slant.flf Adding figlet221/fonts/smslant.flf Adding figlet221/fonts/ushebrew.flc Adding figlet221/fonts/646-fr.flc Adding figlet221/fonts/utf8.flc Adding figlet221/fonts/646-jp.flc Adding figlet221/fonts/shadow.flf Adding figlet221/fonts/jis0201.flc Adding figlet221/fonts/smshadow.flf Adding figlet221/fonts/646-hu.flc Adding figlet221/fonts/646-no.flc Adding figlet221/fonts/block.flf Adding (bin) figlet221/fonts/bubble.flf Adding figlet221/fonts/646-ca.flc Adding figlet221/fonts/646-pt.flc Adding figlet221/fonts/646-gb.flc Adding figlet221/fonts/script.flf Adding figlet221/fonts/moscow.flc Adding figlet221/fonts/smscript.flf Adding (bin) figlet221/fonts/term.flf Adding figlet221/fonts/small.flf Adding figlet221/fonts/frango.flc Adding figlet221/fonts/8859-2.flc Adding figlet221/fonts/646-cn.flc Adding figlet221/fonts/646-irv.flc Adding figlet221/fonts/8859-3.flc Adding figlet221/fonts/8859-4.flc Adding figlet221/fonts/8859-5.flc Adding (bin) figlet221/fonts/digital.flf Adding figlet221/fonts/8859-7.flc Adding figlet221/fonts/lean.flf Adding figlet221/fonts/8859-8.flc Adding figlet221/fonts/646-ca2.flc Adding figlet221/fonts/646-pt2.flc Adding figlet221/fonts/8859-9.flc Adding figlet221/fonts/646-cu.flc Adding figlet221/fonts/646-es.flc Adding figlet221/fonts/646-se.flc Adding figlet221/fonts/uskata.flc Adding figlet221/fonts/646-it.flc Adding figlet221/fonts/646-kr.flc Adding figlet221/fonts/upper.flc Adding figlet221/fonts/koi8r.flc Adding figlet221/fonts/mini.flf Adding figlet221/fonts/ivrit.flf Adding figlet221/fonts/ilhebrew.flc Adding figlet221/fonts/standard.flf Adding figlet221/fonts/big.flf Adding figlet221/fonts/646-de.flc Adding figlet221/fonts/646-es2.flc Adding figlet221/fonts/646-se2.flc Adding figlet221/fonts/mnemonic.flf Adding figlet221/fonts/banner.flf Adding figlet221/fonts/646-yu.flc Adding figlet221/fonts/646-dk.flc Adding figlet221/fonts/646-no2.flc Adding figlet221/figlet.c Adding figlet221/crc.h Adding figlet221/README Adding figlet221/figlist Adding figlet221/inflate.c Adding figlet221/figmagic Adding figlet221/FAQ Adding figlet221/CHANGES Adding figlet221/inflate.h Adding figlet221/figfont.txt Adding figlet221/zipio.c Adding figlet221/Makefile Adding figlet221/chkfont.c Adding figlet221/figlet.6 Committed revision 2. + svn copy -m 'Tag the Figlet 2.2.1 import' file:///usr/obj/tmp/TEST-repo/vendor/figlet/dist file:///usr/obj/tmp/TEST-repo/vendor/figlet/2.2.1 Committed revision 3. + svn copy -m 'Copy import to HEAD' file:///usr/obj/tmp/TEST-repo/vendor/figlet/dist file:///usr/obj/tmp/TEST-repo/head/contrib/figlet Committed revision 4. + svn up Updating '.': A head/contrib/figlet A head/contrib/figlet/zipio.h A head/contrib/figlet/showfigfonts A head/contrib/figlet/Artistic-license.txt A head/contrib/figlet/getopt.c A head/contrib/figlet/crc.c A head/contrib/figlet/fonts A head/contrib/figlet/fonts/hz.flc A head/contrib/figlet/fonts/646-fr.flc A head/contrib/figlet/fonts/slant.flf A head/contrib/figlet/fonts/smslant.flf A head/contrib/figlet/fonts/ushebrew.flc A head/contrib/figlet/fonts/646-jp.flc A head/contrib/figlet/fonts/utf8.flc A head/contrib/figlet/fonts/jis0201.flc A head/contrib/figlet/fonts/shadow.flf A head/contrib/figlet/fonts/smshadow.flf A head/contrib/figlet/fonts/646-hu.flc A head/contrib/figlet/fonts/646-no.flc A head/contrib/figlet/fonts/block.flf A head/contrib/figlet/fonts/bubble.flf A head/contrib/figlet/fonts/646-pt.flc A head/contrib/figlet/fonts/646-ca.flc A head/contrib/figlet/fonts/646-gb.flc A head/contrib/figlet/fonts/smscript.flf A head/contrib/figlet/fonts/script.flf A head/contrib/figlet/fonts/moscow.flc A head/contrib/figlet/fonts/term.flf A head/contrib/figlet/fonts/small.flf A head/contrib/figlet/fonts/frango.flc A head/contrib/figlet/fonts/8859-2.flc A head/contrib/figlet/fonts/646-irv.flc A head/contrib/figlet/fonts/646-cn.flc A head/contrib/figlet/fonts/8859-3.flc A head/contrib/figlet/fonts/8859-4.flc A head/contrib/figlet/fonts/8859-5.flc A head/contrib/figlet/fonts/digital.flf A head/contrib/figlet/fonts/8859-7.flc A head/contrib/figlet/fonts/8859-8.flc A head/contrib/figlet/fonts/646-pt2.flc A head/contrib/figlet/fonts/646-ca2.flc A head/contrib/figlet/fonts/lean.flf A head/contrib/figlet/fonts/8859-9.flc A head/contrib/figlet/fonts/646-se.flc A head/contrib/figlet/fonts/646-cu.flc A head/contrib/figlet/fonts/646-es.flc A head/contrib/figlet/fonts/uskata.flc A head/contrib/figlet/fonts/646-it.flc A head/contrib/figlet/fonts/646-kr.flc A head/contrib/figlet/fonts/upper.flc A head/contrib/figlet/fonts/koi8r.flc A head/contrib/figlet/fonts/mini.flf A head/contrib/figlet/fonts/ivrit.flf A head/contrib/figlet/fonts/ilhebrew.flc A head/contrib/figlet/fonts/standard.flf A head/contrib/figlet/fonts/big.flf A head/contrib/figlet/fonts/646-de.flc A head/contrib/figlet/fonts/646-se2.flc A head/contrib/figlet/fonts/646-es2.flc A head/contrib/figlet/fonts/banner.flf A head/contrib/figlet/fonts/mnemonic.flf A head/contrib/figlet/fonts/646-yu.flc A head/contrib/figlet/fonts/646-no2.flc A head/contrib/figlet/fonts/646-dk.flc A head/contrib/figlet/figlet.c A head/contrib/figlet/README A head/contrib/figlet/crc.h A head/contrib/figlet/figlist A head/contrib/figlet/inflate.c A head/contrib/figlet/figmagic A head/contrib/figlet/FAQ A head/contrib/figlet/inflate.h A head/contrib/figlet/CHANGES A head/contrib/figlet/figfont.txt A head/contrib/figlet/zipio.c A head/contrib/figlet/chkfont.c A head/contrib/figlet/Makefile A head/contrib/figlet/figlet.6 A vendor/figlet/2.2.1 A vendor/figlet/2.2.1/zipio.h A vendor/figlet/2.2.1/showfigfonts A vendor/figlet/2.2.1/Artistic-license.txt A vendor/figlet/2.2.1/getopt.c A vendor/figlet/2.2.1/crc.c A vendor/figlet/2.2.1/fonts A vendor/figlet/2.2.1/fonts/hz.flc A vendor/figlet/2.2.1/fonts/646-fr.flc A vendor/figlet/2.2.1/fonts/slant.flf A vendor/figlet/2.2.1/fonts/smslant.flf A vendor/figlet/2.2.1/fonts/ushebrew.flc A vendor/figlet/2.2.1/fonts/646-jp.flc A vendor/figlet/2.2.1/fonts/utf8.flc A vendor/figlet/2.2.1/fonts/jis0201.flc A vendor/figlet/2.2.1/fonts/shadow.flf A vendor/figlet/2.2.1/fonts/smshadow.flf A vendor/figlet/2.2.1/fonts/646-hu.flc A vendor/figlet/2.2.1/fonts/646-no.flc A vendor/figlet/2.2.1/fonts/block.flf A vendor/figlet/2.2.1/fonts/bubble.flf A vendor/figlet/2.2.1/fonts/646-pt.flc A vendor/figlet/2.2.1/fonts/646-ca.flc A vendor/figlet/2.2.1/fonts/646-gb.flc A vendor/figlet/2.2.1/fonts/moscow.flc A vendor/figlet/2.2.1/fonts/script.flf A vendor/figlet/2.2.1/fonts/smscript.flf A vendor/figlet/2.2.1/fonts/term.flf A vendor/figlet/2.2.1/fonts/small.flf A vendor/figlet/2.2.1/fonts/8859-2.flc A vendor/figlet/2.2.1/fonts/frango.flc A vendor/figlet/2.2.1/fonts/8859-3.flc A vendor/figlet/2.2.1/fonts/646-cn.flc A vendor/figlet/2.2.1/fonts/646-irv.flc A vendor/figlet/2.2.1/fonts/8859-4.flc A vendor/figlet/2.2.1/fonts/8859-5.flc A vendor/figlet/2.2.1/fonts/digital.flf A vendor/figlet/2.2.1/fonts/8859-7.flc A vendor/figlet/2.2.1/fonts/8859-8.flc A vendor/figlet/2.2.1/fonts/646-pt2.flc A vendor/figlet/2.2.1/fonts/646-ca2.flc A vendor/figlet/2.2.1/fonts/lean.flf A vendor/figlet/2.2.1/fonts/8859-9.flc A vendor/figlet/2.2.1/fonts/646-se.flc A vendor/figlet/2.2.1/fonts/646-cu.flc A vendor/figlet/2.2.1/fonts/646-es.flc A vendor/figlet/2.2.1/fonts/uskata.flc A vendor/figlet/2.2.1/fonts/646-it.flc A vendor/figlet/2.2.1/fonts/646-kr.flc A vendor/figlet/2.2.1/fonts/upper.flc A vendor/figlet/2.2.1/fonts/koi8r.flc A vendor/figlet/2.2.1/fonts/mini.flf A vendor/figlet/2.2.1/fonts/ivrit.flf A vendor/figlet/2.2.1/fonts/ilhebrew.flc A vendor/figlet/2.2.1/fonts/standard.flf A vendor/figlet/2.2.1/fonts/big.flf A vendor/figlet/2.2.1/fonts/646-de.flc A vendor/figlet/2.2.1/fonts/646-se2.flc A vendor/figlet/2.2.1/fonts/646-es2.flc A vendor/figlet/2.2.1/fonts/banner.flf A vendor/figlet/2.2.1/fonts/mnemonic.flf A vendor/figlet/2.2.1/fonts/646-yu.flc A vendor/figlet/2.2.1/fonts/646-no2.flc A vendor/figlet/2.2.1/fonts/646-dk.flc A vendor/figlet/2.2.1/figlet.c A vendor/figlet/2.2.1/README A vendor/figlet/2.2.1/crc.h A vendor/figlet/2.2.1/figlist A vendor/figlet/2.2.1/inflate.c A vendor/figlet/2.2.1/figmagic A vendor/figlet/2.2.1/FAQ A vendor/figlet/2.2.1/inflate.h A vendor/figlet/2.2.1/CHANGES A vendor/figlet/2.2.1/figfont.txt A vendor/figlet/2.2.1/zipio.c A vendor/figlet/2.2.1/chkfont.c A vendor/figlet/2.2.1/Makefile A vendor/figlet/2.2.1/figlet.6 A vendor/figlet/dist A vendor/figlet/dist/zipio.h A vendor/figlet/dist/showfigfonts A vendor/figlet/dist/Artistic-license.txt A vendor/figlet/dist/getopt.c A vendor/figlet/dist/crc.c A vendor/figlet/dist/fonts A vendor/figlet/dist/fonts/hz.flc A vendor/figlet/dist/fonts/646-fr.flc A vendor/figlet/dist/fonts/slant.flf A vendor/figlet/dist/fonts/smslant.flf A vendor/figlet/dist/fonts/ushebrew.flc A vendor/figlet/dist/fonts/646-jp.flc A vendor/figlet/dist/fonts/utf8.flc A vendor/figlet/dist/fonts/jis0201.flc A vendor/figlet/dist/fonts/shadow.flf A vendor/figlet/dist/fonts/smshadow.flf A vendor/figlet/dist/fonts/646-hu.flc A vendor/figlet/dist/fonts/646-no.flc A vendor/figlet/dist/fonts/block.flf A vendor/figlet/dist/fonts/bubble.flf A vendor/figlet/dist/fonts/646-pt.flc A vendor/figlet/dist/fonts/646-ca.flc A vendor/figlet/dist/fonts/646-gb.flc A vendor/figlet/dist/fonts/moscow.flc A vendor/figlet/dist/fonts/script.flf A vendor/figlet/dist/fonts/smscript.flf A vendor/figlet/dist/fonts/term.flf A vendor/figlet/dist/fonts/small.flf A vendor/figlet/dist/fonts/8859-2.flc A vendor/figlet/dist/fonts/frango.flc A vendor/figlet/dist/fonts/8859-3.flc A vendor/figlet/dist/fonts/646-cn.flc A vendor/figlet/dist/fonts/646-irv.flc A vendor/figlet/dist/fonts/8859-4.flc A vendor/figlet/dist/fonts/8859-5.flc A vendor/figlet/dist/fonts/digital.flf A vendor/figlet/dist/fonts/8859-7.flc A vendor/figlet/dist/fonts/8859-8.flc A vendor/figlet/dist/fonts/646-pt2.flc A vendor/figlet/dist/fonts/646-ca2.flc A vendor/figlet/dist/fonts/lean.flf A vendor/figlet/dist/fonts/8859-9.flc A vendor/figlet/dist/fonts/646-se.flc A vendor/figlet/dist/fonts/646-cu.flc A vendor/figlet/dist/fonts/646-es.flc A vendor/figlet/dist/fonts/uskata.flc A vendor/figlet/dist/fonts/646-it.flc A vendor/figlet/dist/fonts/646-kr.flc A vendor/figlet/dist/fonts/upper.flc A vendor/figlet/dist/fonts/koi8r.flc A vendor/figlet/dist/fonts/mini.flf A vendor/figlet/dist/fonts/ivrit.flf A vendor/figlet/dist/fonts/ilhebrew.flc A vendor/figlet/dist/fonts/standard.flf A vendor/figlet/dist/fonts/big.flf A vendor/figlet/dist/fonts/646-de.flc A vendor/figlet/dist/fonts/646-se2.flc A vendor/figlet/dist/fonts/646-es2.flc A vendor/figlet/dist/fonts/banner.flf A vendor/figlet/dist/fonts/mnemonic.flf A vendor/figlet/dist/fonts/646-yu.flc A vendor/figlet/dist/fonts/646-no2.flc A vendor/figlet/dist/fonts/646-dk.flc A vendor/figlet/dist/figlet.c A vendor/figlet/dist/README A vendor/figlet/dist/crc.h A vendor/figlet/dist/figlist A vendor/figlet/dist/inflate.c A vendor/figlet/dist/figmagic A vendor/figlet/dist/FAQ A vendor/figlet/dist/inflate.h A vendor/figlet/dist/CHANGES A vendor/figlet/dist/figfont.txt A vendor/figlet/dist/zipio.c A vendor/figlet/dist/chkfont.c A vendor/figlet/dist/Makefile A vendor/figlet/dist/figlet.6 Updated to revision 4. + tar xf /usr/ports/distfiles/figlet222.tar.gz + svn-vendorimport.sh figlet222 vendor/figlet/dist D Artistic-license.txt A LICENSE + svn ci -m 'Import Figlet version 2.2.2' vendor/figlet/dist Deleting vendor/figlet/dist/Artistic-license.txt Sending vendor/figlet/dist/CHANGES Sending vendor/figlet/dist/FAQ Adding vendor/figlet/dist/LICENSE Sending vendor/figlet/dist/Makefile Sending vendor/figlet/dist/README Sending vendor/figlet/dist/figfont.txt Sending vendor/figlet/dist/figlet.6 Sending vendor/figlet/dist/figlet.c Transmitting file data ........ Committed revision 5. + svn copy -m 'Tag the Figlet 2.2.2 import' file:///usr/obj/tmp/TEST-repo/vendor/figlet/dist file:///usr/obj/tmp/TEST-repo/vendor/figlet/2.2.2 Committed revision 6. + svn up Updating '.': A vendor/figlet/2.2.2 A vendor/figlet/2.2.2/zipio.h A vendor/figlet/2.2.2/showfigfonts A vendor/figlet/2.2.2/LICENSE A vendor/figlet/2.2.2/getopt.c A vendor/figlet/2.2.2/crc.c A vendor/figlet/2.2.2/fonts A vendor/figlet/2.2.2/fonts/hz.flc A vendor/figlet/2.2.2/fonts/646-fr.flc A vendor/figlet/2.2.2/fonts/slant.flf A vendor/figlet/2.2.2/fonts/smslant.flf A vendor/figlet/2.2.2/fonts/ushebrew.flc A vendor/figlet/2.2.2/fonts/646-jp.flc A vendor/figlet/2.2.2/fonts/utf8.flc A vendor/figlet/2.2.2/fonts/jis0201.flc A vendor/figlet/2.2.2/fonts/shadow.flf A vendor/figlet/2.2.2/fonts/smshadow.flf A vendor/figlet/2.2.2/fonts/646-hu.flc A vendor/figlet/2.2.2/fonts/646-no.flc A vendor/figlet/2.2.2/fonts/block.flf A vendor/figlet/2.2.2/fonts/bubble.flf A vendor/figlet/2.2.2/fonts/646-pt.flc A vendor/figlet/2.2.2/fonts/646-ca.flc A vendor/figlet/2.2.2/fonts/646-gb.flc A vendor/figlet/2.2.2/fonts/smscript.flf A vendor/figlet/2.2.2/fonts/script.flf A vendor/figlet/2.2.2/fonts/moscow.flc A vendor/figlet/2.2.2/fonts/term.flf A vendor/figlet/2.2.2/fonts/small.flf A vendor/figlet/2.2.2/fonts/frango.flc A vendor/figlet/2.2.2/fonts/8859-2.flc A vendor/figlet/2.2.2/fonts/646-irv.flc A vendor/figlet/2.2.2/fonts/646-cn.flc A vendor/figlet/2.2.2/fonts/8859-3.flc A vendor/figlet/2.2.2/fonts/8859-4.flc A vendor/figlet/2.2.2/fonts/8859-5.flc A vendor/figlet/2.2.2/fonts/digital.flf A vendor/figlet/2.2.2/fonts/8859-7.flc A vendor/figlet/2.2.2/fonts/8859-8.flc A vendor/figlet/2.2.2/fonts/646-pt2.flc A vendor/figlet/2.2.2/fonts/646-ca2.flc A vendor/figlet/2.2.2/fonts/lean.flf A vendor/figlet/2.2.2/fonts/8859-9.flc A vendor/figlet/2.2.2/fonts/646-se.flc A vendor/figlet/2.2.2/fonts/646-cu.flc A vendor/figlet/2.2.2/fonts/646-es.flc A vendor/figlet/2.2.2/fonts/uskata.flc A vendor/figlet/2.2.2/fonts/646-it.flc A vendor/figlet/2.2.2/fonts/646-kr.flc A vendor/figlet/2.2.2/fonts/upper.flc A vendor/figlet/2.2.2/fonts/koi8r.flc A vendor/figlet/2.2.2/fonts/mini.flf A vendor/figlet/2.2.2/fonts/ivrit.flf A vendor/figlet/2.2.2/fonts/ilhebrew.flc A vendor/figlet/2.2.2/fonts/standard.flf A vendor/figlet/2.2.2/fonts/big.flf A vendor/figlet/2.2.2/fonts/646-de.flc A vendor/figlet/2.2.2/fonts/646-se2.flc A vendor/figlet/2.2.2/fonts/646-es2.flc A vendor/figlet/2.2.2/fonts/banner.flf A vendor/figlet/2.2.2/fonts/mnemonic.flf A vendor/figlet/2.2.2/fonts/646-yu.flc A vendor/figlet/2.2.2/fonts/646-no2.flc A vendor/figlet/2.2.2/fonts/646-dk.flc A vendor/figlet/2.2.2/figlet.c A vendor/figlet/2.2.2/README A vendor/figlet/2.2.2/crc.h A vendor/figlet/2.2.2/figlist A vendor/figlet/2.2.2/inflate.c A vendor/figlet/2.2.2/figmagic A vendor/figlet/2.2.2/FAQ A vendor/figlet/2.2.2/inflate.h A vendor/figlet/2.2.2/CHANGES A vendor/figlet/2.2.2/figfont.txt A vendor/figlet/2.2.2/zipio.c A vendor/figlet/2.2.2/chkfont.c A vendor/figlet/2.2.2/Makefile A vendor/figlet/2.2.2/figlet.6 Updated to revision 6. + svn merge ^/vendor/figlet/dist head/contrib/figlet --- Merging r4 through r6 into 'head/contrib/figlet': A head/contrib/figlet/LICENSE U head/contrib/figlet/figlet.c U head/contrib/figlet/README U head/contrib/figlet/FAQ U head/contrib/figlet/CHANGES U head/contrib/figlet/figfont.txt U head/contrib/figlet/Makefile U head/contrib/figlet/figlet.6 D head/contrib/figlet/Artistic-license.txt --- Recording mergeinfo for merge of r4 through r6 into 'head/contrib/figlet': U head/contrib/figlet + svn ci -m 'Merge Figlet 2.2.2 to HEAD' head Sending head/contrib/figlet Deleting head/contrib/figlet/Artistic-license.txt Sending head/contrib/figlet/CHANGES Sending head/contrib/figlet/FAQ Adding head/contrib/figlet/LICENSE Sending head/contrib/figlet/Makefile Sending head/contrib/figlet/README Sending head/contrib/figlet/figfont.txt Sending head/contrib/figlet/figlet.6 Sending head/contrib/figlet/figlet.c Transmitting file data ....... Committed revision 7. + svn copy -m 'The New Gen folks took over Figlet' file:///usr/obj/tmp/TEST-repo/vendor/figlet file:///usr/obj/tmp/TEST-repo/vendor/figlet-NG Committed revision 8. + svn up Updating '.': A vendor/figlet-NG A vendor/figlet-NG/2.2.1 A vendor/figlet-NG/2.2.1/zipio.h A vendor/figlet-NG/2.2.1/showfigfonts A vendor/figlet-NG/2.2.1/Artistic-license.txt A vendor/figlet-NG/2.2.1/getopt.c A vendor/figlet-NG/2.2.1/crc.c A vendor/figlet-NG/2.2.1/fonts A vendor/figlet-NG/2.2.1/fonts/hz.flc A vendor/figlet-NG/2.2.1/fonts/646-fr.flc A vendor/figlet-NG/2.2.1/fonts/slant.flf A vendor/figlet-NG/2.2.1/fonts/smslant.flf A vendor/figlet-NG/2.2.1/fonts/ushebrew.flc A vendor/figlet-NG/2.2.1/fonts/646-jp.flc A vendor/figlet-NG/2.2.1/fonts/utf8.flc A vendor/figlet-NG/2.2.1/fonts/jis0201.flc A vendor/figlet-NG/2.2.1/fonts/shadow.flf A vendor/figlet-NG/2.2.1/fonts/smshadow.flf A vendor/figlet-NG/2.2.1/fonts/646-hu.flc A vendor/figlet-NG/2.2.1/fonts/646-no.flc A vendor/figlet-NG/2.2.1/fonts/block.flf A vendor/figlet-NG/2.2.1/fonts/bubble.flf A vendor/figlet-NG/2.2.1/fonts/646-pt.flc A vendor/figlet-NG/2.2.1/fonts/646-ca.flc A vendor/figlet-NG/2.2.1/fonts/646-gb.flc A vendor/figlet-NG/2.2.1/fonts/smscript.flf A vendor/figlet-NG/2.2.1/fonts/script.flf A vendor/figlet-NG/2.2.1/fonts/moscow.flc A vendor/figlet-NG/2.2.1/fonts/term.flf A vendor/figlet-NG/2.2.1/fonts/small.flf A vendor/figlet-NG/2.2.1/fonts/frango.flc A vendor/figlet-NG/2.2.1/fonts/8859-2.flc A vendor/figlet-NG/2.2.1/fonts/646-irv.flc A vendor/figlet-NG/2.2.1/fonts/646-cn.flc A vendor/figlet-NG/2.2.1/fonts/8859-3.flc A vendor/figlet-NG/2.2.1/fonts/8859-4.flc A vendor/figlet-NG/2.2.1/fonts/8859-5.flc A vendor/figlet-NG/2.2.1/fonts/digital.flf A vendor/figlet-NG/2.2.1/fonts/8859-7.flc A vendor/figlet-NG/2.2.1/fonts/8859-8.flc A vendor/figlet-NG/2.2.1/fonts/646-pt2.flc A vendor/figlet-NG/2.2.1/fonts/646-ca2.flc A vendor/figlet-NG/2.2.1/fonts/lean.flf A vendor/figlet-NG/2.2.1/fonts/8859-9.flc A vendor/figlet-NG/2.2.1/fonts/646-se.flc A vendor/figlet-NG/2.2.1/fonts/646-cu.flc A vendor/figlet-NG/2.2.1/fonts/646-es.flc A vendor/figlet-NG/2.2.1/fonts/uskata.flc A vendor/figlet-NG/2.2.1/fonts/646-it.flc A vendor/figlet-NG/2.2.1/fonts/646-kr.flc A vendor/figlet-NG/2.2.1/fonts/upper.flc A vendor/figlet-NG/2.2.1/fonts/koi8r.flc A vendor/figlet-NG/2.2.1/fonts/mini.flf A vendor/figlet-NG/2.2.1/fonts/ivrit.flf A vendor/figlet-NG/2.2.1/fonts/ilhebrew.flc A vendor/figlet-NG/2.2.1/fonts/standard.flf A vendor/figlet-NG/2.2.1/fonts/big.flf A vendor/figlet-NG/2.2.1/fonts/646-de.flc A vendor/figlet-NG/2.2.1/fonts/646-se2.flc A vendor/figlet-NG/2.2.1/fonts/646-es2.flc A vendor/figlet-NG/2.2.1/fonts/banner.flf A vendor/figlet-NG/2.2.1/fonts/mnemonic.flf A vendor/figlet-NG/2.2.1/fonts/646-yu.flc A vendor/figlet-NG/2.2.1/fonts/646-no2.flc A vendor/figlet-NG/2.2.1/fonts/646-dk.flc A vendor/figlet-NG/2.2.1/figlet.c A vendor/figlet-NG/2.2.1/README A vendor/figlet-NG/2.2.1/crc.h A vendor/figlet-NG/2.2.1/figlist A vendor/figlet-NG/2.2.1/inflate.c A vendor/figlet-NG/2.2.1/figmagic A vendor/figlet-NG/2.2.1/FAQ A vendor/figlet-NG/2.2.1/inflate.h A vendor/figlet-NG/2.2.1/CHANGES A vendor/figlet-NG/2.2.1/figfont.txt A vendor/figlet-NG/2.2.1/zipio.c A vendor/figlet-NG/2.2.1/chkfont.c A vendor/figlet-NG/2.2.1/Makefile A vendor/figlet-NG/2.2.1/figlet.6 A vendor/figlet-NG/2.2.2 A vendor/figlet-NG/2.2.2/zipio.h A vendor/figlet-NG/2.2.2/showfigfonts A vendor/figlet-NG/2.2.2/LICENSE A vendor/figlet-NG/2.2.2/getopt.c A vendor/figlet-NG/2.2.2/crc.c A vendor/figlet-NG/2.2.2/fonts A vendor/figlet-NG/2.2.2/fonts/hz.flc A vendor/figlet-NG/2.2.2/fonts/646-fr.flc A vendor/figlet-NG/2.2.2/fonts/slant.flf A vendor/figlet-NG/2.2.2/fonts/smslant.flf A vendor/figlet-NG/2.2.2/fonts/ushebrew.flc A vendor/figlet-NG/2.2.2/fonts/646-jp.flc A vendor/figlet-NG/2.2.2/fonts/utf8.flc A vendor/figlet-NG/2.2.2/fonts/jis0201.flc A vendor/figlet-NG/2.2.2/fonts/shadow.flf A vendor/figlet-NG/2.2.2/fonts/smshadow.flf A vendor/figlet-NG/2.2.2/fonts/646-hu.flc A vendor/figlet-NG/2.2.2/fonts/646-no.flc A vendor/figlet-NG/2.2.2/fonts/block.flf A vendor/figlet-NG/2.2.2/fonts/bubble.flf A vendor/figlet-NG/2.2.2/fonts/646-pt.flc A vendor/figlet-NG/2.2.2/fonts/646-ca.flc A vendor/figlet-NG/2.2.2/fonts/646-gb.flc A vendor/figlet-NG/2.2.2/fonts/moscow.flc A vendor/figlet-NG/2.2.2/fonts/script.flf A vendor/figlet-NG/2.2.2/fonts/smscript.flf A vendor/figlet-NG/2.2.2/fonts/term.flf A vendor/figlet-NG/2.2.2/fonts/small.flf A vendor/figlet-NG/2.2.2/fonts/8859-2.flc A vendor/figlet-NG/2.2.2/fonts/frango.flc A vendor/figlet-NG/2.2.2/fonts/8859-3.flc A vendor/figlet-NG/2.2.2/fonts/646-cn.flc A vendor/figlet-NG/2.2.2/fonts/646-irv.flc A vendor/figlet-NG/2.2.2/fonts/8859-4.flc A vendor/figlet-NG/2.2.2/fonts/8859-5.flc A vendor/figlet-NG/2.2.2/fonts/digital.flf A vendor/figlet-NG/2.2.2/fonts/8859-7.flc A vendor/figlet-NG/2.2.2/fonts/8859-8.flc A vendor/figlet-NG/2.2.2/fonts/646-pt2.flc A vendor/figlet-NG/2.2.2/fonts/646-ca2.flc A vendor/figlet-NG/2.2.2/fonts/lean.flf A vendor/figlet-NG/2.2.2/fonts/8859-9.flc A vendor/figlet-NG/2.2.2/fonts/646-se.flc A vendor/figlet-NG/2.2.2/fonts/646-cu.flc A vendor/figlet-NG/2.2.2/fonts/646-es.flc A vendor/figlet-NG/2.2.2/fonts/uskata.flc A vendor/figlet-NG/2.2.2/fonts/646-it.flc A vendor/figlet-NG/2.2.2/fonts/646-kr.flc A vendor/figlet-NG/2.2.2/fonts/upper.flc A vendor/figlet-NG/2.2.2/fonts/koi8r.flc A vendor/figlet-NG/2.2.2/fonts/mini.flf A vendor/figlet-NG/2.2.2/fonts/ivrit.flf A vendor/figlet-NG/2.2.2/fonts/ilhebrew.flc A vendor/figlet-NG/2.2.2/fonts/standard.flf A vendor/figlet-NG/2.2.2/fonts/big.flf A vendor/figlet-NG/2.2.2/fonts/646-de.flc A vendor/figlet-NG/2.2.2/fonts/646-se2.flc A vendor/figlet-NG/2.2.2/fonts/646-es2.flc A vendor/figlet-NG/2.2.2/fonts/banner.flf A vendor/figlet-NG/2.2.2/fonts/mnemonic.flf A vendor/figlet-NG/2.2.2/fonts/646-yu.flc A vendor/figlet-NG/2.2.2/fonts/646-no2.flc A vendor/figlet-NG/2.2.2/fonts/646-dk.flc A vendor/figlet-NG/2.2.2/figlet.c A vendor/figlet-NG/2.2.2/README A vendor/figlet-NG/2.2.2/crc.h A vendor/figlet-NG/2.2.2/figlist A vendor/figlet-NG/2.2.2/inflate.c A vendor/figlet-NG/2.2.2/figmagic A vendor/figlet-NG/2.2.2/FAQ A vendor/figlet-NG/2.2.2/inflate.h A vendor/figlet-NG/2.2.2/CHANGES A vendor/figlet-NG/2.2.2/figfont.txt A vendor/figlet-NG/2.2.2/zipio.c A vendor/figlet-NG/2.2.2/chkfont.c A vendor/figlet-NG/2.2.2/Makefile A vendor/figlet-NG/2.2.2/figlet.6 A vendor/figlet-NG/dist A vendor/figlet-NG/dist/zipio.h A vendor/figlet-NG/dist/showfigfonts A vendor/figlet-NG/dist/LICENSE A vendor/figlet-NG/dist/getopt.c A vendor/figlet-NG/dist/crc.c A vendor/figlet-NG/dist/fonts A vendor/figlet-NG/dist/fonts/hz.flc A vendor/figlet-NG/dist/fonts/646-fr.flc A vendor/figlet-NG/dist/fonts/slant.flf A vendor/figlet-NG/dist/fonts/smslant.flf A vendor/figlet-NG/dist/fonts/ushebrew.flc A vendor/figlet-NG/dist/fonts/646-jp.flc A vendor/figlet-NG/dist/fonts/utf8.flc A vendor/figlet-NG/dist/fonts/jis0201.flc A vendor/figlet-NG/dist/fonts/shadow.flf A vendor/figlet-NG/dist/fonts/smshadow.flf A vendor/figlet-NG/dist/fonts/646-hu.flc A vendor/figlet-NG/dist/fonts/646-no.flc A vendor/figlet-NG/dist/fonts/block.flf A vendor/figlet-NG/dist/fonts/bubble.flf A vendor/figlet-NG/dist/fonts/646-pt.flc A vendor/figlet-NG/dist/fonts/646-ca.flc A vendor/figlet-NG/dist/fonts/646-gb.flc A vendor/figlet-NG/dist/fonts/moscow.flc A vendor/figlet-NG/dist/fonts/script.flf A vendor/figlet-NG/dist/fonts/smscript.flf A vendor/figlet-NG/dist/fonts/term.flf A vendor/figlet-NG/dist/fonts/small.flf A vendor/figlet-NG/dist/fonts/8859-2.flc A vendor/figlet-NG/dist/fonts/frango.flc A vendor/figlet-NG/dist/fonts/8859-3.flc A vendor/figlet-NG/dist/fonts/646-cn.flc A vendor/figlet-NG/dist/fonts/646-irv.flc A vendor/figlet-NG/dist/fonts/8859-4.flc A vendor/figlet-NG/dist/fonts/8859-5.flc A vendor/figlet-NG/dist/fonts/digital.flf A vendor/figlet-NG/dist/fonts/8859-7.flc A vendor/figlet-NG/dist/fonts/8859-8.flc A vendor/figlet-NG/dist/fonts/646-pt2.flc A vendor/figlet-NG/dist/fonts/646-ca2.flc A vendor/figlet-NG/dist/fonts/lean.flf A vendor/figlet-NG/dist/fonts/8859-9.flc A vendor/figlet-NG/dist/fonts/646-se.flc A vendor/figlet-NG/dist/fonts/646-cu.flc A vendor/figlet-NG/dist/fonts/646-es.flc A vendor/figlet-NG/dist/fonts/uskata.flc A vendor/figlet-NG/dist/fonts/646-it.flc A vendor/figlet-NG/dist/fonts/646-kr.flc A vendor/figlet-NG/dist/fonts/upper.flc A vendor/figlet-NG/dist/fonts/koi8r.flc A vendor/figlet-NG/dist/fonts/mini.flf A vendor/figlet-NG/dist/fonts/ivrit.flf A vendor/figlet-NG/dist/fonts/ilhebrew.flc A vendor/figlet-NG/dist/fonts/standard.flf A vendor/figlet-NG/dist/fonts/big.flf A vendor/figlet-NG/dist/fonts/646-de.flc A vendor/figlet-NG/dist/fonts/646-se2.flc A vendor/figlet-NG/dist/fonts/646-es2.flc A vendor/figlet-NG/dist/fonts/banner.flf A vendor/figlet-NG/dist/fonts/mnemonic.flf A vendor/figlet-NG/dist/fonts/646-yu.flc A vendor/figlet-NG/dist/fonts/646-no2.flc A vendor/figlet-NG/dist/fonts/646-dk.flc A vendor/figlet-NG/dist/figlet.c A vendor/figlet-NG/dist/README A vendor/figlet-NG/dist/crc.h A vendor/figlet-NG/dist/figlist A vendor/figlet-NG/dist/inflate.c A vendor/figlet-NG/dist/figmagic A vendor/figlet-NG/dist/FAQ A vendor/figlet-NG/dist/inflate.h A vendor/figlet-NG/dist/CHANGES A vendor/figlet-NG/dist/figfont.txt A vendor/figlet-NG/dist/zipio.c A vendor/figlet-NG/dist/chkfont.c A vendor/figlet-NG/dist/Makefile A vendor/figlet-NG/dist/figlet.6 Updated to revision 8. + tar xf /usr/ports/distfiles/figlet-2.2.3.tar.gz + svn-vendorimport.sh figlet-2.2.3 vendor/figlet-NG/dist D figmagic D getopt.c A Makefile.tc A chkfont.6 A figlist.6 A showfigfonts.6 + svn ci -m 'Import Figlet NG version 2.2.3' vendor/figlet-NG Sending vendor/figlet-NG/dist/CHANGES Sending vendor/figlet-NG/dist/FAQ Sending vendor/figlet-NG/dist/LICENSE Sending vendor/figlet-NG/dist/Makefile Adding vendor/figlet-NG/dist/Makefile.tc Sending vendor/figlet-NG/dist/README Adding vendor/figlet-NG/dist/chkfont.6 Sending vendor/figlet-NG/dist/chkfont.c Sending vendor/figlet-NG/dist/crc.c Sending vendor/figlet-NG/dist/crc.h Sending vendor/figlet-NG/dist/figlet.6 Sending vendor/figlet-NG/dist/figlet.c Adding vendor/figlet-NG/dist/figlist.6 Deleting vendor/figlet-NG/dist/figmagic Sending vendor/figlet-NG/dist/fonts/jis0201.flc Deleting vendor/figlet-NG/dist/getopt.c Sending vendor/figlet-NG/dist/inflate.c Sending vendor/figlet-NG/dist/inflate.h Adding vendor/figlet-NG/dist/showfigfonts.6 Sending vendor/figlet-NG/dist/zipio.c Sending vendor/figlet-NG/dist/zipio.h Transmitting file data ................... Committed revision 9. + svn copy -m 'Tag the Figlet NG 2.2.3 import' file:///usr/obj/tmp/TEST-repo/vendor/figlet-NG/dist file:///usr/obj/tmp/TEST-repo/vendor/figlet-NG/2.2.2 Committed revision 10. + svn up Updating '.': A vendor/figlet-NG/2.2.2/dist A vendor/figlet-NG/2.2.2/dist/zipio.h A vendor/figlet-NG/2.2.2/dist/showfigfonts A vendor/figlet-NG/2.2.2/dist/LICENSE A vendor/figlet-NG/2.2.2/dist/Makefile.tc A vendor/figlet-NG/2.2.2/dist/showfigfonts.6 A vendor/figlet-NG/2.2.2/dist/crc.c A vendor/figlet-NG/2.2.2/dist/fonts A vendor/figlet-NG/2.2.2/dist/fonts/hz.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-fr.flc A vendor/figlet-NG/2.2.2/dist/fonts/slant.flf A vendor/figlet-NG/2.2.2/dist/fonts/smslant.flf A vendor/figlet-NG/2.2.2/dist/fonts/ushebrew.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-jp.flc A vendor/figlet-NG/2.2.2/dist/fonts/utf8.flc A vendor/figlet-NG/2.2.2/dist/fonts/jis0201.flc A vendor/figlet-NG/2.2.2/dist/fonts/shadow.flf A vendor/figlet-NG/2.2.2/dist/fonts/smshadow.flf A vendor/figlet-NG/2.2.2/dist/fonts/646-hu.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-no.flc A vendor/figlet-NG/2.2.2/dist/fonts/block.flf A vendor/figlet-NG/2.2.2/dist/fonts/bubble.flf A vendor/figlet-NG/2.2.2/dist/fonts/646-pt.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-ca.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-gb.flc A vendor/figlet-NG/2.2.2/dist/fonts/moscow.flc A vendor/figlet-NG/2.2.2/dist/fonts/script.flf A vendor/figlet-NG/2.2.2/dist/fonts/smscript.flf A vendor/figlet-NG/2.2.2/dist/fonts/term.flf A vendor/figlet-NG/2.2.2/dist/fonts/small.flf A vendor/figlet-NG/2.2.2/dist/fonts/8859-2.flc A vendor/figlet-NG/2.2.2/dist/fonts/frango.flc A vendor/figlet-NG/2.2.2/dist/fonts/8859-3.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-cn.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-irv.flc A vendor/figlet-NG/2.2.2/dist/fonts/8859-4.flc A vendor/figlet-NG/2.2.2/dist/fonts/8859-5.flc A vendor/figlet-NG/2.2.2/dist/fonts/digital.flf A vendor/figlet-NG/2.2.2/dist/fonts/8859-7.flc A vendor/figlet-NG/2.2.2/dist/fonts/8859-8.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-pt2.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-ca2.flc A vendor/figlet-NG/2.2.2/dist/fonts/lean.flf A vendor/figlet-NG/2.2.2/dist/fonts/8859-9.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-se.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-cu.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-es.flc A vendor/figlet-NG/2.2.2/dist/fonts/uskata.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-it.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-kr.flc A vendor/figlet-NG/2.2.2/dist/fonts/upper.flc A vendor/figlet-NG/2.2.2/dist/fonts/koi8r.flc A vendor/figlet-NG/2.2.2/dist/fonts/mini.flf A vendor/figlet-NG/2.2.2/dist/fonts/ivrit.flf A vendor/figlet-NG/2.2.2/dist/fonts/ilhebrew.flc A vendor/figlet-NG/2.2.2/dist/fonts/standard.flf A vendor/figlet-NG/2.2.2/dist/fonts/big.flf A vendor/figlet-NG/2.2.2/dist/fonts/646-de.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-se2.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-es2.flc A vendor/figlet-NG/2.2.2/dist/fonts/banner.flf A vendor/figlet-NG/2.2.2/dist/fonts/mnemonic.flf A vendor/figlet-NG/2.2.2/dist/fonts/646-yu.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-no2.flc A vendor/figlet-NG/2.2.2/dist/fonts/646-dk.flc A vendor/figlet-NG/2.2.2/dist/figlet.c A vendor/figlet-NG/2.2.2/dist/README A vendor/figlet-NG/2.2.2/dist/crc.h A vendor/figlet-NG/2.2.2/dist/chkfont.6 A vendor/figlet-NG/2.2.2/dist/figlist A vendor/figlet-NG/2.2.2/dist/inflate.c A vendor/figlet-NG/2.2.2/dist/figlist.6 A vendor/figlet-NG/2.2.2/dist/FAQ A vendor/figlet-NG/2.2.2/dist/CHANGES A vendor/figlet-NG/2.2.2/dist/inflate.h A vendor/figlet-NG/2.2.2/dist/figfont.txt A vendor/figlet-NG/2.2.2/dist/zipio.c A vendor/figlet-NG/2.2.2/dist/chkfont.c A vendor/figlet-NG/2.2.2/dist/Makefile A vendor/figlet-NG/2.2.2/dist/figlet.6 Updated to revision 10. + svn merge ^/vendor/figlet-NG/dist head/contrib/figlet --- Recording mergeinfo for merge of r7 into 'head/contrib/figlet': U head/contrib/figlet --- Merging r8 through r10 into 'head/contrib/figlet': U head/contrib/figlet/zipio.h U head/contrib/figlet/LICENSE A head/contrib/figlet/Makefile.tc A head/contrib/figlet/showfigfonts.6 U head/contrib/figlet/crc.c U head/contrib/figlet/fonts/jis0201.flc D head/contrib/figlet/getopt.c D head/contrib/figlet/figmagic U head/contrib/figlet/figlet.c U head/contrib/figlet/README U head/contrib/figlet/crc.h A head/contrib/figlet/chkfont.6 U head/contrib/figlet/inflate.c A head/contrib/figlet/figlist.6 U head/contrib/figlet/FAQ U head/contrib/figlet/CHANGES U head/contrib/figlet/inflate.h U head/contrib/figlet/zipio.c U head/contrib/figlet/chkfont.c U head/contrib/figlet/Makefile U head/contrib/figlet/figlet.6 --- Recording mergeinfo for merge of r8 through r10 into 'head/contrib/figlet': G head/contrib/figlet + svn ci -m 'Merge Figlet 2.2.3 to HEAD' head Sending head/contrib/figlet Sending head/contrib/figlet/CHANGES Sending head/contrib/figlet/FAQ Sending head/contrib/figlet/LICENSE Sending head/contrib/figlet/Makefile Adding head/contrib/figlet/Makefile.tc Sending head/contrib/figlet/README Adding head/contrib/figlet/chkfont.6 Sending head/contrib/figlet/chkfont.c Sending head/contrib/figlet/crc.c Sending head/contrib/figlet/crc.h Sending head/contrib/figlet/figlet.6 Sending head/contrib/figlet/figlet.c Adding head/contrib/figlet/figlist.6 Deleting head/contrib/figlet/figmagic Sending head/contrib/figlet/fonts/jis0201.flc Deleting head/contrib/figlet/getopt.c Sending head/contrib/figlet/inflate.c Sending head/contrib/figlet/inflate.h Adding head/contrib/figlet/showfigfonts.6 Sending head/contrib/figlet/zipio.c Sending head/contrib/figlet/zipio.h Transmitting file data ............... Committed revision 11. + svn up Updating '.': At revision 11. + tar xf /usr/ports/distfiles/figlet-2.2.4.tar.gz + svn-vendorimport.sh figlet-2.2.4 vendor/figlet/dist D figmagic D getopt.c A Makefile.tc A chkfont.6 A figlist.6 A run-tests.sh A showfigfonts.6 A tests A (bin) tests/emboss.tlf A tests/input.txt A tests/longtext.txt A tests/res001.txt A tests/res002.txt A tests/res003.txt A tests/res004.txt A tests/res005.txt A tests/res006.txt A tests/res007.txt A tests/res008.txt A tests/res009.txt A tests/res010.txt A tests/res011.txt A tests/res012.txt A tests/res013.txt A tests/res014.txt A tests/res015.txt A tests/res016.txt A tests/res017.txt A tests/res018.txt A tests/res019.txt A tests/res020.txt A tests/res021.txt A tests/res022.txt A tests/res023.txt A tests/res024.txt A utf8.c A utf8.h + svn ci -m 'Import Figlet version 2.2.4 (Author returns!)' vendor/figlet Sending vendor/figlet/dist/CHANGES Sending vendor/figlet/dist/FAQ Sending vendor/figlet/dist/LICENSE Sending vendor/figlet/dist/Makefile Adding vendor/figlet/dist/Makefile.tc Sending vendor/figlet/dist/README Adding vendor/figlet/dist/chkfont.6 Sending vendor/figlet/dist/chkfont.c Sending vendor/figlet/dist/crc.c Sending vendor/figlet/dist/crc.h Sending vendor/figlet/dist/figfont.txt Sending vendor/figlet/dist/figlet.6 Sending vendor/figlet/dist/figlet.c Sending vendor/figlet/dist/figlist Adding vendor/figlet/dist/figlist.6 Deleting vendor/figlet/dist/figmagic Sending vendor/figlet/dist/fonts/jis0201.flc Deleting vendor/figlet/dist/getopt.c Sending vendor/figlet/dist/inflate.c Sending vendor/figlet/dist/inflate.h Adding vendor/figlet/dist/run-tests.sh Sending vendor/figlet/dist/showfigfonts Adding vendor/figlet/dist/showfigfonts.6 Adding vendor/figlet/dist/tests Adding (bin) vendor/figlet/dist/tests/emboss.tlf Adding vendor/figlet/dist/tests/input.txt Adding vendor/figlet/dist/tests/longtext.txt Adding vendor/figlet/dist/tests/res001.txt Adding vendor/figlet/dist/tests/res002.txt Adding vendor/figlet/dist/tests/res003.txt Adding vendor/figlet/dist/tests/res004.txt Adding vendor/figlet/dist/tests/res005.txt Adding vendor/figlet/dist/tests/res006.txt Adding vendor/figlet/dist/tests/res007.txt Adding vendor/figlet/dist/tests/res008.txt Adding vendor/figlet/dist/tests/res009.txt Adding vendor/figlet/dist/tests/res010.txt Adding vendor/figlet/dist/tests/res011.txt Adding vendor/figlet/dist/tests/res012.txt Adding vendor/figlet/dist/tests/res013.txt Adding vendor/figlet/dist/tests/res014.txt Adding vendor/figlet/dist/tests/res015.txt Adding vendor/figlet/dist/tests/res016.txt Adding vendor/figlet/dist/tests/res017.txt Adding vendor/figlet/dist/tests/res018.txt Adding vendor/figlet/dist/tests/res019.txt Adding vendor/figlet/dist/tests/res020.txt Adding vendor/figlet/dist/tests/res021.txt Adding vendor/figlet/dist/tests/res022.txt Adding vendor/figlet/dist/tests/res023.txt Adding vendor/figlet/dist/tests/res024.txt Adding vendor/figlet/dist/utf8.c Adding vendor/figlet/dist/utf8.h Sending vendor/figlet/dist/zipio.c Sending vendor/figlet/dist/zipio.h Transmitting file data .................................................... Committed revision 12. + svn copy -m 'Tag the Figlet 2.2.4 (Author returns!) import' file:///usr/obj/tmp/TEST-repo/vendor/figlet/dist file:///usr/obj/tmp/TEST-repo/vendor/figlet/2.2.4 Committed revision 13. + svn merge ^/vendor/figlet/dist head/contrib/figlet --- Merging r8 through r13 into 'head/contrib/figlet': U head/contrib/figlet/showfigfonts C head/contrib/figlet/Makefile.tc C head/contrib/figlet/showfigfonts.6 C head/contrib/figlet/getopt.c C head/contrib/figlet/figmagic C head/contrib/figlet/figlet.c C head/contrib/figlet/README C head/contrib/figlet/chkfont.6 U head/contrib/figlet/figlist A head/contrib/figlet/tests A head/contrib/figlet/tests/longtext.txt A head/contrib/figlet/tests/res001.txt A head/contrib/figlet/tests/res010.txt A head/contrib/figlet/tests/res020.txt A head/contrib/figlet/tests/res002.txt A head/contrib/figlet/tests/res011.txt A head/contrib/figlet/tests/res021.txt A head/contrib/figlet/tests/res003.txt A head/contrib/figlet/tests/res012.txt A head/contrib/figlet/tests/res022.txt A head/contrib/figlet/tests/res004.txt A head/contrib/figlet/tests/res013.txt A head/contrib/figlet/tests/res023.txt A head/contrib/figlet/tests/res014.txt A head/contrib/figlet/tests/res005.txt A head/contrib/figlet/tests/res006.txt A head/contrib/figlet/tests/res015.txt A head/contrib/figlet/tests/res024.txt A head/contrib/figlet/tests/res007.txt A head/contrib/figlet/tests/res016.txt A head/contrib/figlet/tests/res008.txt A head/contrib/figlet/tests/res017.txt A head/contrib/figlet/tests/res009.txt A head/contrib/figlet/tests/res018.txt A head/contrib/figlet/tests/res019.txt A head/contrib/figlet/tests/emboss.tlf A head/contrib/figlet/tests/input.txt C head/contrib/figlet/figlist.6 C head/contrib/figlet/FAQ A head/contrib/figlet/utf8.c C head/contrib/figlet/CHANGES U head/contrib/figlet/figfont.txt A head/contrib/figlet/utf8.h C head/contrib/figlet/Makefile A head/contrib/figlet/run-tests.sh C head/contrib/figlet/figlet.6 --- Recording mergeinfo for merge of r8 through r13 into 'head/contrib/figlet': U head/contrib/figlet Summary of conflicts: Text conflicts: 6 Tree conflicts: 6 Script done on Tue Jul 3 11:19:16 2012 --4Ckj6UjgE2iN1+kY-- From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 10:59:33 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 146A9106566C; Wed, 4 Jul 2012 10:59:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C6CB18FC15; Wed, 4 Jul 2012 10:59:32 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 34B58B939; Wed, 4 Jul 2012 06:59:32 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org, obrien@freebsd.org Date: Wed, 4 Jul 2012 06:59:31 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <1340992732.19144.YahooMailClassic@web113501.mail.gq1.yahoo.com> <20120703182118.GA70183@dragon.NUXI.org> In-Reply-To: <20120703182118.GA70183@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201207040659.31330.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Jul 2012 06:59:32 -0400 (EDT) Cc: arch@freebsd.org, gnn@freebsd.org, pfg@freebsd.org, Doug Barton Subject: Re: svn commit: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/c... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 10:59:33 -0000 On Tuesday, July 03, 2012 02:21:19 PM David O'Brien wrote: > On Tue, Jul 03, 2012 at 08:55:11AM -0600, Warner Losh wrote: > > On Jul 3, 2012, at 8:50 AM, gnn@freebsd.org wrote: > > > At Mon, 2 Jul 2012 14:09:31 -0700, David O'Brien wrote: > > >> On Sun, Jul 01, 2012 at 08:32:41PM -0700, Doug Barton wrote: > > >>> On 06/29/2012 10:58, Pedro Giffuni wrote: > > >>>> Now .. David pointed out I am not respecting the code > > >>>> provenance since I didn't add them to the opensolaris > > >>>> vendor area, but these files are copyrighted Joyent > > >>>> Inc (not even Illumos) so I cannot put them there > > >>>> unless we create a new vendor for Joyent > > >>> > > >>> Creating a new vendor area would be the right solution, yes. > > >> > > >> I totally disagree -- it will cause a real pain merging. > > ... > > > > I actually agree with Doug here, but not strongly, I'd prefer to be > > > better educated about this topic. Do our Repo Meisters read arch@? > > > > I agree with Doug as well. I think that transitioning from one vendor > > tree to the other is the right thing to do. Unless we have good, > > concrete reasons not to do this, I think the default assumption should > > be this is a good idea. > > FYI, > When I disagreed with Doug it was for a "new" vendor tree vs. a renamed > (moved) one. In other words I disagree with having two vendor trees. > > > I believe that svn merge -c XXX will work because of how mergenotes > > work, but I'd appreciate confirmation from our repo masters. > > Please see below. I'm almost sure it will not work in what would be > likely situation. I expect 'svn merge -c' will likely have svn telling > you it cannot find the previous revision. > > > I think that having the two different sources is a good thing, should > > OpenSolaris ever come back to live and be a viable source of imports. > > We need to keep that option open, > > We're never totally shut off from any option. Even if we > 'svn delete vendor/opensolaris' and then later want to do an import > from Oracle, we (or Repo Meisters) can resurrect it in the manner that > is best for that time. But leaving vendor/opensolaris alive now, > makes it too easy for someone to import there that isn't aware of > the issues. > > > unless doing so has a real, demonstrable harm. > > I set up a test repository to show what I am concerned of. > I used Figlet (/usr/ports/misc/figlet) as it had a fork when the > original author moved on. I then did an import as if the original > author returned to his own line of figlet. > > Roughly: > 1. Import figlet 2.2.1 into vendor/figlet > 2. Merge 2.2.1 to head/contrib/figlet > 3. Import figlet 2.2.2 into vendor/figlet > 4. Merge 2.2.2 to head/contrib/figlet > 5. Copy vendor/figlet to vendor/figlet-NG [fork] > 6. Import figlet 2.2.3 into vendor/figlet-NG > 7. Merge 2.2.3 to head/contrib/figlet > 8. Import figlet 2.2.4 into vendor/figlet [return of original author] > 9. Merge 2.2.4 to head/contrib/figlet > > This lead to > Summary of conflicts: > Text conflicts: 6 > Tree conflicts: 6 > > Which is the problem -- what do you do with the tree conflicts? > Tree conflicts are quite different from the usual textual conflicts. > > Please see > http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html Note > the examples there are more simplistic than our situation. > > When the 2nd vendor does an new release and it is merged in, you'll get > another set of tree conflicts. > > One thing to keep in mind with SCM's more advanced than CVS is objects > are not the same just because their file names are the same. An object > has a clear ancestry. Just because I am "David O'Brien", doesn't mean > another "David O'Brien" of a different mother is just a newer version > of me. > > One way to deal with this is to use "merge --ignore-ancestry". > Please see > http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branch > merge.advanced.ancestry which directly talks to our situation. > > But, I really don't think we want to use --ignore-ancestry. Per the > docs, it disables merge tracking (svn:mergeinfo is not considered when > svn merge is determining what revisions to merge, nor is svn:mergeinfo > recorded to describe the merge). It turns the 'svn merge' into a more > textual 3-way diff + patch. And even if we were OK with this, we would > have a very hard time documenting and getting the word out to everyone > that should know about it. (i.e., every committer that ever wants to > bring in new Solaris-family technologies) > > The other way is essentially to 'svn delete' the tree conflicts in > head/vendor/figlet before doing the merge and let the merge put in > files of a totally different ancestry. Then when the same tree > conflicts occur again when importing from the other vendor we do > the same. So we wind up with a ping-pong of ancestry and one cannot > readily read the commit history of these files. > > Also note the textual conflicts where there should have been zero -- I > made no text changes within head/contrib/figlet. > > I'll attach the set of commands and the 'script out sh -x' run > of that so folks can first-hand test this. Actually, this appears to have worked very well. The switch from vendor/figlet to vendor/figlet-NG was seemless. The text conflicts are for files changed by both vendors, and the tree conflicts are for when vendor/figlet updates a file removed by an earlier import from vendor/figlet-NG. That is exactly the sort of situation that requires manual intervention to determine the right course of action (should we bring back the deleted file or leave it out). Once you have made that decision and fixed up the version of the file you want to use (or left it removed) you can use 'resolve --accept working' to resolve the tree conflict. Why don't you try resolving one tree conflict by removing the file and at least one other by resurrecting the vendor/figlet file, then create new versions on each vendor that add some trivial changes and merge them. I suspect you will only have to resolve the tree conflict once (and not on each import). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jul 4 10:59:33 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 146A9106566C; Wed, 4 Jul 2012 10:59:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C6CB18FC15; Wed, 4 Jul 2012 10:59:32 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 34B58B939; Wed, 4 Jul 2012 06:59:32 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org, obrien@freebsd.org Date: Wed, 4 Jul 2012 06:59:31 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <1340992732.19144.YahooMailClassic@web113501.mail.gq1.yahoo.com> <20120703182118.GA70183@dragon.NUXI.org> In-Reply-To: <20120703182118.GA70183@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201207040659.31330.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Jul 2012 06:59:32 -0400 (EDT) Cc: arch@freebsd.org, gnn@freebsd.org, pfg@freebsd.org, Doug Barton Subject: Re: svn commit: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/c... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 10:59:33 -0000 On Tuesday, July 03, 2012 02:21:19 PM David O'Brien wrote: > On Tue, Jul 03, 2012 at 08:55:11AM -0600, Warner Losh wrote: > > On Jul 3, 2012, at 8:50 AM, gnn@freebsd.org wrote: > > > At Mon, 2 Jul 2012 14:09:31 -0700, David O'Brien wrote: > > >> On Sun, Jul 01, 2012 at 08:32:41PM -0700, Doug Barton wrote: > > >>> On 06/29/2012 10:58, Pedro Giffuni wrote: > > >>>> Now .. David pointed out I am not respecting the code > > >>>> provenance since I didn't add them to the opensolaris > > >>>> vendor area, but these files are copyrighted Joyent > > >>>> Inc (not even Illumos) so I cannot put them there > > >>>> unless we create a new vendor for Joyent > > >>> > > >>> Creating a new vendor area would be the right solution, yes. > > >> > > >> I totally disagree -- it will cause a real pain merging. > > ... > > > > I actually agree with Doug here, but not strongly, I'd prefer to be > > > better educated about this topic. Do our Repo Meisters read arch@? > > > > I agree with Doug as well. I think that transitioning from one vendor > > tree to the other is the right thing to do. Unless we have good, > > concrete reasons not to do this, I think the default assumption should > > be this is a good idea. > > FYI, > When I disagreed with Doug it was for a "new" vendor tree vs. a renamed > (moved) one. In other words I disagree with having two vendor trees. > > > I believe that svn merge -c XXX will work because of how mergenotes > > work, but I'd appreciate confirmation from our repo masters. > > Please see below. I'm almost sure it will not work in what would be > likely situation. I expect 'svn merge -c' will likely have svn telling > you it cannot find the previous revision. > > > I think that having the two different sources is a good thing, should > > OpenSolaris ever come back to live and be a viable source of imports. > > We need to keep that option open, > > We're never totally shut off from any option. Even if we > 'svn delete vendor/opensolaris' and then later want to do an import > from Oracle, we (or Repo Meisters) can resurrect it in the manner that > is best for that time. But leaving vendor/opensolaris alive now, > makes it too easy for someone to import there that isn't aware of > the issues. > > > unless doing so has a real, demonstrable harm. > > I set up a test repository to show what I am concerned of. > I used Figlet (/usr/ports/misc/figlet) as it had a fork when the > original author moved on. I then did an import as if the original > author returned to his own line of figlet. > > Roughly: > 1. Import figlet 2.2.1 into vendor/figlet > 2. Merge 2.2.1 to head/contrib/figlet > 3. Import figlet 2.2.2 into vendor/figlet > 4. Merge 2.2.2 to head/contrib/figlet > 5. Copy vendor/figlet to vendor/figlet-NG [fork] > 6. Import figlet 2.2.3 into vendor/figlet-NG > 7. Merge 2.2.3 to head/contrib/figlet > 8. Import figlet 2.2.4 into vendor/figlet [return of original author] > 9. Merge 2.2.4 to head/contrib/figlet > > This lead to > Summary of conflicts: > Text conflicts: 6 > Tree conflicts: 6 > > Which is the problem -- what do you do with the tree conflicts? > Tree conflicts are quite different from the usual textual conflicts. > > Please see > http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html Note > the examples there are more simplistic than our situation. > > When the 2nd vendor does an new release and it is merged in, you'll get > another set of tree conflicts. > > One thing to keep in mind with SCM's more advanced than CVS is objects > are not the same just because their file names are the same. An object > has a clear ancestry. Just because I am "David O'Brien", doesn't mean > another "David O'Brien" of a different mother is just a newer version > of me. > > One way to deal with this is to use "merge --ignore-ancestry". > Please see > http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branch > merge.advanced.ancestry which directly talks to our situation. > > But, I really don't think we want to use --ignore-ancestry. Per the > docs, it disables merge tracking (svn:mergeinfo is not considered when > svn merge is determining what revisions to merge, nor is svn:mergeinfo > recorded to describe the merge). It turns the 'svn merge' into a more > textual 3-way diff + patch. And even if we were OK with this, we would > have a very hard time documenting and getting the word out to everyone > that should know about it. (i.e., every committer that ever wants to > bring in new Solaris-family technologies) > > The other way is essentially to 'svn delete' the tree conflicts in > head/vendor/figlet before doing the merge and let the merge put in > files of a totally different ancestry. Then when the same tree > conflicts occur again when importing from the other vendor we do > the same. So we wind up with a ping-pong of ancestry and one cannot > readily read the commit history of these files. > > Also note the textual conflicts where there should have been zero -- I > made no text changes within head/contrib/figlet. > > I'll attach the set of commands and the 'script out sh -x' run > of that so folks can first-hand test this. Actually, this appears to have worked very well. The switch from vendor/figlet to vendor/figlet-NG was seemless. The text conflicts are for files changed by both vendors, and the tree conflicts are for when vendor/figlet updates a file removed by an earlier import from vendor/figlet-NG. That is exactly the sort of situation that requires manual intervention to determine the right course of action (should we bring back the deleted file or leave it out). Once you have made that decision and fixed up the version of the file you want to use (or left it removed) you can use 'resolve --accept working' to resolve the tree conflict. Why don't you try resolving one tree conflict by removing the file and at least one other by resurrecting the vendor/figlet file, then create new versions on each vendor that add some trivial changes and merge them. I suspect you will only have to resolve the tree conflict once (and not on each import). -- John Baldwin