From jsun@junsun.net Fri Jul 16 18:31:08 2004 Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6GMV7bI021173 for ; Fri, 16 Jul 2004 18:31:08 -0400 Received: from gateway.junsun.net (c-24-6-204-16.client.comcast.net[24.6.204.16]) by comcast.net (rwcrmhc13) with ESMTP id <20040716223111015003ftp4e>; Fri, 16 Jul 2004 22:31:11 +0000 Received: from gateway.junsun.net (gateway [127.0.0.1]) by gateway.junsun.net (8.12.8/8.12.8) with ESMTP id i6GMdl9T019799 for ; Fri, 16 Jul 2004 15:39:48 -0700 Received: (from jsun@localhost) by gateway.junsun.net (8.12.8/8.12.8/Submit) id i6GMdl6p019798 for conary-list@lists.specifixinc.com; Fri, 16 Jul 2004 15:39:47 -0700 Date: Fri, 16 Jul 2004 15:39:47 -0700 From: Jun Sun To: conary-list@lists.specifixinc.com Message-ID: <20040716223947.GD19714@gateway.junsun.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: where to find docs? X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Discussion of Conary per se List-Id: Discussion of Conary per se List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2004 22:31:08 -0000 I am glad to be the first one to post in this list. :) The first problem I encountered after downloading conary is that I found zero documentation. A simple "make" gives the following errors (on RedHat 9). The white paper is too high a level to give any useful hints. Any pointers? Jun [jsun@gateway conary-0.1]$ make for d in build local repository lib pysqlite deps; do make -C $d DIR=$d || exit 1; done make[1]: Entering directory `/home/jsun/local/build/conary-0.1/build' echo "nothing to build" nothing to build make[1]: Leaving directory `/home/jsun/local/build/conary-0.1/build' make[1]: Entering directory `/home/jsun/local/build/conary-0.1/local' echo "nothing to install" nothing to install make[1]: Leaving directory `/home/jsun/local/build/conary-0.1/local' make[1]: Entering directory `/home/jsun/local/build/conary-0.1/repository' echo "nothing to build" nothing to build make[1]: Leaving directory `/home/jsun/local/build/conary-0.1/repository' make[1]: /usr/lib/conary/python/bin/python2.3: Command not found make[1]: Entering directory `/home/jsun/local/build/conary-0.1/lib' cc -Wall -I -fPIC -c -o elf.o elf.c elf.c:17:20: Python.h: No such file or directory elf.c:26: parse error before '*' token elf.c:26: parse error before '*' token elf.c:26: warning: type defaults to `int' in declaration of `inspect' elf.c:26: warning: data definition has no type or storage class elf.c:27: parse error before '*' token elf.c:27: parse error before '*' token elf.c:27: warning: type defaults to `int' in declaration of `stripped' elf.c:27: warning: data definition has no type or storage class elf.c:28: parse error before '*' token .... From johnsonm@specifixinc.com Fri Jul 16 20:47:53 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6H0lrbI021371 for ; Fri, 16 Jul 2004 20:47:53 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id A27BC1670E for ; Fri, 16 Jul 2004 17:47:57 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6H0luTD030817 for ; Fri, 16 Jul 2004 20:47:56 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i6H0ludv030815 for conary-list@lists.specifixinc.com; Fri, 16 Jul 2004 20:47:56 -0400 Resent-Message-Id: <200407170047.i6H0ludv030815@lambchop.rdu.specifixinc.com> Date: Fri, 16 Jul 2004 20:46:41 -0400 From: "Michael K. Johnson" To: conary-list@specifixinc.com Message-ID: <20040717004641.GA30657@lambchop.rdu.specifixinc.com> References: <20040716223947.GD19714@gateway.junsun.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040716223947.GD19714@gateway.junsun.net> User-Agent: Mutt/1.4.1i Resent-From: "Michael K. Johnson" Resent-Date: Fri, 16 Jul 2004 20:47:56 -0400 Resent-To: conary-list@specifixinc.com Cc: Subject: Re: where to find docs? X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Discussion of Conary per se List-Id: Discussion of Conary per se List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2004 00:47:54 -0000 On Fri, Jul 16, 2004 at 03:39:47PM -0700, Jun Sun wrote: > The first problem I encountered after downloading conary is > that I found zero documentation. Well, there's currently zero documentation on building it, anyway. There is a man page that has some documentation on using it, though it is a typical man page in that it is definitely reference rather than tutorial. Consider the documentation embryonic right now. > A simple "make" gives the following > errors (on RedHat 9). The white paper is too high a level to give > any useful hints. There is *no* documentation on building. However, if you want something that gives more details on the technology than that introductory white paper, you might consider looking at the paper we wrote for OLS, which OLS has kindly made available at: http://www.finux.org/Reprints/Reprint-Wilson-OLS2004.pdf > Any pointers? Sure. First, we haven't tried building on RHL9, so no promises. At a minimum, though, you need python 2.3 (/usr/bin/python2.3) and recent 2.x sqlite (we've used 2.8.13 and 2.8.14). I can say that those two on top of FC1 are sufficient. This project is still very young, and things have been changing very rapidly. I would encourage anyone interested to join us on the freenode.org IRC network on the #conary channel for real-time discussion. From johnsonm@specifixinc.com Fri Jul 16 21:18:33 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6H1IXbI022678 for ; Fri, 16 Jul 2004 21:18:33 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 1758A16710 for ; Fri, 16 Jul 2004 18:18:38 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6H1IaTD031777 for ; Fri, 16 Jul 2004 21:18:36 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i6H1IaY0031775 for conary-list@lists.specifixinc.com; Fri, 16 Jul 2004 21:18:36 -0400 Date: Fri, 16 Jul 2004 21:18:36 -0400 From: "Michael K. Johnson" To: conary-list@specifixinc.com Message-ID: <20040717011836.GA31721@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Cc: Subject: New Conary repository wire protocol X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2004 01:18:34 -0000 In order to fix a bug, the Conary repository wire protocol version was incremented. You will not be able to contact a repository until you have upgraded Conary. If you have installed Conary on your system from tarball, grab conary-0.2.tar.bz2 from the FTP site. If you have installed the distribution, grab conary-0.1-10-1-to-0.2-3-2.ccs (smaller and preferred, a relative changeset) or conary-0.2-3-2.ccs (larger, the absolute changeset) and apply it with "conary update " This will happen again in the future as we discover and fix bugs that impact the protocol. Sorry for the inconvenience... From pnasrat@redhat.com Sat Jul 17 01:24:04 2004 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6H5O4bI022978 for ; Sat, 17 Jul 2004 01:24:04 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6H5O9e1022265 for ; Sat, 17 Jul 2004 01:24:09 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6H5O9a28646 for ; Sat, 17 Jul 2004 01:24:09 -0400 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with ESMTP id i6H5NYHD011920 for ; Sat, 17 Jul 2004 01:23:34 -0400 Received: (from pnasrat@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) id i6H5NY1W011917 for conary-list@lists.specifixinc.com; Sat, 17 Jul 2004 01:23:34 -0400 Date: Sat, 17 Jul 2004 01:23:34 -0400 From: Paul Nasrat To: Conary Discussion Message-ID: <20040717052334.GA6893@devserv.devel.redhat.com> References: <20040717011836.GA31721@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040717011836.GA31721@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: New Conary repository wire protocol X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2004 05:24:04 -0000 On Fri, Jul 16, 2004 at 09:18:36PM -0400, Michael K. Johnson wrote: > In order to fix a bug, the Conary repository wire protocol version > was incremented. You will not be able to contact a repository > until you have upgraded Conary. At this point I don't really know enough about the conary protocol to comment,but a quick question. If the protocol is versioned which is implied above - is it not possible to do message translation to bootstrap the conary changeset publication. That way you don't have to run two copies of the repository? As both the client and the repo box are aware of the repository version that would seem fairly painless. I've seen this done for schema migration on "headless" clusters. Of course this may just be on the ever expanding TODO, and breakages are just something that people will deal with until things settle. Also based on the comments on irc this may have been the two versions of a module issue? Paul From johnsonm@specifixinc.com Sat Jul 17 10:00:22 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6HE0MbI024115 for ; Sat, 17 Jul 2004 10:00:22 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 0675C1670B for ; Sat, 17 Jul 2004 07:00:27 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6HE0PTD010500 for ; Sat, 17 Jul 2004 10:00:25 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i6HE0Pct010498 for conary-list@lists.specifixinc.com; Sat, 17 Jul 2004 10:00:25 -0400 Date: Sat, 17 Jul 2004 10:00:25 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040717140025.GA10384@lambchop.rdu.specifixinc.com> References: <20040717011836.GA31721@lambchop.rdu.specifixinc.com> <20040717052334.GA6893@devserv.devel.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040717052334.GA6893@devserv.devel.redhat.com> User-Agent: Mutt/1.4.1i Subject: Re: New Conary repository wire protocol X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2004 14:00:22 -0000 On Sat, Jul 17, 2004 at 01:23:34AM -0400, Paul Nasrat wrote: > If the protocol is versioned which is implied above - is it not possible to do > message translation to bootstrap the conary changeset publication. That way > you don't have to run two copies of the repository? As both the client and the > repo box are aware of the repository version that would seem fairly painless. > I've seen this done for schema migration on "headless" clusters. > > Of course this may just be on the ever expanding TODO, and breakages > are just something that people will deal with until things settle. This particular problem involved a change in the repository itself, as well as a change in the format, so conversion would be a long process and not worth the effort. During the alpha/beta process, this is likely to happen again as we discover things we need to fix. At this point, the repository gets touched up by hand at least once a week as we go "back in time" to fix bugs. (The alternative is to throw the repository away, which was what we did earlier in development while we still kept our recipes in CVS and merely created transitory repositories to test our repository code.) So until things settle, you will likely occasionally have to download a changeset and apply it. > Also based on the comments on irc this may have been the two versions > of a module issue? Yes, we couldn't create an old-protocol repository and a new-protocol repository on the same machine. Yes, we could have worked around that with lots of chroot etc. but at this point we'd rather work on fixing bugs when there's a simple workaround... From tchung@openwebmail.org Fri Jul 23 22:27:07 2004 Received: from www.openwebmail.org (www.openwebmail.org [69.44.61.113]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6O2R7bI000423 for ; Fri, 23 Jul 2004 22:27:07 -0400 Received: from openwebmail.org (localhost.localdomain [127.0.0.1]) by www.openwebmail.org (8.12.10/8.12.10) with ESMTP id i6O2Rpto004104 for ; Fri, 23 Jul 2004 19:27:51 -0700 From: "Thomas Chung" To: "conary-list" Date: Fri, 23 Jul 2004 19:27:51 -0700 Message-Id: <20040724022035.M68948@fedoranews.org> X-Mailer: Open WebMail 2.32 20040724 X-OriginatingIP: 137.79.66.107 (tchung) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: HOWTO install evolution via conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2004 02:27:07 -0000 Here is a little HOWTO install evolution via conary. First, let's query if evolution pkg has been installed in local # conary pq evolution (nothing) Now, let's query if evolution pkg is available from repository # conary rq evolution evolution 1.5.91-2-1 OK, let's install evoution pkg from repository # conary update evolution (after about 5 mins) Now, let's query if evolution pkg has been installed in local # conary pq evolution evolution 1.5.91-2-1 Yeah! Thomas From msw@specifixinc.com Fri Jul 23 22:33:19 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6O2XIbI000441 for ; Fri, 23 Jul 2004 22:33:19 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 5E89E16721 for ; Fri, 23 Jul 2004 19:33:31 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6O2XUTD015491 for ; Fri, 23 Jul 2004 22:33:30 -0400 Received: (from msw@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i6O2XUfx015489 for conary-list@lists.specifixinc.com; Fri, 23 Jul 2004 22:33:30 -0400 Date: Fri, 23 Jul 2004 22:33:29 -0400 From: Matt Wilson To: Conary Discussion Message-ID: <20040724023329.GA14762@specifixinc.com> References: <20040724022035.M68948@fedoranews.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040724022035.M68948@fedoranews.org> User-Agent: Mutt/1.4.1i Subject: Re: HOWTO install evolution via conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2004 02:33:19 -0000 On Fri, Jul 23, 2004 at 07:27:51PM -0700, Thomas Chung wrote: > > # conary pq evolution > evolution 1.5.91-2-1 > > Yeah! Good job! Only tricky thing at the moment is making sure that all of evolution's dependencies are satisfied. We still need to write that dependency check code. ;-) Cheers, Matt From tchung@openwebmail.org Fri Jul 23 22:37:51 2004 Received: from www.openwebmail.org (www.openwebmail.org [69.44.61.113]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6O2bobI000458 for ; Fri, 23 Jul 2004 22:37:50 -0400 Received: from openwebmail.org (localhost.localdomain [127.0.0.1]) by www.openwebmail.org (8.12.10/8.12.10) with ESMTP id i6O2cYto004173 for ; Fri, 23 Jul 2004 19:38:34 -0700 From: "Thomas Chung" To: Conary Discussion Date: Fri, 23 Jul 2004 19:38:34 -0700 Message-Id: <20040724023404.M98201@fedoranews.org> In-Reply-To: <20040724022035.M68948@fedoranews.org> References: <20040724022035.M68948@fedoranews.org> X-Mailer: Open WebMail 2.32 20040724 X-OriginatingIP: 137.79.66.107 (tchung) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: Re: HOWTO install evolution via conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2004 02:37:51 -0000 Hmm, I guess it's not ready to use yet. # /usr/bin/evolution-1.5 evolution-1.5: error while loading shared libraries: libecal.so.6: cannot open shared object file: No such file or directory Sorry. :( ---------- Original Message ----------- From: "Thomas Chung" To: "conary-list" Sent: Fri, 23 Jul 2004 19:27:51 -0700 Subject: HOWTO install evolution via conary > Here is a little HOWTO install evolution via conary. > > First, let's query if evolution pkg has been installed in local > > # conary pq evolution > (nothing) > > Now, let's query if evolution pkg is available from repository > > # conary rq evolution > evolution 1.5.91-2-1 > > OK, let's install evoution pkg from repository > > # conary update evolution > (after about 5 mins) > > Now, let's query if evolution pkg has been installed in local > > # conary pq evolution > evolution 1.5.91-2-1 > > Yeah! > > Thomas > _______________________________________________ > conary-list mailing list > conary-list@lists.specifixinc.com > http://lists.specifixinc.com/mailman/listinfo/conary-list ------- End of Original Message ------- From msw@specifixinc.com Fri Jul 23 22:49:12 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6O2nCbI000477 for ; Fri, 23 Jul 2004 22:49:12 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id E52EF16721 for ; Fri, 23 Jul 2004 19:49:24 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6O2nNTD015759 for ; Fri, 23 Jul 2004 22:49:23 -0400 Received: (from msw@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i6O2nNYn015757 for conary-list@lists.specifixinc.com; Fri, 23 Jul 2004 22:49:23 -0400 Date: Fri, 23 Jul 2004 22:49:23 -0400 From: Matt Wilson To: Conary Discussion Message-ID: <20040724024923.GB14762@specifixinc.com> References: <20040724022035.M68948@fedoranews.org> <20040724023404.M98201@fedoranews.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040724023404.M98201@fedoranews.org> User-Agent: Mutt/1.4.1i Subject: Re: HOWTO install evolution via conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2004 02:49:12 -0000 On Fri, Jul 23, 2004 at 07:38:34PM -0700, Thomas Chung wrote: > Hmm, > > I guess it's not ready to use yet. > > # /usr/bin/evolution-1.5 > evolution-1.5: error while loading shared libraries: libecal.so.6: cannot open shared > object file: No such file or directory Be sure to install evolution-data-server, gtkhtml, libsoup, and gal... That dependency thing is really what I need to do next..... Matt From tchung@openwebmail.org Fri Jul 23 23:02:42 2004 Received: from www.openwebmail.org (www.openwebmail.org [69.44.61.113]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6O32fbI000504 for ; Fri, 23 Jul 2004 23:02:41 -0400 Received: from openwebmail.org (localhost.localdomain [127.0.0.1]) by www.openwebmail.org (8.12.10/8.12.10) with ESMTP id i6O33Qto004264 for ; Fri, 23 Jul 2004 20:03:26 -0700 From: "Thomas Chung" To: Conary Discussion Date: Fri, 23 Jul 2004 20:03:26 -0700 Message-Id: <20040724025920.M11842@fedoranews.org> In-Reply-To: <20040724024923.GB14762@specifixinc.com> References: <20040724022035.M68948@fedoranews.org> <20040724023404.M98201@fedoranews.org> <20040724024923.GB14762@specifixinc.com> X-Mailer: Open WebMail 2.32 20040724 X-OriginatingIP: 137.79.66.107 (tchung) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: Re: HOWTO install evolution via conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2004 03:02:42 -0000 All right! After installing pkgs in following order, I can now launch evolution-1.5 # conary update evolution # conary update evolution-data-server # conary update gtkhtml # conary update libsoup # conary update gal # evolution-1.5 Here is the proof! :) http://openwebmail.org/specifix/screenshots/0.2/evolution.png ---------- Original Message ----------- From: Matt Wilson To: Conary Discussion Sent: Fri, 23 Jul 2004 22:49:23 -0400 Subject: Re: HOWTO install evolution via conary > On Fri, Jul 23, 2004 at 07:38:34PM -0700, Thomas Chung wrote: > > Hmm, > > > > I guess it's not ready to use yet. > > > > # /usr/bin/evolution-1.5 > > evolution-1.5: error while loading shared libraries: libecal.so.6: cannot open shared > > object file: No such file or directory > > Be sure to install evolution-data-server, gtkhtml, libsoup, and gal... > > That dependency thing is really what I need to do next..... > > Matt > _______________________________________________ > conary-list mailing list > conary-list@lists.specifixinc.com > http://lists.specifixinc.com/mailman/listinfo/conary-list ------- End of Original Message ------- From msw@specifixinc.com Sat Jul 24 00:11:55 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6O4BtbI000552 for ; Sat, 24 Jul 2004 00:11:55 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id B9C8C16721 for ; Fri, 23 Jul 2004 21:12:07 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6O4C6TD016934 for ; Sat, 24 Jul 2004 00:12:06 -0400 Received: (from msw@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i6O4C6qs016932 for conary-list@lists.specifixinc.com; Sat, 24 Jul 2004 00:12:06 -0400 Date: Sat, 24 Jul 2004 00:12:06 -0400 From: Matt Wilson To: Conary Discussion Message-ID: <20040724041206.GC14762@specifixinc.com> References: <20040724022035.M68948@fedoranews.org> <20040724023404.M98201@fedoranews.org> <20040724024923.GB14762@specifixinc.com> <20040724025920.M11842@fedoranews.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040724025920.M11842@fedoranews.org> User-Agent: Mutt/1.4.1i Subject: Re: HOWTO install evolution via conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2004 04:11:55 -0000 On Fri, Jul 23, 2004 at 08:03:26PM -0700, Thomas Chung wrote: > > Here is the proof! :) > > http://openwebmail.org/specifix/screenshots/0.2/evolution.png You're going to want to update mozilla as well in order to get libnss libraries. Cheers, Matt From tchung@openwebmail.org Sat Jul 24 01:55:26 2004 Received: from www.openwebmail.org (www.openwebmail.org [69.44.61.113]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6O5tQbI000634 for ; Sat, 24 Jul 2004 01:55:26 -0400 Received: from openwebmail.org (localhost.localdomain [127.0.0.1]) by www.openwebmail.org (8.12.10/8.12.10) with ESMTP id i6O5uAto026705 for ; Fri, 23 Jul 2004 22:56:10 -0700 From: "Thomas Chung" To: Conary Discussion Date: Fri, 23 Jul 2004 22:56:10 -0700 Message-Id: <20040724055206.M67009@fedoranews.org> In-Reply-To: <20040724041206.GC14762@specifixinc.com> References: <20040724022035.M68948@fedoranews.org> <20040724023404.M98201@fedoranews.org> <20040724024923.GB14762@specifixinc.com> <20040724025920.M11842@fedoranews.org> <20040724041206.GC14762@specifixinc.com> X-Mailer: Open WebMail 2.32 20040724 X-OriginatingIP: 24.31.56.126 (tchung) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: Re: HOWTO install evolution via conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2004 05:55:26 -0000 Cool, I was wondering about that when I didn't see any mail components. After updating mozilla as shown below: [root@localhost root]# conary pq mozilla mozilla 1.7-1-1 [root@localhost root]# conary rq mozilla mozilla 1.7-2-1 [root@localhost root]# conary update mozilla [root@localhost root]# conary pq mozilla mozilla 1.7-2-1 [root@localhost root]# I can now see a complete evolution! http://openwebmail.org/specifix/screenshots/0.2/evolution-complete.png Thank you Matt! I really appreciate all your help! Thomas ---------- Original Message ----------- From: Matt Wilson To: Conary Discussion Sent: Sat, 24 Jul 2004 00:12:06 -0400 Subject: Re: HOWTO install evolution via conary > On Fri, Jul 23, 2004 at 08:03:26PM -0700, Thomas Chung wrote: > > > > Here is the proof! :) > > > > http://openwebmail.org/specifix/screenshots/0.2/evolution.png > > You're going to want to update mozilla as well in order to get libnss > libraries. > > Cheers, > > Matt > _______________________________________________ > conary-list mailing list > conary-list@lists.specifixinc.com > http://lists.specifixinc.com/mailman/listinfo/conary-list ------- End of Original Message ------- From johnsonm@specifixinc.com Wed Jul 28 22:45:06 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6T2j5bI015573 for ; Wed, 28 Jul 2004 22:45:06 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id BF78416707 for ; Wed, 28 Jul 2004 19:45:23 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6T2jMTD011359 for ; Wed, 28 Jul 2004 22:45:22 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i6T2jMrC011357 for conary-list@lists.specifixinc.com; Wed, 28 Jul 2004 22:45:22 -0400 Date: Wed, 28 Jul 2004 22:45:22 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040729024522.GA11265@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Wiki now available X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2004 02:45:07 -0000 http://wiki.specifixinc.com/ is now available. I have populated it with some content we had written on an internal wiki. The main page is immutable to avoid trivial defacement attacks, and all pages require you to create an account to edit them, again to discourage trivial defacement attacks. Anyone who creates an account should be able to create new pages. When you create new pages and aren't sure where to link them, or have questions, please feel free to visit #conary on the freenode IRC network, where we can discuss where best to put them. From omar@tinysofa.org Wed Jul 28 23:06:04 2004 Received: from treehou.se (treehou.se [64.246.58.46]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6T364bI015656 for ; Wed, 28 Jul 2004 23:06:04 -0400 Received: (qmail 4456 invoked from network); 29 Jul 2004 03:06:20 -0000 Received: from ppp216-207.lns1.syd3.internode.on.net (HELO ?172.17.2.201?) (203.122.216.207) by treehou.se with RC4-MD5 encrypted SMTP; 29 Jul 2004 03:06:20 -0000 Message-ID: <410869AF.7000009@tinysofa.org> Date: Thu, 29 Jul 2004 13:06:23 +1000 From: Omar Kilani User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: conary-list@lists.specifixinc.com X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Ideas X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2004 03:06:04 -0000 Hi, Brain dumped these ideas in IRC last night, but thought I might give them some permanency on the mailing list. :) "Couple of ideas that I've had/implemented previously but sort of gave up on, which might be useful for inclusion in conary since it's pretty revolutionary. What would be nice is if say, some sort of distributed, version controlled architecture was available for files marked as %config This is probably better off outside the package management system, but it still needs to integrate in terms of md5sums and what not so say you have a cluster of 10 servers, and you want the same config file on all of them, but any changes should be reflected in the PMS updating cluster node 1's config and then running conary --propagate-config package could theoretically update the rest of the nodes as well as maintaining the PMS database. Of course, adding things like variable substitution to the system would be pretty cool so if your httpd.conf or whatever had ServerName %{hostname}, conary autofills it in before storing on node this is a little like cfengine, but PMS managed Then the SCM side of things helps in a 'sysadmin screwed up a change, and propagated it to the 10 nodes, roll back to revision X' so the conary changeset system could be used to do that, with a conary --rollback-config package --revision X. Another idea is a 'user installable packages' concept. Sort of a relocatable packages feature but a bit more... involved. A conary --install or whatever installs to $HOME/.conary, and updates PATH and LD_LIBRARY_PATH, or PKGCONFIG_PATH or whatever. And then theres a re-targetable version idea, which could also be system-wide or per-user. Say you have the FC mess of autotools :) conary already solves the package naming problem, so thats good. You have /conary/automake/1.7.x, /conary/automake/1.8.x, and then /conary/automake/current and you can switch current with conary --retarget-version automake --version 1.7.x. Doing that on a user level could be interesting you apply 'user installable packages' to that and user can then select which version they want to use. Issues such as what manages the 'automake' symlink need to be addressed, but not too hard, so parallel install/use is still possible. I'm not sure if XML was looked into as a recipe file format but when I wrote my own PMS, I used python as a recipe file format initially, where a 'source package' was a cpio (header + payload), where payload was tar.bz2 of a directory structure like 'package-version-release/{package,sources,patches}'. /package contained .py files representing various stages of the build process, a little like debian's control stuff, so info.py had lines like: name = 'openssl' version = '0.9.7b' release = '1' sources = [ ('name': 'tarball', url: 'http://www.blah.blah.blah/%{name}s-%{version}s-%{release}s') ], etc. To read in the package build details, I'd just 'import package' from the package directory anyway, problems I faced with this where hard to implement variable substitution (what if packager left off 's' in dict reference? what if they used 'd' instead), differences in implementation between lists and tuples, then you need to implement local vs global name spaces for macro defines and what not. So I moved to XML and this turned out to be much better, since I could use xpath for variable substitution, etc, and could easily separate things out into lists, do type handling based on what the XML parser told me, etc. Reviving rpm's xmlspec might be an option. Additionally, it would be nice if there was infrastructure in place to do md5/sha1 checks on sources, and possibly even gpg checks. I didn't see a definition for this in the tmpwatch.recipe or the wiki Recipe description page. A recipe maintainer could supply a .sig for their source, as well as expected fingerprint, and conary should be able to verify it. This is a good idea in terms of community security review as well, since you'd be able to tell if, for example, the GNUPG packages where compromised and help out in the restoration of proper source packages." That's about it for now. Thanks for reading. :) Best Regards, Omar Kilani From johnsonm@specifixinc.com Wed Jul 28 23:26:14 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6T3QEbI015776 for ; Wed, 28 Jul 2004 23:26:14 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id AEE9B16707 for ; Wed, 28 Jul 2004 20:26:32 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6T3QVTD012360 for ; Wed, 28 Jul 2004 23:26:31 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i6T3QVxo012358 for conary-list@lists.specifixinc.com; Wed, 28 Jul 2004 23:26:31 -0400 Date: Wed, 28 Jul 2004 23:26:31 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040729032631.GA12122@lambchop.rdu.specifixinc.com> References: <410869AF.7000009@tinysofa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <410869AF.7000009@tinysofa.org> User-Agent: Mutt/1.4.1i Subject: Re: Ideas X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2004 03:26:15 -0000 On Thu, Jul 29, 2004 at 01:06:23PM +1000, Omar Kilani wrote: > This is probably better off outside the package management system, but > it still needs to integrate in terms of md5sums and what not so say you > have a cluster of 10 servers, and you want the same config file on all > of them, but any changes should be reflected in the PMS updating cluster > node 1's config and then running conary --propagate-config package could > theoretically update the rest of the nodes as well as maintaining the > PMS database. > > Of course, adding things like variable substitution to the system would > be pretty cool so if your httpd.conf or whatever had ServerName > %{hostname}, conary autofills it in before storing on node this is a > little like cfengine, but PMS managed You could easily do this in a branch or shadow. Just add a "my-managed-config" tag to the files, and have the taghandler do the mangling. Alternatively or additionally, you could use local changesets directly or checked into a repository. So, your cluster of 1000 systems with essentially the same configuration you would manage by creating a shadow with modified configuration files. The substitution you could do with the extra taghandler. Files can have multiple tags associated with them; for example, as a general rule, a taghandler will be tagged both as a taghandler and as a config file. There's no hard limit to the number of tags you can assign to a file. In practice, keeping it down to somthing reasonable will benefit performance and maintainability. > Then the SCM side of things helps in a 'sysadmin screwed up a change, > and propagated it to the 10 nodes, roll back to revision X' so the > conary changeset system could be used to do that, with a conary > --rollback-config package --revision X. Yes. This is particularly true with local changesets committed to a corporate/private/whatever repository. > Another idea is a 'user installable packages' concept. Sort of a > relocatable packages feature but a bit more... involved. A conary > --install or whatever installs to $HOME/.conary, and updates PATH and > LD_LIBRARY_PATH, or PKGCONFIG_PATH or whatever. Mmm, you can set up special roots, but not sure about mangling people's .bashrc or whatever. > I'm not sure if XML was looked into as a recipe file format but when I Discussed and rejected... Not from any dislike of XML (for example, we use xmlrpc for the interface with the repository) but because we want very simple, easy-to-read, *easy-to-write* recipes with little noise and strong inheritance. Now, since they are python, there is absolutely nothing stopping you or anyone else from writing a recipe parser that implements an XML recipe. If XML were our base format, it would be impossible to go the other way. > To read in the package build details, I'd just 'import package' from the > package directory anyway, problems I faced with this where hard to > implement variable substitution (what if packager left off 's' in dict > reference? what if they used 'd' instead), We notice the missing s and complain. > differences in implementation > between lists and tuples, then you need to implement local vs global > name spaces for macro defines and what not. The wiki now has http://wiki.specifixinc.com/ConaryRecipe There's a lot of room for improvement. In some cases, we're still at the RTFS stage -- take a look at conary/build/macros.py and conary/build/recipe.py to see how our macros work. No need for global name spaces... > Additionally, it would be nice if there was infrastructure in place to > do md5/sha1 checks on sources, and possibly even gpg checks. I didn't read conary/build/source.py and search for gpg An md5sum doesn't really give you much there. > see a definition for this in the tmpwatch.recipe or the wiki Recipe > description page. It's missing a lot of stuff still. One thing we need to do is to export our epydoc-produced documentation. I think it will end up next to the sources on cvs.specifixinc.com -- there's a lot in there that hasn't been moved because it is still changing a lot. I'd suggest reading a bunch more recipes to see more variety, now that you've seen basic ones like tmpwatch. > A recipe maintainer could supply a .sig for their > source, as well as expected fingerprint, and conary should be able to > verify it. Exactly what we do. :-) From johnsonm@specifixinc.com Fri Jul 30 09:37:04 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6UDb4bI023945 for ; Fri, 30 Jul 2004 09:37:04 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id EDB0616737 for ; Fri, 30 Jul 2004 06:37:23 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i6UDbMTD009295 for ; Fri, 30 Jul 2004 09:37:22 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i6UDbM9F009293 for conary-list@lists.specifixinc.com; Fri, 30 Jul 2004 09:37:22 -0400 Date: Fri, 30 Jul 2004 09:37:22 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040730133722.GA8413@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Conary API documentation now available X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2004 13:37:04 -0000 http://cvs.specifixinc.com/conary-docs/ now has regularly-updated Conary API documentation. It is generated by epydoc within a few minutes of any new commit to the CVS repository. This is currently of interest not only to those who want to work on Conary per-se, but also to those who wish to write Conary recipes. This is because the documentation of the actions and policies used in Conary is currently changing enough that maintaining it in the source code has been the only way to keep it mostly in sync with what the code actually does. Look for this information under the "Package Building" heading, particularly the build subdirectory. You can ask questions here, or join us on #conary on the freenode IRC network. From dbc@specifixinc.com Wed Aug 4 16:56:49 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i74KumbI008120 for ; Wed, 4 Aug 2004 16:56:49 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id A14FC16760 for ; Wed, 4 Aug 2004 13:57:14 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i74KvDTD014791 for ; Wed, 4 Aug 2004 16:57:13 -0400 Received: (from dbc@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i74KvDG6014789 for conary-list@lists.specifixinc.com; Wed, 4 Aug 2004 16:57:13 -0400 Date: Wed, 4 Aug 2004 16:57:13 -0400 From: "David B. Christian" To: conary-list@lists.specifixinc.com Message-ID: <20040804205713.GA14455@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Build-side Flavors X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2004 20:56:49 -0000 Okay, here is some info about flavors, including how we are currently considering implementing the building of multiple flavors for a distribution. A flavor describes both the instruction set the package is built to run on and the configuration the package was built with. The same package can be built multiple times with the same configuration for multiple instruction sets, and multiple times for the same instruction set with different configurations. A single version of a package can be built multiple times with different flavors, and every flavor that was built for a single version is available in the repository. At install time, conary will get to choose which flavor to install. Flavor support is not complete; we store flavor information (though we have some modifications yet to make to that) but we do not yet use complete flavor information to choose which package to install. Flavors are controlled in recipes by three things: Use, Arch, and Flags. Use provides the system configuration; Use-flags are system-wide. Arch provides the definition of the instruction set being built. Flags give recipe-specific configuration options. One thing that we expect will happen is that a repository may want to have multiple flavors of a package available. We'd like a recipe to be able to specify which flavors of a package are are interesting/useful, and have those be cooked automatically by some unnamed distribution-building program. One suggested syntax to allow a recipe to specify useful combinations looks like this: Options = ( ((Flags.feature1, True), (Flags.feature2, False), (Use.blah, True)), ((Flags.feature1, False), (Flags.feature2, True), (Use.blah, True), (Use.asdf, False)), ((Flags.feature1, True), (Flags.feature2, False), (Use.blah, False)), ((Flags.feature1, True), (Flags.feature2, True)), # Any flag not mentioned in one of the combinations specified in # Options is a "don't care" flag in that configuration So, in this case, for every architecture, the recipe would be built using four configurations using the Use/Flags specified above, and all other configuration information following the default values. Any comments/ideas/questions are welcome. David Christian (dugan) From skvidal@phy.duke.edu Wed Aug 4 17:00:16 2004 Received: from mail.phy.duke.edu (mail.phy.duke.edu [152.3.182.2]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i74L0GbI008136 for ; Wed, 4 Aug 2004 17:00:16 -0400 Received: from [152.3.182.42] (opus.phy.duke.edu [152.3.182.42]) by mail.phy.duke.edu (Postfix) with ESMTP id 2A2C693254 for ; Wed, 4 Aug 2004 17:00:29 -0400 (EDT) From: seth vidal To: Conary Discussion In-Reply-To: <20040804205713.GA14455@lambchop.rdu.specifixinc.com> References: <20040804205713.GA14455@lambchop.rdu.specifixinc.com> Content-Type: text/plain Message-Id: <1091653240.32340.60.camel@opus.phy.duke.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 04 Aug 2004 17:00:40 -0400 Content-Transfer-Encoding: 7bit Subject: Re: Build-side Flavors X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2004 21:00:16 -0000 > So, in this case, for every architecture, the recipe would be built > using four configurations using the Use/Flags specified above, and all > other configuration information following the default values. > > Any comments/ideas/questions are welcome. How would the user select a different item for install? If they want the binary with --enable-foo=yes instead of --enable-foo=no for the flags? And how would they be ranked for value? -sv From dbc@specifixinc.com Thu Aug 5 09:34:56 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i75DYsbI009441 for ; Thu, 5 Aug 2004 09:34:55 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id ED15E16759 for ; Thu, 5 Aug 2004 06:35:14 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i75DZDTD001153 for ; Thu, 5 Aug 2004 09:35:13 -0400 Received: (from dbc@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i75DZDZM001151 for conary-list@lists.specifixinc.com; Thu, 5 Aug 2004 09:35:13 -0400 Date: Thu, 5 Aug 2004 09:35:13 -0400 From: "David B. Christian" To: Conary Discussion Message-ID: <20040805133513.GA32522@lambchop.rdu.specifixinc.com> References: <20040804205713.GA14455@lambchop.rdu.specifixinc.com> <1091653240.32340.60.camel@opus.phy.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1091653240.32340.60.camel@opus.phy.duke.edu> User-Agent: Mutt/1.4.1i Subject: Re: Build-side Flavors X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2004 13:34:57 -0000 > How would the user select a different item for install? If they want the > binary with --enable-foo=yes instead of --enable-foo=no for the flags? > My understanding (which is usually a little off from mkj's): 1. You can set up a configuration file which sets the user's choices for system-wide options, and perhaps package-specific options (this is not implemented) 2. You could specify the flags to set on the command line (also not implemented). Of course, in general, only some --enable/--disable configure flags are going to have associated flags, depending on the importance of being able to turn the feature on/off. I don't think there's any written policy for how that decision will be made yet. > And how would they be ranked for value? > The gist I got from the IRC communication was that there was no need to rank the options for value in the recipe. A user's Use flags would be set in a configuration file somewhere. Package specific flags would default to the values set in the recipe. Arch flags of course would be set. Of course, one can think of pathological cases, where flags interact. Say you are building licq, an ICQ client which has both Qt and Gtk interfaces. Suppose (falsely, I believe) that you can only install one of the two interfaces, because they cause problems. The build options might be something as simple as: ( ((Use.Qt, True), (Use.gtk, False)), ((Use.Qt, False), (Use.gtk, True)), ) However, on the install side, this will cause problems, because the user will probably has both Use.Qt and Use.gtk set to true. Which one do we install? One solution is to have these two versions on separate branches, and force the user to specify...but is that the right solution? Another, abstract case: If the options were: ( (...), ((Flags.foo, False), (Flags.bar, False), (Flags.bang, True)), ((Flags.foo, False), (Flags.bar, True), (Flags.bang, False)) ) And the defaults were Flags.foo = True Flags.bar = True Flags.bang = True But the user had set in a config file Flags.foo = False while not setting a value for bar and bang, then there is an ordering question: which one of the two options do I choose? Note that this case only comes up because the default installation values are not possible , because what is available when foo is true is not available as an option when foo is false. It would be important to see a real-world example of such interaction before worrying too much about these examples. One more thing: It is not clear yet how often this syntax will be used. It is only useful in cases where a repository wants to have multiple versions of the same package on the same branch. So far, the kernel is the only case we have for our own repository, although we have just begun looking. It may be that maintaining a sane set of options for the recipes in a package is the resposibility of the repository owner, and that poorly maintained repos will be avoided by users. However, I think it would be better if we could come up with a better solution. David Christian (dugan) From dbc@specifixinc.com Thu Aug 5 10:39:56 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i75EdtbI009853 for ; Thu, 5 Aug 2004 10:39:55 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 5380816759 for ; Thu, 5 Aug 2004 07:40:21 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i75EeHTD004380 for ; Thu, 5 Aug 2004 10:40:17 -0400 Received: (from dbc@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i75EeHYh004378 for conary-list@lists.specifixinc.com; Thu, 5 Aug 2004 10:40:17 -0400 Date: Thu, 5 Aug 2004 10:40:17 -0400 From: "David B. Christian" To: conary-list@lists.specifixinc.com Message-ID: <20040805144017.GB32522@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Use flags issue X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2004 14:39:56 -0000 Okay, so I've found a couple of places where the current Use flag syntax may not work. In tk.recipe, we have the following line: if not Use.tcl or not Use.tk or not Use.X: The way the Use flags are marked as being used is through their being accessed. I.e. when python looks within the Use object to see if it has a tcl flag, it is added to a list of flags that are important to this recipe. Of course, in the line from the tk recipe, python will short circuit before getting to Use.tk if Use.tcl is false, not evaluating it. This happens to not be a problem in this case because all that happens if hte Use.tcl flag is not set is that the recipe is not built at all. This short circuiting may come up in other cases with nested Use statements, like: if Use.a: if Use.b: I'm not sure whether this is a big deal or not -- it's not quite clear how which Use flags are used is important to a package. If several Use flags would trigger the same branch, e.g. in the case: If Use.a or Use.b or Use.c: Is it enough to know that Use.a was set for this build, and ignore the settings for Use.b and Use.c? David From johnsonm@specifixinc.com Thu Aug 5 12:44:00 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i75GhxbI013850 for ; Thu, 5 Aug 2004 12:44:00 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id D5B3E1675B for ; Thu, 5 Aug 2004 09:44:25 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i75GiOTD008053 for ; Thu, 5 Aug 2004 12:44:24 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i75GiOJq008051 for conary-list@lists.specifixinc.com; Thu, 5 Aug 2004 12:44:24 -0400 Date: Thu, 5 Aug 2004 12:44:24 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040805164423.GA7942@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: CVS repository commit lists added X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2004 16:44:00 -0000 We have added three mailing lists to the list server: http://lists.specifixinc.com/mailman/listinfo/conary-commits http://lists.specifixinc.com/mailman/listinfo/conary-repository-commits http://lists.specifixinc.com/mailman/listinfo/conary-gui-commits You can subscribe to any of those lists to see what is changing in Conary-land. Please do not post to these lists! Honor the followup header that points here, to conary-list. In addition, we have added viewcvs access to the conary-gui repository, something we were missing before. All these changes are documented on our wiki. You can subscribe to the wiki and get email updates. Merely create a username on the wiki by clicking on "UserPreferences" at the upper right corner and filling in a name and password; you can then change your preferences to subscribe to ".*" and you will be notified automatically about changes to the wiki by email. From johnsonm@specifixinc.com Thu Aug 5 12:53:23 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i75GrMbI013920 for ; Thu, 5 Aug 2004 12:53:22 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 069951675B for ; Thu, 5 Aug 2004 09:53:49 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i75GrlTD008287 for ; Thu, 5 Aug 2004 12:53:47 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i75GrlG5008285 for conary-list@lists.specifixinc.com; Thu, 5 Aug 2004 12:53:47 -0400 Date: Thu, 5 Aug 2004 12:53:47 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040805165347.GB7942@lambchop.rdu.specifixinc.com> References: <20040805144017.GB32522@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040805144017.GB32522@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: Use flags issue X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2004 16:53:23 -0000 On Thu, Aug 05, 2004 at 10:40:17AM -0400, David B. Christian wrote: > I'm not sure whether this is a big deal or not -- it's not quite clear how > which Use flags are used is important to a package. If several Use flags > would trigger the same branch, e.g. in the case: If Use.a or Use.b or Use.c: Python can do bitwise operations on booleans, and that will not be short-circuited, so for any places where it matters, we can do: if (Use.a | Use.b | Use.c): Make sense? From david.christian@gmail.com Thu Aug 5 13:05:03 2004 Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i75H52bI013988 for ; Thu, 5 Aug 2004 13:05:03 -0400 Received: by mproxy.gmail.com with SMTP id 76so17808rnk for ; Thu, 05 Aug 2004 10:05:26 -0700 (PDT) Received: by 10.38.86.1 with SMTP id j1mr132765rnb; Thu, 05 Aug 2004 10:05:25 -0700 (PDT) Message-ID: <63940b0040805100527c0d8b3@mail.gmail.com> Date: Thu, 5 Aug 2004 13:05:25 -0400 From: David Christian To: Conary Discussion In-Reply-To: <20040805165347.GB7942@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040805144017.GB32522@lambchop.rdu.specifixinc.com> <20040805165347.GB7942@lambchop.rdu.specifixinc.com> Subject: Re: Use flags issue X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2004 17:05:03 -0000 > Python can do bitwise operations on booleans, and that will not be > short-circuited, so for any places where it matters, we can do: > if (Use.a | Use.b | Use.c): > Well, yes, as long as we don't allow: if Use.a: if Use.b: if Use.c: It seems to me that this might actually be a non-issue -- a package flavor need only mention those flags that are critical to that particular flavor. So you might have on flavor be "not a", and another be "a and not b", and another be "a and b and c". Does that seem reasonable? From johnsonm@specifixinc.com Thu Aug 5 15:20:10 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i75JK9bI014169 for ; Thu, 5 Aug 2004 15:20:09 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 847DD162A1 for ; Thu, 5 Aug 2004 12:20:36 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i75JKZTD012030 for ; Thu, 5 Aug 2004 15:20:35 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i75JKZHH012028 for conary-list@lists.specifixinc.com; Thu, 5 Aug 2004 15:20:35 -0400 Date: Thu, 5 Aug 2004 15:20:35 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040805192035.GA11237@lambchop.rdu.specifixinc.com> References: <20040805144017.GB32522@lambchop.rdu.specifixinc.com> <20040805165347.GB7942@lambchop.rdu.specifixinc.com> <63940b0040805100527c0d8b3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63940b0040805100527c0d8b3@mail.gmail.com> User-Agent: Mutt/1.4.1i Subject: Re: Use flags issue X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2004 19:20:10 -0000 On Thu, Aug 05, 2004 at 01:05:25PM -0400, David Christian wrote: > Well, yes, as long as we don't allow: > > if Use.a: > if Use.b: > if Use.c: Well, "allow" is strong. In those rare cases where this is actually an issue, you could add useRef = (Use.a | Use.b | Use.c) or such at the top of the recipe. > It seems to me that this might actually be a non-issue -- a package > flavor need only mention those flags that are critical to that > particular flavor. So you might have on flavor be "not a", and > another be "a and not b", and another be "a and b and c". That's what I expect to be the common case. From ewt@specifixinc.com Thu Aug 12 11:45:28 2004 Received: from bluesmobile.specifixinc.com ([64.62.200.227]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7CFjRbI017444 for ; Thu, 12 Aug 2004 11:45:27 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 5E09916759 for ; Thu, 12 Aug 2004 08:46:02 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7CFk1TD024743 for ; Thu, 12 Aug 2004 11:46:01 -0400 Received: from localhost (ewt@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) with ESMTP id i7CFk1ns024733 for ; Thu, 12 Aug 2004 11:46:01 -0400 X-Authentication-Warning: lambchop.rdu.specifixinc.com: ewt owned process doing -bs Date: Thu, 12 Aug 2004 11:46:01 -0400 (EDT) From: ewt@specifixinc.com X-X-Sender: ewt@lambchop.rdu.specifixinc.com To: Conary Discussion In-Reply-To: <20040805192035.GA11237@lambchop.rdu.specifixinc.com> Message-ID: References: <20040805144017.GB32522@lambchop.rdu.specifixinc.com> <20040805165347.GB7942@lambchop.rdu.specifixinc.com> <63940b0040805100527c0d8b3@mail.gmail.com> <20040805192035.GA11237@lambchop.rdu.specifixinc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Thu, 12 Aug 2004 14:09:14 -0400 Subject: Re: Use flags issue X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 15:45:28 -0000 On Thu, 5 Aug 2004, Michael K. Johnson wrote: > > It seems to me that this might actually be a non-issue -- a package > > flavor need only mention those flags that are critical to that > > particular flavor. So you might have on flavor be "not a", and > > another be "a and not b", and another be "a and b and c". > > That's what I expect to be the common case. Here is my (very late) $0.02.... This is actually preferable, as you don't have a "not and not b" case, which is nonsensical for this example. Erik From ken@biZrace.com Fri Aug 13 23:34:25 2004 Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7E3YPbI025162 for ; Fri, 13 Aug 2004 23:34:25 -0400 Received: from [192.168.1.103] (cpe-024-163-091-077.nc.rr.com [24.163.91.77]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i7E3YxNr027380 for ; Fri, 13 Aug 2004 23:35:00 -0400 (EDT) Message-ID: <411D8828.7060707@biZrace.com> Date: Fri, 13 Aug 2004 23:34:00 -0400 From: Ken VanDine User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: conary-list@lists.specifixinc.com Content-Type: multipart/alternative; boundary="------------060603030809020603080103" X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: commit to contrib, not launching vi for message X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2004 03:34:25 -0000 This is a multi-part message in MIME format. --------------060603030809020603080103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This failed, using conary 0.7.0 committing to contrib: [ken@snickers libgphoto2]$ conary src commit Traceback (most recent call last): File "/usr/share/conary/conary", line 21, in ? sys.exit(conary.main()) File "/usr/share/conary/conary.py", line 465, in main realMain() File "/usr/share/conary/conary.py", line 426, in realMain return srcctl.sourceCommand(cfg, otherArgs[2:], argSet) File "/usr/share/conary/srcctl.py", line 67, in sourceCommand checkin.commit(repos, cfg, message) File "/usr/share/conary/checkin.py", line 272, in commit cl = changelog.ChangeLog(cfg.name, cfg.contact, message) File "/usr/share/conary/changelog.py", line 100, in __init__ self.setMessage(message) File "/usr/share/conary/changelog.py", line 46, in setMessage assert(value[-1] == '\n') TypeError: unsubscriptable object > /usr/share/conary/changelog.py(46)setMessage() -> assert(value[-1] == '\n') (Pdb) Error in sys.excepthook: Traceback (most recent call last): File "/usr/share/conary/util.py", line 94, in excepthook pdb.post_mortem(tb) File "/usr/lib/python2.3/pdb.py", line 1001, in post_mortem p.interaction(t.tb_frame, t) File "/usr/lib/python2.3/pdb.py", line 149, in interaction self.cmdloop() File "/usr/lib/python2.3/cmd.py", line 121, in cmdloop line = raw_input(self.prompt) KeyboardInterrupt Original exception was: Traceback (most recent call last): File "/usr/share/conary/conary", line 21, in ? sys.exit(conary.main()) File "/usr/share/conary/conary.py", line 465, in main realMain() File "/usr/share/conary/conary.py", line 426, in realMain return srcctl.sourceCommand(cfg, otherArgs[2:], argSet) File "/usr/share/conary/srcctl.py", line 67, in sourceCommand checkin.commit(repos, cfg, message) File "/usr/share/conary/checkin.py", line 272, in commit cl = changelog.ChangeLog(cfg.name, cfg.contact, message) File "/usr/share/conary/changelog.py", line 100, in __init__ self.setMessage(message) File "/usr/share/conary/changelog.py", line 46, in setMessage assert(value[-1] == '\n') TypeError: unsubscriptable object [ken@snickers libgphoto2]$ conary src commit Traceback (most recent call last): File "/usr/share/conary/conary", line 21, in ? sys.exit(conary.main()) File "/usr/share/conary/conary.py", line 465, in main realMain() File "/usr/share/conary/conary.py", line 426, in realMain return srcctl.sourceCommand(cfg, otherArgs[2:], argSet) File "/usr/share/conary/srcctl.py", line 67, in sourceCommand checkin.commit(repos, cfg, message) File "/usr/share/conary/checkin.py", line 272, in commit cl = changelog.ChangeLog(cfg.name, cfg.contact, message) File "/usr/share/conary/changelog.py", line 100, in __init__ self.setMessage(message) File "/usr/share/conary/changelog.py", line 46, in setMessage assert(value[-1] == '\n') TypeError: unsubscriptable object > /usr/share/conary/changelog.py(46)setMessage() -> assert(value[-1] == '\n') (Pdb) Error in sys.excepthook: Traceback (most recent call last): File "/usr/share/conary/util.py", line 94, in excepthook pdb.post_mortem(tb) File "/usr/lib/python2.3/pdb.py", line 1001, in post_mortem p.interaction(t.tb_frame, t) File "/usr/lib/python2.3/pdb.py", line 149, in interaction self.cmdloop() File "/usr/lib/python2.3/cmd.py", line 121, in cmdloop line = raw_input(self.prompt) KeyboardInterrupt Original exception was: Traceback (most recent call last): File "/usr/share/conary/conary", line 21, in ? sys.exit(conary.main()) File "/usr/share/conary/conary.py", line 465, in main realMain() File "/usr/share/conary/conary.py", line 426, in realMain return srcctl.sourceCommand(cfg, otherArgs[2:], argSet) File "/usr/share/conary/srcctl.py", line 67, in sourceCommand checkin.commit(repos, cfg, message) File "/usr/share/conary/checkin.py", line 272, in commit cl = changelog.ChangeLog(cfg.name, cfg.contact, message) File "/usr/share/conary/changelog.py", line 100, in __init__ self.setMessage(message) File "/usr/share/conary/changelog.py", line 46, in setMessage assert(value[-1] == '\n') TypeError: unsubscriptable object This worked: [ken@snickers libgphoto2]$ conary src commit --message "Added libgphoto2, required by gthumb" --------------060603030809020603080103 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit This failed, using conary 0.7.0 committing to contrib:

[ken@snickers libgphoto2]$ conary src commit
Traceback (most recent call last):
  File "/usr/share/conary/conary", line 21, in ?
    sys.exit(conary.main())
  File "/usr/share/conary/conary.py", line 465, in main
    realMain()
  File "/usr/share/conary/conary.py", line 426, in realMain
    return srcctl.sourceCommand(cfg, otherArgs[2:], argSet)
  File "/usr/share/conary/srcctl.py", line 67, in sourceCommand
    checkin.commit(repos, cfg, message)
  File "/usr/share/conary/checkin.py", line 272, in commit
    cl = changelog.ChangeLog(cfg.name, cfg.contact, message)
  File "/usr/share/conary/changelog.py", line 100, in __init__
    self.setMessage(message)
  File "/usr/share/conary/changelog.py", line 46, in setMessage
    assert(value[-1] == '\n')
TypeError: unsubscriptable object

> /usr/share/conary/changelog.py(46)setMessage()
-> assert(value[-1] == '\n')
(Pdb) Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/share/conary/util.py", line 94, in excepthook
    pdb.post_mortem(tb)
  File "/usr/lib/python2.3/pdb.py", line 1001, in post_mortem
    p.interaction(t.tb_frame, t)
  File "/usr/lib/python2.3/pdb.py", line 149, in interaction
    self.cmdloop()
  File "/usr/lib/python2.3/cmd.py", line 121, in cmdloop
    line = raw_input(self.prompt)
KeyboardInterrupt

Original exception was:
Traceback (most recent call last):
  File "/usr/share/conary/conary", line 21, in ?
    sys.exit(conary.main())
  File "/usr/share/conary/conary.py", line 465, in main
    realMain()
  File "/usr/share/conary/conary.py", line 426, in realMain
    return srcctl.sourceCommand(cfg, otherArgs[2:], argSet)
  File "/usr/share/conary/srcctl.py", line 67, in sourceCommand
    checkin.commit(repos, cfg, message)
  File "/usr/share/conary/checkin.py", line 272, in commit
    cl = changelog.ChangeLog(cfg.name, cfg.contact, message)
  File "/usr/share/conary/changelog.py", line 100, in __init__
    self.setMessage(message)
  File "/usr/share/conary/changelog.py", line 46, in setMessage
    assert(value[-1] == '\n')
TypeError: unsubscriptable object
[ken@snickers libgphoto2]$ conary src commit
Traceback (most recent call last):
  File "/usr/share/conary/conary", line 21, in ?
    sys.exit(conary.main())
  File "/usr/share/conary/conary.py", line 465, in main
    realMain()
  File "/usr/share/conary/conary.py", line 426, in realMain
    return srcctl.sourceCommand(cfg, otherArgs[2:], argSet)
  File "/usr/share/conary/srcctl.py", line 67, in sourceCommand
    checkin.commit(repos, cfg, message)
  File "/usr/share/conary/checkin.py", line 272, in commit
    cl = changelog.ChangeLog(cfg.name, cfg.contact, message)
  File "/usr/share/conary/changelog.py", line 100, in __init__
    self.setMessage(message)
  File "/usr/share/conary/changelog.py", line 46, in setMessage
    assert(value[-1] == '\n')
TypeError: unsubscriptable object

> /usr/share/conary/changelog.py(46)setMessage()
-> assert(value[-1] == '\n')
(Pdb) Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/share/conary/util.py", line 94, in excepthook
    pdb.post_mortem(tb)
  File "/usr/lib/python2.3/pdb.py", line 1001, in post_mortem
    p.interaction(t.tb_frame, t)
  File "/usr/lib/python2.3/pdb.py", line 149, in interaction
    self.cmdloop()
  File "/usr/lib/python2.3/cmd.py", line 121, in cmdloop
    line = raw_input(self.prompt)
KeyboardInterrupt

Original exception was:
Traceback (most recent call last):
  File "/usr/share/conary/conary", line 21, in ?
    sys.exit(conary.main())
  File "/usr/share/conary/conary.py", line 465, in main
    realMain()
  File "/usr/share/conary/conary.py", line 426, in realMain
    return srcctl.sourceCommand(cfg, otherArgs[2:], argSet)
  File "/usr/share/conary/srcctl.py", line 67, in sourceCommand
    checkin.commit(repos, cfg, message)
  File "/usr/share/conary/checkin.py", line 272, in commit
    cl = changelog.ChangeLog(cfg.name, cfg.contact, message)
  File "/usr/share/conary/changelog.py", line 100, in __init__
    self.setMessage(message)
  File "/usr/share/conary/changelog.py", line 46, in setMessage
    assert(value[-1] == '\n')
TypeError: unsubscriptable object

This worked:
[ken@snickers libgphoto2]$ conary src commit --message "Added libgphoto2, required by gthumb"

 --------------060603030809020603080103-- From ewt@specifixinc.com Mon Aug 16 19:58:58 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7GNwvbI002742 for ; Mon, 16 Aug 2004 19:58:57 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 35C181654A for ; Mon, 16 Aug 2004 16:59:36 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7GNxYTD026022 for ; Mon, 16 Aug 2004 19:59:34 -0400 Received: from localhost (ewt@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) with ESMTP id i7GNxYJB026018 for ; Mon, 16 Aug 2004 19:59:34 -0400 X-Authentication-Warning: lambchop.rdu.specifixinc.com: ewt owned process doing -bs Date: Mon, 16 Aug 2004 19:59:34 -0400 (EDT) From: ewt@specifixinc.com X-X-Sender: ewt@lambchop.rdu.specifixinc.com To: Conary Discussion In-Reply-To: <411D8828.7060707@biZrace.com> Message-ID: References: <411D8828.7060707@biZrace.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Mon, 16 Aug 2004 20:55:40 -0400 Subject: Re: commit to contrib, not launching vi for message X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2004 23:58:58 -0000 This should be fixed on head. Erik On Fri, 13 Aug 2004, Ken VanDine wrote: > This failed, using conary 0.7.0 committing to contrib: > > [ken@snickers libgphoto2]$ conary src commit > Traceback (most recent call last): > File "/usr/share/conary/conary", line 21, in ? > sys.exit(conary.main()) > File "/usr/share/conary/conary.py", line 465, in main > realMain() > File "/usr/share/conary/conary.py", line 426, in realMain > return srcctl.sourceCommand(cfg, otherArgs[2:], argSet) > File "/usr/share/conary/srcctl.py", line 67, in sourceCommand > checkin.commit(repos, cfg, message) > File "/usr/share/conary/checkin.py", line 272, in commit > cl = changelog.ChangeLog(cfg.name, cfg.contact, message) > File "/usr/share/conary/changelog.py", line 100, in __init__ > self.setMessage(message) > File "/usr/share/conary/changelog.py", line 46, in setMessage > assert(value[-1] == '\n') > TypeError: unsubscriptable object > > > /usr/share/conary/changelog.py(46)setMessage() > -> assert(value[-1] == '\n') > (Pdb) Error in sys.excepthook: > Traceback (most recent call last): > File "/usr/share/conary/util.py", line 94, in excepthook > pdb.post_mortem(tb) > File "/usr/lib/python2.3/pdb.py", line 1001, in post_mortem > p.interaction(t.tb_frame, t) > File "/usr/lib/python2.3/pdb.py", line 149, in interaction > self.cmdloop() > File "/usr/lib/python2.3/cmd.py", line 121, in cmdloop > line = raw_input(self.prompt) > KeyboardInterrupt > > Original exception was: > Traceback (most recent call last): > File "/usr/share/conary/conary", line 21, in ? > sys.exit(conary.main()) > File "/usr/share/conary/conary.py", line 465, in main > realMain() > File "/usr/share/conary/conary.py", line 426, in realMain > return srcctl.sourceCommand(cfg, otherArgs[2:], argSet) > File "/usr/share/conary/srcctl.py", line 67, in sourceCommand > checkin.commit(repos, cfg, message) > File "/usr/share/conary/checkin.py", line 272, in commit > cl = changelog.ChangeLog(cfg.name, cfg.contact, message) > File "/usr/share/conary/changelog.py", line 100, in __init__ > self.setMessage(message) > File "/usr/share/conary/changelog.py", line 46, in setMessage > assert(value[-1] == '\n') > TypeError: unsubscriptable object > [ken@snickers libgphoto2]$ conary src commit > Traceback (most recent call last): > File "/usr/share/conary/conary", line 21, in ? > sys.exit(conary.main()) > File "/usr/share/conary/conary.py", line 465, in main > realMain() > File "/usr/share/conary/conary.py", line 426, in realMain > return srcctl.sourceCommand(cfg, otherArgs[2:], argSet) > File "/usr/share/conary/srcctl.py", line 67, in sourceCommand > checkin.commit(repos, cfg, message) > File "/usr/share/conary/checkin.py", line 272, in commit > cl = changelog.ChangeLog(cfg.name, cfg.contact, message) > File "/usr/share/conary/changelog.py", line 100, in __init__ > self.setMessage(message) > File "/usr/share/conary/changelog.py", line 46, in setMessage > assert(value[-1] == '\n') > TypeError: unsubscriptable object > > > /usr/share/conary/changelog.py(46)setMessage() > -> assert(value[-1] == '\n') > (Pdb) Error in sys.excepthook: > Traceback (most recent call last): > File "/usr/share/conary/util.py", line 94, in excepthook > pdb.post_mortem(tb) > File "/usr/lib/python2.3/pdb.py", line 1001, in post_mortem > p.interaction(t.tb_frame, t) > File "/usr/lib/python2.3/pdb.py", line 149, in interaction > self.cmdloop() > File "/usr/lib/python2.3/cmd.py", line 121, in cmdloop > line = raw_input(self.prompt) > KeyboardInterrupt > > Original exception was: > Traceback (most recent call last): > File "/usr/share/conary/conary", line 21, in ? > sys.exit(conary.main()) > File "/usr/share/conary/conary.py", line 465, in main > realMain() > File "/usr/share/conary/conary.py", line 426, in realMain > return srcctl.sourceCommand(cfg, otherArgs[2:], argSet) > File "/usr/share/conary/srcctl.py", line 67, in sourceCommand > checkin.commit(repos, cfg, message) > File "/usr/share/conary/checkin.py", line 272, in commit > cl = changelog.ChangeLog(cfg.name, cfg.contact, message) > File "/usr/share/conary/changelog.py", line 100, in __init__ > self.setMessage(message) > File "/usr/share/conary/changelog.py", line 46, in setMessage > assert(value[-1] == '\n') > TypeError: unsubscriptable object > > This worked: > [ken@snickers libgphoto2]$ conary src commit --message "Added > libgphoto2, required by gthumb" > > From johnsonm@specifixinc.com Tue Aug 24 19:19:49 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7ONJmbI027040 for ; Tue, 24 Aug 2004 19:19:48 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 09FCF1677E for ; Tue, 24 Aug 2004 16:20:37 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7ONKZTD030369 for ; Tue, 24 Aug 2004 19:20:35 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i7ONKZps030367 for conary-list@lists.specifixinc.com; Tue, 24 Aug 2004 19:20:35 -0400 Date: Tue, 24 Aug 2004 19:20:35 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040824232035.GA28570@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Categorizing flags X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 23:19:49 -0000 We have a todo item for implementing a richer syntax for flags, encoded on the wiki as "~flag as supported but not required". In order to think about this, I started to work on matrices of possibilities for different flag settings. As I started to fill in various matrices, I realized that we might need to better categorize our existing Use flags. This email attempts to (re)categorize what we have into categories: o Feature existance (library such as pam, program such as ImageMagick) o Capability (of system or library, such as NPTL) o Configuration (of distribution, such as builddocs or dietlibc) For each flag, we have four cases to consider: 1,0) Package has flag set, system has flag unset 1,1) Package has flag set, system has flag set 0,0) Package has flag unset, system has flag unset 0,1) Package has flag unset, system has flag set For each of those cases, we have a possible outcome: D) Disqualify immediately, without further consideration +) Adds "goodness" -) Subtracts "goodness" x) Don't care The "goodness" is a value (possible configuration-dependent, but with a default value) added to or subtracted from a weight assigned to each flavor. Notice that while there is immediate disqualification, there is no immediate qualification. This is an assymetric process. My idea is that when there is not an existing version of a trove installed, then for each candidate trove, each flag is considered (except when consideratino of a single candidate trove is cut short by an immediate disqualification), and the trove with the best weight wins. When there is an existing version of a trove, however, the same configuration will be chosen by default, perhaps even to the default exclusion of an upgrade if that particular flavor does not exist for a new version. That's debateable, though. I also think that how much weight is added/subtracted for each flag could be a system configuration item. Here's my first attempt to place all of our existing flags (so far) into these categories and to enumerate the values of the cases. This is not well-thought-out yet; it is just an initial attempt and I'd love to get feedback, most especially counter-examples. Feature existance Unless otherwise stated: 1,0) D; 1,1) +; 0,1) x; 0,0; x In english: Package has flag set, system has flag unset: Disqualify Package has flag set, system has flag set: Add goodness Package has flag unset, system has flag set: Don't care Package has flag unset, system has flag unset: Don't care Use.pcre Use.tcpwrappers Use.gcj Use.gnat Use.selinux 0,1) D (Package has flag unset, system has flag set: Disqualify) Use.pam 0,1) D Use.python Use.perl Use.readline Use.gdbm Use.emacs Use.krb Use.tcl Use.tk Use.X Use.gtk Use.gnome Use.qt Use.kde Use.xfce Use.gd Use.ldap Use.sasl Use.ssl Use.slang Use.netpbm Capability Use.nptl 1,0) D; 1,1) +; 0,1) -; 0,0; + In english: Package uses nptl, system does not provide nptl: Disqualify Package uses nptl, system provides nptl: Add goodness (good match) Package does not use nptl, system provides it: Subtract goodness (There's probably a better match) Neither package nor system implement nptl: Add goodness Use.ipv6 1,0) D; 1,1) +; 0,1) x; 0,0; x Use.alternatives 1,0) D; 1,1) +; 0,1) x; 0,0; x Configuration Use.pie 1,0) x; 1,1) +; 0,1) x; 0,0; + Use.dietlibc 1,0) D; 1,1) +; 0,1) D; 0,0; + Use.bootstrap 1,0) -; 1,1) +; 0,1) -; 0,0; + Use.builddocs 1,0) +; 1,1) +; 0,1) -; 0,0; - In general, docs are preffered to not docs (to not install docs, choose not to install :doc components, don't prefr packages with !builddocs) Use.buildtests 1,0) +; 1,1) +; 0,1) -; 0,0; - {linux-,}kernel.debug 1,0) x; 1,1) +; 0,1) x; 0,0; + Use.desktop (follows freedesktop.org standards) 1,0) x; 1,1) +; 0,1) x; 0,0; + Once we get agreement on the semantics we are tryign to establish, it won't be too hard to set up syntax to express the semantics, I expect. From ian@airs.com Tue Aug 24 23:28:29 2004 Received: from yosemite.airs.com (yosemite.airs.com [209.128.65.135]) by lists.specifixinc.com (8.12.10/8.12.10) with SMTP id i7P3SSbI027338 for ; Tue, 24 Aug 2004 23:28:29 -0400 Received: (qmail 6979 invoked by uid 10); 25 Aug 2004 03:29:17 -0000 Received: (qmail 15881 invoked by uid 500); 25 Aug 2004 03:29:09 -0000 To: Conary Discussion References: <20040824232035.GA28570@lambchop.rdu.specifixinc.com> From: Ian Lance Taylor Date: 24 Aug 2004 23:29:09 -0400 In-Reply-To: <20040824232035.GA28570@lambchop.rdu.specifixinc.com> Message-ID: Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Categorizing flags X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 03:28:29 -0000 "Michael K. Johnson" writes: > As I started to fill in various matrices, I realized that we might need > to better categorize our existing Use flags. This email attempts to > (re)categorize what we have into categories: >From my outside perspective, describing everything as Use flags seems confusing to me. In the general case, configuration decisions are not "set" or "unset". They are tri-state: "true", "false", or "unspecified". It seems to me that specifying any configuration decision implies finding a set of packages which implement that decision. Thus, any packages can be marked as setting a decision to be true, or setting a decision to be false. Also, packages can require a decision to be true or false, without setting it. Also, packages can prefer a decision to be true or false, without requiring or setting it. Also, packages can modify their behaviour depending upon a particular decision, without preferring, requiring, or setting it. So, generalizing, we can say for each configuration decision which is specified find set of packages which set that decision if specified true add packages which set it true to add_list add packages which set it false to exclude_list else add packages which set it true to exclude_list add packages which set it false to add_list subtract all packages in exclude_list from add_list for each configuration decision which is specified if any package in add_list requires that decision to be a value opposite to that specified, remove it from add_list for each configuration decision which is specified if no packages in add_list sets that decision appropriately we have a problem Then we can use preferences to choose specific packages out of a set of available packages. One could imaging doing this using some sort of annealing process over requirements and preferences, and contradictions betwwen decisions which are set, but that is probably overkill. Ian From johnsonm@specifixinc.com Wed Aug 25 10:56:43 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7PEugbI028570 for ; Wed, 25 Aug 2004 10:56:42 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id A5A8C16778 for ; Wed, 25 Aug 2004 07:57:31 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7PEvUTD018166 for ; Wed, 25 Aug 2004 10:57:30 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i7PEvU3K018164 for conary-list@lists.specifixinc.com; Wed, 25 Aug 2004 10:57:30 -0400 Date: Wed, 25 Aug 2004 10:57:30 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040825145730.GA17874@lambchop.rdu.specifixinc.com> References: <20040824232035.GA28570@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: Categorizing flags X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 14:56:43 -0000 On Tue, Aug 24, 2004 at 11:29:09PM -0400, Ian Lance Taylor wrote: > In the general case, configuration decisions are not "set" or "unset". > They are tri-state: "true", "false", or "unspecified". Correct. In most packages, most flags are unspecified. This work here is to define how to deal with the *specified* cases; true or false. Take a look at the output of "conary -rq --all" -- you'll see use: in places. One of the first things you will notice is that for the majority of packages, there is no "use:" line at all. For those that do have a "use:" line, you'll see that it's usually only 1-3 items. In terms of finding packages that match, we have a restricted set we are considering. Use flags, like architecture flags, are part of "flavors". Basically, each node on the version tree can hold multiple flavors. This is about choosing the best flavor on a node. One reason we are using configuration flags to choose flavors is to cut short lengthy dependency calculations -- instead of getting halfway through dependency calculation and discovering that the system does not provide libfoo, we can see that there is a flavor disparity in terms of Use.foo and we can avoid that whole dependency search. It's important to be able to cut the dependency search down to size, otherwise the resolution time will go exponential with flavors. Because flag space is much smaller and is restricted to specified flags, the base and exponent are so small that it doesn't matter, I think that it's actually log(n) normal case (with very small n), and the search has very good locality because all the information is in one place, unlike searching (potentially) the whole database for dependencies that aren't there. Does that help explain what I'm up to? From johnsonm@specifixinc.com Wed Aug 25 11:00:49 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7PF0nbI028587 for ; Wed, 25 Aug 2004 11:00:49 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 87F3016782 for ; Wed, 25 Aug 2004 08:01:38 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7PF1bTD018338 for ; Wed, 25 Aug 2004 11:01:37 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i7PF1bnE018336 for conary-list@lists.specifixinc.com; Wed, 25 Aug 2004 11:01:37 -0400 Date: Wed, 25 Aug 2004 11:01:37 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040825150137.GB17874@lambchop.rdu.specifixinc.com> References: <20040824232035.GA28570@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: Categorizing flags X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 15:00:49 -0000 On Tue, Aug 24, 2004 at 11:29:09PM -0400, Ian Lance Taylor wrote: > So, generalizing, we can say > for each configuration decision which is specified > find set of packages which set that decision > if specified true > add packages which set it true to add_list > add packages which set it false to exclude_list > else > add packages which set it true to exclude_list > add packages which set it false to add_list > subtract all packages in exclude_list from add_list > for each configuration decision which is specified > if any package in add_list requires that decision to be a value > opposite to that specified, remove it from add_list > for each configuration decision which is specified > if no packages in add_list sets that decision appropriately > we have a problem I should have been clearer about this part: this is a different problem than the one I'm trying to solve. I'm not trying to select packages or create package sets. The problem I'm trying to solve is: "Given a version of a trove, remove the flavors that we know (from flavor information alone) cannot be installed on this system, and weight the rest. Then a separate step of dependency resolution can go through the weighted list of flavors in order, and find the first one for which dependency resolution succeeds." From ewt@specifixinc.com Mon Aug 30 19:25:07 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7UNP7bI005398; Mon, 30 Aug 2004 19:25:07 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id A9DE716399; Mon, 30 Aug 2004 16:26:02 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i7UNQ1NI016081; Mon, 30 Aug 2004 19:26:01 -0400 Received: from localhost (ewt@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) with ESMTP id i7UNPiHM015996; Mon, 30 Aug 2004 19:26:01 -0400 X-Authentication-Warning: lambchop.rdu.specifixinc.com: ewt owned process doing -bs Date: Mon, 30 Aug 2004 19:25:44 -0400 (EDT) From: ewt@specifixinc.com X-X-Sender: ewt@lambchop.rdu.specifixinc.com To: conary-list@lists.specifixinc.com In-Reply-To: <200408302118.i7ULIGut011383@lambchop.rdu.specifixinc.com> Message-ID: References: <200408302118.i7ULIGut011383@lambchop.rdu.specifixinc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: synccvs@specifixinc.com, conary-commits@lists.specifixinc.com Subject: Re: conary/local update.py,1.149,1.150 X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 23:25:08 -0000 On Mon, 30 Aug 2004, Matt Wilson wrote: > + elif (not isinstance(headFile, files.Directory) > + and stat.S_ISDIR(s.st_mode) and s.st_nlink > 2): > + # this is a non-empty directory that's in the way of > + # a new file. Even --replace-files can't help here > + self.errors.append("non-empty directory %s is in " > + "the way of a newly created " > + "file" % headRealPath) This check doesn't tell you that file is empty, just that in doesn't contain any subdirectories... Erik From johnsonm@specifixinc.com Fri Sep 3 16:07:58 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i83K7vbI028046 for ; Fri, 3 Sep 2004 16:07:58 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id E803C16399 for ; Fri, 3 Sep 2004 13:08:57 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i83K8uNI031335 for ; Fri, 3 Sep 2004 16:08:56 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i83K8uqa031333 for conary-list@lists.specifixinc.com; Fri, 3 Sep 2004 16:08:56 -0400 Date: Fri, 3 Sep 2004 16:08:56 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 20:07:58 -0000 OK, we need to handle users and groups. We'd like to do this in a very different way from RPM -- we want to separate data from the mechanism that acts on it. This can't just use tags and handlers, because of too many chicken/egg problems. First, we need to define the information that a packager can set, without regard to where it is put, or how it is acted on. I think that package-specified users/groups shouldn't have passwords or shadow stuff like expiry. We should also not create home directories for such users; those directories should be packaged instead. Also, since we should always suggest a uid, -r doesn't make sense. So thinking in terms of useradd options, we want to allow people to specify: -u preferred user id -g group (but only by name) -G required supplemental group list (but only additions) -c comment -d home dir -s shell (default for packaged users should be /sbin/nologin) So the changes IRT command-line option semantics will be for -g, we only allow a name; for -G, we only list additions to the group list required for the package, and for -s, we default to /sbin/nologin -G is special. -u, -g, -c, -d, and -s are used only when creating the user. -G, if specified, provides groups that must be added to the specified. (This brings up a question: if the package adds a member to a supplemental group list, and the sysadmin removes that membership, can we preserve the sysadmin's choice when upgrading that package? The good news is that this is a VERY unusual case; I've only ever seen this from a packaging standpoint once that I can remember.) For groups, it's much simpler: -g preferred group id We should never remove users or groups -- that's a security risk. If a user or group is removed from the system database, but a file (or other resource) is left owned by that user/group, then when another different user or group is added and re-uses the number, they can access the file (or other resource). The consequences of that access cannot be known in general. Now, mechanism. The idea that Erik came up with is to have a per-component table containing this information (consider the user/group names as indexes into this table) for all non-root permissions. Then, on installed systems, we can have scripts which drive the mechanism, based on the information in those tables. For bootstrapping the install, before the policy scripts exist, there needs to be a fallback; conary has to have the ability to edit the user/group files itself. Any thoughts? From msw@specifixinc.com Tue Sep 7 16:38:25 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i87KcObI018598 for ; Tue, 7 Sep 2004 16:38:25 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 3E2031649A for ; Tue, 7 Sep 2004 13:39:29 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i87KdRNI014467 for ; Tue, 7 Sep 2004 16:39:27 -0400 Received: (from msw@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i87KdR0c014465 for conary-list@lists.specifixinc.com; Tue, 7 Sep 2004 16:39:27 -0400 Date: Tue, 7 Sep 2004 16:39:27 -0400 From: Matt Wilson To: conary-list@lists.specifixinc.com Message-ID: <20040907203927.GA13731@specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Conary 0.9.3 available X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 20:38:25 -0000 Changes in 0.9.3: * New "cvc annotate" feature * Man page updates * Changesets which remove a file and replace it now apply correctly. * "cvc update" no longer complains and fails to update the CONARY state file properly when ownerships differ * FileId generation now looks for previous versions of all the packages that have just been created, not just the name of the recipe. * Cooking as root is no longer allowed * Miscellaneous bug fixes. ftp://download.specifixinc.com/pub/specifix/conary/conary-0.9.3.tar.bz2 Cheers, Matt From johnsonm@specifixinc.com Tue Sep 7 16:40:35 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i87KeZbI018616 for ; Tue, 7 Sep 2004 16:40:35 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id A0B481649A for ; Tue, 7 Sep 2004 13:41:39 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i87KfcNI014509 for ; Tue, 7 Sep 2004 16:41:38 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i87Kfc6v014507 for conary-list@lists.specifixinc.com; Tue, 7 Sep 2004 16:41:38 -0400 Date: Tue, 7 Sep 2004 16:41:38 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040907204138.GA13643@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: dependencies: IRC summary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 20:40:35 -0000 On IRC, we talked a lot about dependencies, particularly about the consequences of implementing something Erik talked about where an arbitrary string for Requires or Provides could be specified, which I called "virtual dependencies". For the sake of discussion, we used a leading "*" character to denote these, since there are other kinds of manual dependencies, such as DEP_CLASS_FILES, that we'll need to express. I said that leading "/" means DEP_CLASS_FILES, leading "*" means DEP_CLASS_VIRTUAL, and anything else is DEP_CLASS_TROVE -- just for the purposes of discussion. Justin Forbes suggested that in general, negating any form of dependency could be used to create a conflicts mechanism without having to add explicit storage for conflicts. We then started to get into the ramifications of using virtual dependencies for real, and realized that it quickly turned into a rats nest. The only real example we could come up with for needing it was something like: /usr/bin/blah requires component A:runtime built with patch foo, so: r.Requires('A:runtime', '/usr/bin/blah') r.Requires('*patch-foo', '/usr/bin/blah') But now imagine that you have A:runtime built without *patch-foo, and C:runtime built with *patch-foo -- the resolver might reasonably decide that C:runtime with *patch-foo plus A:runtime is what you need. Now you start to say that you have to reserve namespace within virtual dependencies, to get something like r.Requires('*A:runtime-patch-foo', '/usr/bin/blah') This is ugly. And if you accept prepending a "!" for negation, it gets worse. You start to need to create another table of virtual dependencies, with an index, just to be able to resolve negative entries in reasonable time. I think. When we tried to come up with examples for this, we quickly started confusing ourselves talking about the possibilities. So we came up with a new idea, and said that the packager should use a local use flag to encode this information in the flavor for the package: r.Requires('A:runtime(Use.A.foo)', '/usr/bin/blah') which properly encodes the information that A.recipe was cooked with A's local Flag foo = True. This also allows you to cook both flavors (with and without the patch) on the same version node, if you want, killing two birds with one stone. This basically means that we need to implement parameterized deps... In that context, we have had the idea for months that we'd be able to use parameterized deps for version comparisons. We said something like foo(>= 1.2.3-1-2). However, we don't really want to implement version comparison algorithms -- the repository tree has gotten us away from bad version comparison algorithms. Matt had the idea that we could cook all version number references in dependencies into the changeset into a full version reference, resolved against the repository at build time; this would allow comparisons to be meaningful in respect to the repository. It's not clear exactly how that would be implemented. Thoughts or comments? From johnsonm@specifixinc.com Tue Sep 7 17:06:07 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i87L66bI018692 for ; Tue, 7 Sep 2004 17:06:06 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 4253D16793 for ; Tue, 7 Sep 2004 14:07:11 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i87L79NI015783 for ; Tue, 7 Sep 2004 17:07:09 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i87L79Jf015781 for conary-list@lists.specifixinc.com; Tue, 7 Sep 2004 17:07:09 -0400 Date: Tue, 7 Sep 2004 17:07:09 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040907210709.GA15575@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: local use flags with decoupled repositories X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 21:06:07 -0000 A few of us have been discussing something we want to agree on the right solution for. Scenario: You have package A, built in repository 1 and repository 2 In repository 1, A is build with usefoo In repository 2, A is build with foo Package C, built in repository 1, requires A.usefoo Package D, built in repository 2, requires A.foo Problem: You can't install C and D on the same system without forcing it somehow Scenario (continued): You have installed A and C from repository 1. A new version of C comes out, but only repository 2 has the new version cooked. Problem: You cannot update only C from the version built on repository 1 to the version built on repository 2 without either: Changing the version of A you have installed Using some form of "force" to ignore dependency information I don't like the idea of limiting the set of possible local use flags to a predetermined set. However, it might make sense to maintain a central registry of some sort, and have conary warn if you are cooking with local use flags that are not in the registry. I don't want to make it *impossible* for people to create weird repositories that do not cooperate with the rest of the world, but I do want to make it *easy* for people to create good repositories that do cooperate with the rest of the world. From fedora64@leaper.linuxtx.org Tue Sep 7 17:24:23 2004 Received: from leaper.linuxtx.org (c-24-1-16-159.client.comcast.net [24.1.16.159]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i87LOMbI018725 for ; Tue, 7 Sep 2004 17:24:23 -0400 Received: from leaper.linuxtx.org (localhost.localdomain [127.0.0.1]) by leaper.linuxtx.org (8.12.11/8.12.11) with ESMTP id i87LPRlR010480 for ; Tue, 7 Sep 2004 16:25:27 -0500 Received: (from fedora64@localhost) by leaper.linuxtx.org (8.12.11/8.12.11/Submit) id i87LPRdi010479 for conary-list@lists.specifixinc.com; Tue, 7 Sep 2004 16:25:27 -0500 Date: Tue, 7 Sep 2004 16:25:27 -0500 From: "Justin M. Forbes" To: Conary Discussion Message-ID: <20040907212527.GB8766@linuxtx.org> References: <20040907210709.GA15575@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040907210709.GA15575@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Tue, 07 Sep 2004 17:31:07 -0400 Subject: Re: local use flags with decoupled repositories X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 21:24:24 -0000 On Tue, Sep 07, 2004 at 05:07:09PM -0400, Michael K. Johnson wrote: > > I don't like the idea of limiting the set of possible local use > flags to a predetermined set. However, it might make sense to > maintain a central registry of some sort, and have conary warn > if you are cooking with local use flags that are not in the > registry. > It seems that a central location for local use flags would be a great idea, but perhaps if it is voluntary then things will be easier on users. Do not warn on update, just on cook, and even then, just a warning. People who want to play well can comply, those who do not care about the rest of the world do not have to. > I don't want to make it *impossible* for people to create weird > repositories that do not cooperate with the rest of the world, > but I do want to make it *easy* for people to create good > repositories that do cooperate with the rest of the world. If compliance is encouraged, rather than enforced on the recipe maintainer, we should hear fewer complaints, and I would expect a reasonable amount of compliance from people who take pride in their work. Justin From johnsonm@specifixinc.com Tue Sep 7 17:41:31 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i87LfVbI018770 for ; Tue, 7 Sep 2004 17:41:31 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id B34F116793 for ; Tue, 7 Sep 2004 14:42:35 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i87LgYNI016810 for ; Tue, 7 Sep 2004 17:42:34 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i87LgYV0016808 for conary-list@lists.specifixinc.com; Tue, 7 Sep 2004 17:42:34 -0400 Date: Tue, 7 Sep 2004 17:42:34 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040907214234.GA16652@lambchop.rdu.specifixinc.com> References: <20040907210709.GA15575@lambchop.rdu.specifixinc.com> <20040907212527.GB8766@linuxtx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040907212527.GB8766@linuxtx.org> User-Agent: Mutt/1.4.1i Subject: Re: local use flags with decoupled repositories X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 21:41:31 -0000 On Tue, Sep 07, 2004 at 04:25:27PM -0500, Justin M. Forbes wrote: > Do not warn on update, just on cook, and even then, just a warning. Exactly. A warning, along with the method for registering new local use flags, since we want to encourage configurability. I'd love it if that data source could be in a repository somehow, but I'm not absolutely sure how that would work. Suggestions welcome. One thing we've talked about is having not only packaging policy, but also repository policy, something that the repository can run before committing a changeset to a repository. I could imagine a repository being set up with policy that requires all local use flags to be registered (perhaps with a list of explicit exceptions, if necessary for some reason). > If compliance is encouraged, rather than enforced on the recipe > maintainer, we should hear fewer complaints, and I would expect a > reasonable amount of compliance from people who take pride in their work. Yeah, as long as there is an official "the right way to do it" I expect that most repository maintainers will want to follow it, and for any who choose not to, it should de-politicize other people saying "be aware that such-and-such repository doesn't follow this rule". (Disagreements about what the right way is to do things abound in the rpm repository world, and they do tend to get political and even personal, unfortunately.) From conary-list@groks.org Wed Sep 8 04:26:48 2004 Received: from bubba.e-complex.com (new.userful.com [69.44.60.111] (may be forged)) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i888QmbI020111 for ; Wed, 8 Sep 2004 04:26:48 -0400 Received: from [192.168.2.2] (d137-186-198-143.abhsia.telus.net [137.186.198.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bubba.e-complex.com (Postfix) with ESMTP id A435F29C145 for ; Wed, 8 Sep 2004 03:21:24 -0600 (MDT) From: Stephen Deasey To: Conary Discussion In-Reply-To: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> Content-Type: text/plain Message-Id: <1094632070.2365.145.camel@january.e-complex.ca> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 08 Sep 2004 02:27:51 -0600 Content-Transfer-Encoding: 7bit Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 08:26:48 -0000 What about ACLs? What about a sudoers list? What about SELinux? It feels like these plus traditional Unix permissions could be expressed as some higher level concept in packages, and the precise implementation could be chosen on installation. I'm not sure what it is though... On Fri, 2004-09-03 at 14:08, Michael K. Johnson wrote: > OK, we need to handle users and groups. We'd like to do this > in a very different way from RPM -- we want to separate data > from the mechanism that acts on it. > > This can't just use tags and handlers, because of too many > chicken/egg problems. > > First, we need to define the information that a packager can set, > without regard to where it is put, or how it is acted on. > > I think that package-specified users/groups shouldn't have > passwords or shadow stuff like expiry. We should also not create > home directories for such users; those directories should be > packaged instead. Also, since we should always suggest a uid, > -r doesn't make sense. So thinking in terms of useradd options, > we want to allow people to specify: > -u preferred user id > -g group (but only by name) > -G required supplemental group list (but only additions) > -c comment > -d home dir > -s shell (default for packaged users should be /sbin/nologin) > > So the changes IRT command-line option semantics will be for -g, > we only allow a name; for -G, we only list additions to the group > list required for the package, and for -s, we default to /sbin/nologin > > -G is special. -u, -g, -c, -d, and -s are used only when creating > the user. -G, if specified, provides groups that must be added to > the specified. (This brings up a question: if the package adds a > member to a supplemental group list, and the sysadmin removes that > membership, can we preserve the sysadmin's choice when upgrading > that package? The good news is that this is a VERY unusual case; > I've only ever seen this from a packaging standpoint once that I > can remember.) > > For groups, it's much simpler: > -g preferred group id > > We should never remove users or groups -- that's a security risk. > If a user or group is removed from the system database, but a file > (or other resource) is left owned by that user/group, then when > another different user or group is added and re-uses the number, > they can access the file (or other resource). The consequences > of that access cannot be known in general. > > > Now, mechanism. > > The idea that Erik came up with is to have a per-component table > containing this information (consider the user/group names as > indexes into this table) for all non-root permissions. Then, on > installed systems, we can have scripts which drive the mechanism, > based on the information in those tables. For bootstrapping the > install, before the policy scripts exist, there needs to be a > fallback; conary has to have the ability to edit the user/group > files itself. > > Any thoughts? > _______________________________________________ > conary-list mailing list > conary-list@lists.specifixinc.com > http://lists.specifixinc.com/mailman/listinfo/conary-list From conary-list@groks.org Wed Sep 8 04:46:15 2004 Received: from bubba.e-complex.com (new.userful.com [69.44.60.111] (may be forged)) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i888kFbI020138 for ; Wed, 8 Sep 2004 04:46:15 -0400 Received: from [192.168.2.2] (d137-186-198-143.abhsia.telus.net [137.186.198.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bubba.e-complex.com (Postfix) with ESMTP id 94A4029C145 for ; Wed, 8 Sep 2004 03:40:52 -0600 (MDT) From: Stephen Deasey To: Conary Discussion Content-Type: text/plain Message-Id: <1094633238.2365.166.camel@january.e-complex.ca> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 08 Sep 2004 02:47:19 -0600 Content-Transfer-Encoding: 7bit Subject: Conary vs. RHN X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 08:46:15 -0000 Red Hat Network is nice because it allows centralized control over a group of machines, whereas something like apt allows end users to update the machine in front of them. RHN is also nice because the client machine initiates a connection to the central server and asks for instructions. Red Carpet on the other hand starts a listening daemon on the client machine which the server contacts and sends instructions. I manage a group of geographically dispersed machines, all of which are behind NAT/firewalls, and all of which are locked down to the end users. They run a custom distribution which must be kept up to date. There are also various set of configurations which can be applied: desktop setting, bookmarks, which optional applications are installed, etc. Conary addresses building and maintaining the distribution, which RHN doesn't address at all. Can Conary also help me distribute, manage and customize in this environment? Thanks. From cjtan@OptimaNumerics.com Wed Sep 8 04:51:30 2004 Received: from mta08-svc.ntlworld.com (mta08-svc.ntlworld.com [62.253.162.48]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i888pTbI020152 for ; Wed, 8 Sep 2004 04:51:29 -0400 Received: from pami.OptimaNumerics.com ([62.254.49.98]) by mta08-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with SMTP id <20040908085227.CIFZ4940.mta08-svc.ntlworld.com@pami.OptimaNumerics.com> for ; Wed, 8 Sep 2004 09:52:27 +0100 Received: (qmail 16182 invoked by uid 544); 8 Sep 2004 08:52:22 -0000 Received: from cjtan@OptimaNumerics.com by iwka by uid 520 with qmail-scanner-1.22 (clamdscan: 0.73. f-prot: 4.4.2/3.14.11. spamassassin: 2.63. Clear:RC:1(10.0.3.2):. Processed in 0.973907 secs); 08 Sep 2004 08:52:22 -0000 X-Qmail-Scanner-Mail-From: cjtan@OptimaNumerics.com via iwka X-Qmail-Scanner: 1.22 (Clear:RC:1(10.0.3.2):. Processed in 0.973907 secs) Received: from unknown (10.0.3.2) by 0 with QMTP; 8 Sep 2004 08:52:19 -0000 Received: (qmail 26728 invoked from network); 8 Sep 2004 08:52:19 -0000 Received: from localhost (127.0.0.1) by 0 with SMTP; 8 Sep 2004 08:52:19 -0000 Date: Wed, 8 Sep 2004 08:52:19 +0000 (UTC) From: C J Kenneth Tan -- OptimaNumerics To: Conary Discussion In-Reply-To: <1094632070.2365.145.camel@january.e-complex.ca> Message-ID: References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> <1094632070.2365.145.camel@january.e-complex.ca> Organization: "OptimaNumerics" URL: http://www.OptimaNumerics.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 08:51:30 -0000 Stephen, I am not sure if you are talking about the same issues here. Kenneth Tan ----------------------------------------------------------------------- C. J. Kenneth Tan, Ph.D. OptimaNumerics Ltd. E-mail: cjtan@OptimaNumerics.com Telephone: +44 798 941 7838 Web: http://www.OptimaNumerics.com Facsimile: +44 289 066 3015 ----------------------------------------------------------------------- On 2004-09-08 02:27 -0600 Stephen Deasey (conary-list@groks.org) wrote: > Date: Wed, 08 Sep 2004 02:27:51 -0600 > From: Stephen Deasey > Reply-To: Conary Discussion > To: Conary Discussion > Subject: Re: user/group handling > > > What about ACLs? What about a sudoers list? What about SELinux? It > feels like these plus traditional Unix permissions could be expressed as > some higher level concept in packages, and the precise implementation > could be chosen on installation. I'm not sure what it is though... > > > > > > On Fri, 2004-09-03 at 14:08, Michael K. Johnson wrote: > > OK, we need to handle users and groups. We'd like to do this > > in a very different way from RPM -- we want to separate data > > from the mechanism that acts on it. > > > > This can't just use tags and handlers, because of too many > > chicken/egg problems. > > > > First, we need to define the information that a packager can set, > > without regard to where it is put, or how it is acted on. > > > > I think that package-specified users/groups shouldn't have > > passwords or shadow stuff like expiry. We should also not create > > home directories for such users; those directories should be > > packaged instead. Also, since we should always suggest a uid, > > -r doesn't make sense. So thinking in terms of useradd options, > > we want to allow people to specify: > > -u preferred user id > > -g group (but only by name) > > -G required supplemental group list (but only additions) > > -c comment > > -d home dir > > -s shell (default for packaged users should be /sbin/nologin) > > > > So the changes IRT command-line option semantics will be for -g, > > we only allow a name; for -G, we only list additions to the group > > list required for the package, and for -s, we default to /sbin/nologin > > > > -G is special. -u, -g, -c, -d, and -s are used only when creating > > the user. -G, if specified, provides groups that must be added to > > the specified. (This brings up a question: if the package adds a > > member to a supplemental group list, and the sysadmin removes that > > membership, can we preserve the sysadmin's choice when upgrading > > that package? The good news is that this is a VERY unusual case; > > I've only ever seen this from a packaging standpoint once that I > > can remember.) > > > > For groups, it's much simpler: > > -g preferred group id > > > > We should never remove users or groups -- that's a security risk. > > If a user or group is removed from the system database, but a file > > (or other resource) is left owned by that user/group, then when > > another different user or group is added and re-uses the number, > > they can access the file (or other resource). The consequences > > of that access cannot be known in general. > > > > > > Now, mechanism. > > > > The idea that Erik came up with is to have a per-component table > > containing this information (consider the user/group names as > > indexes into this table) for all non-root permissions. Then, on > > installed systems, we can have scripts which drive the mechanism, > > based on the information in those tables. For bootstrapping the > > install, before the policy scripts exist, there needs to be a > > fallback; conary has to have the ability to edit the user/group > > files itself. > > > > Any thoughts? > > _______________________________________________ > > conary-list mailing list > > conary-list@lists.specifixinc.com > > http://lists.specifixinc.com/mailman/listinfo/conary-list > > _______________________________________________ > conary-list mailing list > conary-list@lists.specifixinc.com > http://lists.specifixinc.com/mailman/listinfo/conary-list > > > From conary-list@groks.org Wed Sep 8 06:05:10 2004 Received: from bubba.e-complex.com (new.userful.com [69.44.60.111] (may be forged)) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i88A5AbI020249 for ; Wed, 8 Sep 2004 06:05:10 -0400 Received: from [192.168.2.2] (d137-186-198-143.abhsia.telus.net [137.186.198.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bubba.e-complex.com (Postfix) with ESMTP id 8308C29C145 for ; Wed, 8 Sep 2004 04:59:47 -0600 (MDT) From: Stephen Deasey To: Conary Discussion In-Reply-To: References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> <1094632070.2365.145.camel@january.e-complex.ca> Content-Type: text/plain Message-Id: <1094637972.2365.205.camel@january.e-complex.ca> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 08 Sep 2004 04:06:13 -0600 Content-Transfer-Encoding: 7bit Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 10:05:11 -0000 I usually specify user/group in RPM packages for daemons, to separate them and give least privilege. But there are more powerful ways to do that now. I'm thinking specifically of SELinux, which already ships with Fedora. Michael talked about traditional Unix users/groups, I was just wondering if it made sense to also consider SELinux at the same time. Perhaps it's a separate issue, but they seem to be addressing the same thing to me. To some extent so also do ACLs, the setuid bit, sudo etc. Conary is for building custom distributions, so I think you have to be careful looking at established practise in Redhat, Suse etc. because they may not be representative. My own experience of custom distribution building suggests they are likely to be much more specifically tuned to a given task. I've found users/groups/permissions to be important, and painful. I'd really like Conary to fix that for me. On Wed, 2004-09-08 at 02:52, C J Kenneth Tan -- OptimaNumerics wrote: > Stephen, > > I am not sure if you are talking about the same issues here. > > > Kenneth Tan > ----------------------------------------------------------------------- > C. J. Kenneth Tan, Ph.D. > OptimaNumerics Ltd. > E-mail: cjtan@OptimaNumerics.com Telephone: +44 798 941 7838 > Web: http://www.OptimaNumerics.com Facsimile: +44 289 066 3015 > ----------------------------------------------------------------------- > > > On 2004-09-08 02:27 -0600 Stephen Deasey (conary-list@groks.org) wrote: > > > Date: Wed, 08 Sep 2004 02:27:51 -0600 > > From: Stephen Deasey > > Reply-To: Conary Discussion > > To: Conary Discussion > > Subject: Re: user/group handling > > > > > > What about ACLs? What about a sudoers list? What about SELinux? It > > feels like these plus traditional Unix permissions could be expressed as > > some higher level concept in packages, and the precise implementation > > could be chosen on installation. I'm not sure what it is though... > > > > > > > > > > > > On Fri, 2004-09-03 at 14:08, Michael K. Johnson wrote: > > > OK, we need to handle users and groups. We'd like to do this > > > in a very different way from RPM -- we want to separate data > > > from the mechanism that acts on it. > > > > > > This can't just use tags and handlers, because of too many > > > chicken/egg problems. > > > > > > First, we need to define the information that a packager can set, > > > without regard to where it is put, or how it is acted on. > > > > > > I think that package-specified users/groups shouldn't have > > > passwords or shadow stuff like expiry. We should also not create > > > home directories for such users; those directories should be > > > packaged instead. Also, since we should always suggest a uid, > > > -r doesn't make sense. So thinking in terms of useradd options, > > > we want to allow people to specify: > > > -u preferred user id > > > -g group (but only by name) > > > -G required supplemental group list (but only additions) > > > -c comment > > > -d home dir > > > -s shell (default for packaged users should be /sbin/nologin) > > > > > > So the changes IRT command-line option semantics will be for -g, > > > we only allow a name; for -G, we only list additions to the group > > > list required for the package, and for -s, we default to /sbin/nologin > > > > > > -G is special. -u, -g, -c, -d, and -s are used only when creating > > > the user. -G, if specified, provides groups that must be added to > > > the specified. (This brings up a question: if the package adds a > > > member to a supplemental group list, and the sysadmin removes that > > > membership, can we preserve the sysadmin's choice when upgrading > > > that package? The good news is that this is a VERY unusual case; > > > I've only ever seen this from a packaging standpoint once that I > > > can remember.) > > > > > > For groups, it's much simpler: > > > -g preferred group id > > > > > > We should never remove users or groups -- that's a security risk. > > > If a user or group is removed from the system database, but a file > > > (or other resource) is left owned by that user/group, then when > > > another different user or group is added and re-uses the number, > > > they can access the file (or other resource). The consequences > > > of that access cannot be known in general. > > > > > > > > > Now, mechanism. > > > > > > The idea that Erik came up with is to have a per-component table > > > containing this information (consider the user/group names as > > > indexes into this table) for all non-root permissions. Then, on > > > installed systems, we can have scripts which drive the mechanism, > > > based on the information in those tables. For bootstrapping the > > > install, before the policy scripts exist, there needs to be a > > > fallback; conary has to have the ability to edit the user/group > > > files itself. > > > > > > Any thoughts? > > > _______________________________________________ > > > conary-list mailing list > > > conary-list@lists.specifixinc.com > > > http://lists.specifixinc.com/mailman/listinfo/conary-list > > > > _______________________________________________ > > conary-list mailing list > > conary-list@lists.specifixinc.com > > http://lists.specifixinc.com/mailman/listinfo/conary-list > > > > > > From ken@biZrace.com Wed Sep 8 06:50:49 2004 Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i88AombI020358 for ; Wed, 8 Sep 2004 06:50:49 -0400 Received: from [192.168.1.101] (cpe-024-163-091-077.nc.rr.com [24.163.91.77]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i88ApqNr028125 for ; Wed, 8 Sep 2004 06:51:52 -0400 (EDT) Message-ID: <413EE447.80203@biZrace.com> Date: Wed, 08 Sep 2004 06:51:51 -0400 From: Ken VanDine User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Conary Discussion References: <1094633238.2365.166.camel@january.e-complex.ca> In-Reply-To: <1094633238.2365.166.camel@january.e-complex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: Re: Conary vs. RHN X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 10:50:49 -0000 Hi Stephen, In short no. However, it could. I am not sure if the Specifix guys have plans to create those tools or not, but even if they don't you or someone could pretty easily. I may work on something like that myself. I think in the long term there is more promise for conary managing larger groups of systems. With the concepts of changesets, you could make a group of systems look the same with little effort. --Ken Stephen Deasey wrote: >Red Hat Network is nice because it allows centralized control over a >group of machines, whereas something like apt allows end users to update >the machine in front of them. > >RHN is also nice because the client machine initiates a connection to >the central server and asks for instructions. Red Carpet on the other >hand starts a listening daemon on the client machine which the server >contacts and sends instructions. > >I manage a group of geographically dispersed machines, all of which are >behind NAT/firewalls, and all of which are locked down to the end >users. They run a custom distribution which must be kept up to date. >There are also various set of configurations which can be applied: >desktop setting, bookmarks, which optional applications are installed, >etc. > >Conary addresses building and maintaining the distribution, which RHN >doesn't address at all. Can Conary also help me distribute, manage and >customize in this environment? > > >Thanks. > > > >_______________________________________________ >conary-list mailing list >conary-list@lists.specifixinc.com >http://lists.specifixinc.com/mailman/listinfo/conary-list > > > From johnsonm@specifixinc.com Wed Sep 8 09:45:12 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i88DjBbI020994 for ; Wed, 8 Sep 2004 09:45:12 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 3D97416230 for ; Wed, 8 Sep 2004 06:46:17 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i88DkFNI001978 for ; Wed, 8 Sep 2004 09:46:15 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i88DkDG0001976 for conary-list@lists.specifixinc.com; Wed, 8 Sep 2004 09:46:13 -0400 Date: Wed, 8 Sep 2004 09:46:13 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040908134613.GA1740@lambchop.rdu.specifixinc.com> References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> <1094632070.2365.145.camel@january.e-complex.ca> <1094637972.2365.205.camel@january.e-complex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094637972.2365.205.camel@january.e-complex.ca> User-Agent: Mutt/1.4.1i Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 13:45:12 -0000 On Wed, Sep 08, 2004 at 04:06:13AM -0600, Stephen Deasey wrote: > Michael talked about traditional Unix users/groups, I was just wondering > if it made sense to also consider SELinux at the same time. Perhaps > it's a separate issue, but they seem to be addressing the same thing to > me. To some extent so also do ACLs, the setuid bit, sudo etc. Sure, separate but somewhat related issues. Conary has to support existing practice of creating users and groups. There's no doubt about that. So we need a way to define how it does that, while avoiding the rampant bugs that standard packaging systems have for creating them (even the rpm package itself creates the rpm user incorrectly). ACLs depend on users and groups existing; they are a more flexible way of specifying permissions. Conary does not yet encode ACLs, but that is really not hard to add; we just need to wrap libacl in python (if it has not already been done) and define some new streams that encode ACLs. Setuid we handle a bit; we refuse to make anything setuid unless the recipe explicitly says that an executable should be setuid. It's one of the few pieces of information we refuse to trust the installed filesystem on. It does *warn* if it sees an unexpectedly setuid file in the filesystem when packaging. But we think that adding new setuid programs to the system automatically is a mistake. Setting up sudo is really an administrative task, and I don't have any ideas how that would be integrated in a completely generic way into a packaging system. I'd be interested to hear a proposal. SELinux is *very* interesting. I would not be at all surprised if it becomes one of the expected lines of defense for any secure system. SELinux policy is still maturing; it's definitely getting better. > Conary is for building custom distributions, so I think you have to be > careful looking at established practise in Redhat, Suse etc. because > they may not be representative. My own experience of custom > distribution building suggests they are likely to be much more > specifically tuned to a given task. I've found users/groups/permissions > to be important, and painful. I'd really like Conary to fix that for > me. We want it to work for building generic *and* custom distributions. The custom part is just the hard part. :-) From johnsonm@specifixinc.com Wed Sep 8 10:25:13 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i88EPDbI021097 for ; Wed, 8 Sep 2004 10:25:13 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 3758516230 for ; Wed, 8 Sep 2004 07:26:18 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i88EQGNI002730 for ; Wed, 8 Sep 2004 10:26:16 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i88EQGT6002728 for conary-list@lists.specifixinc.com; Wed, 8 Sep 2004 10:26:16 -0400 Date: Wed, 8 Sep 2004 10:26:16 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040908142616.GB1740@lambchop.rdu.specifixinc.com> References: <1094633238.2365.166.camel@january.e-complex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094633238.2365.166.camel@january.e-complex.ca> User-Agent: Mutt/1.4.1i Subject: Re: Conary vs. RHN X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 14:25:13 -0000 On Wed, Sep 08, 2004 at 02:47:19AM -0600, Stephen Deasey wrote: > I manage a group of geographically dispersed machines, all of which are > behind NAT/firewalls, and all of which are locked down to the end > users. They run a custom distribution which must be kept up to date. > There are also various set of configurations which can be applied: > desktop setting, bookmarks, which optional applications are installed, > etc. > > Conary addresses building and maintaining the distribution, which RHN > doesn't address at all. Can Conary also help me distribute, manage and > customize in this environment? Yes. Remember, though, that Conary is alpha, and that not all planned features are implemented yet. Several Conary features are specifically designed to help with situations like this. Two of these are: o The ability to branch the distribution, and o Local changesets Let me try to describe how these two features could do what you want. First, you would create your own repository. You would branch group-dist from (say) conary.specifixinc.com@spx:linux (probably @spx:release-1 or something like that, actually, once we have a release...) into your repository, where you would make your local changes. I'm guessing that your local changes would consist primarily of removing all the packages that you did not want installed. You would cook into that repository all the packages that you have made specifically for your installation. You would add those packages to your branch of group-dist. (Once shadows are implemented, you would probably want to shadow rather than branch group-dist, in order to make it easier to track our maintenance of the distribution.) Now, you could create local changesets that describe the configuration changes you have made. You have two ways to distribute those local changesets: o You can apply them to each system you install, as part of your kickstart installation. Those changes will be merged as each system updates as if you had made the changes locally on each machine. o You can commit them to your repository and make them part of your branch. You can then run a cron job with any frequency you like, which does "conary update group-dist"; this will initiate a connection from the client to the repository server, bringing it up to the latest version of group-dist on that branch. In the simplest case, one of your local packages creates the file /etc/cron.hourly with the contents "#!/bin/bash\nconary update group-dist" -- but you probably want to put a random wait in there to keep your repository server from being spammed, or just start a shell script with (while : ; do sleep 3600; conary update group-dist; done)& in it. Each time Conary sees that group-dist has changed, it will update it, and save a rollback encoding the entire transaction of updating group-dist. Now, this might sound like every machine you install has to be identical, or that you have to branch the distribution for each kind of server you install. But you don't. Conary will preserve the local modifications to group-dist on each maching, such as removing all the troves (packages, components, whatever) implementing services not needed on a particular server. When you update group-dist, it will note that you have removed (say) bind from server1, and the new version of group-dist (and everything it contains) that it installs on server1 will still not include bind, even though bind is part of group-dist. If that's not clear, let me know and I'll expand on it with examples. There are alternatives to the simple cron model. You could, say, use curl to fetch a file from a web site which says what version of group-dist to update to, and have "conary update group-dist=${VERSION}" instead. Obviously, there could be a lot more organized automation of this process. It is very easy to imagine having a web/gui system for configuring, say, XML files that the clients fetch to give them more information on what to do, how often to do it, etc. However, my point is that Conary provides the power to make it possible to do this very simply; Conary's repository-based model and change-preserving feature set are designed to make the task much simpler. It should not be missing huge chunks of implementation for updating a system. And, as we implement more features and fix bugs, Conary will be more capable of the task. I do understand that RHN does a lot more than package management, and I don't mean to imply that Conary provides all those features. I just mean that Conary should provide all the power needed to deal with provisioning and customization, allowing another tool to concentrate on system management above that level without that tool having to do half the package management job on top of the system management. And local changesets might shift people's thinking a bit about which tasks are system management and which are provisioning -- Conary might be capable of more work that it looks like at first blush. I'd welcome a discussion of specific tasks and how Conary might be useful in accomplishing them -- please feel free to bring up examples of challenges you see, and I'll do my best to see how they might fit into the Conary model. (Or to say that no, Conary isn't meant to do that...) On the "still being implemented" side, we're still optimizing conary to make "conary update group-dist" a reasonable thing to do in terms of memory. We're getting there; a lot of the necessary memory use optimization happened a couple of weeks ago. It is a key concept for deploying Conary. Right now, our *alpha* distribution isn't even installing group-dist. Finger-in-the-wind estimate: I expect that will change by the time we release a beta distribution. I hope this helps, From johnsonm@specifixinc.com Wed Sep 8 13:14:44 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i88HEhbI027293 for ; Wed, 8 Sep 2004 13:14:44 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id E340B1622D for ; Wed, 8 Sep 2004 10:14:44 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i88HEhNI006960 for ; Wed, 8 Sep 2004 13:14:43 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i88HEhhT006958 for conary-list@lists.specifixinc.com; Wed, 8 Sep 2004 13:14:43 -0400 Date: Wed, 8 Sep 2004 13:14:43 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040908171443.GA5688@lambchop.rdu.specifixinc.com> References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 17:14:44 -0000 On Fri, Sep 03, 2004 at 04:08:56PM -0400, Michael K. Johnson wrote: > Now, mechanism. Also, mechanism in recipes: In almost all cases, there is one recipe (relative to what is installed on a single system) that is clearly responsible for adding the group; the bind recipe is responsible for adding the named user; the ftp server (say, vsftpd) is responsible for adding the ftp user, the mailman recipe for the mailman user, etc. Basic system users are probably defined in the setup recipe. My idea is that supplemental group information should be seen as modifying an existing user, whereas the rest of the user information is only for creating a user. Also, adding a user with a private group, that private group should show up as part of the user definition. So, we might end up with r.User('name', preferred_uid, 'maingroupname', '/home/dir', comment='comment', shell='/path/to/shell', groupid=preferred_gid) where the optional fields have reasonable default values, probably: comment='' shell='/sbin/nologin' groupid=preferred_uid Then, to add a supplemental group to a user, r.SupplementalGroup('user', 'group') or r.SupplementalGroup('user', ('group1', 'group2')) This would be useful mainly for things like adding supplemental groups to the apache user so that the web server can see data. It wouldn't get very much use. If you need to create only a group, you would specify only: r.Group('name', preferred_gid) Like SupplementalGroup, this would be quite rare. If r.Ownership is invoked without invoking r.User, it might be that the package's dependencies could be checked, and if one of them had the information that would be provided by r.User, it would be copied from that package. That would avoid duplication of information -- and when information is duplicated across recipes, it's bound to have a problem somewhere. Thoughts on this model? From johnsonm@specifixinc.com Wed Sep 8 14:25:44 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i88IPhbI027411 for ; Wed, 8 Sep 2004 14:25:44 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id D2D171622D for ; Wed, 8 Sep 2004 11:25:44 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i88IPhNI009124 for ; Wed, 8 Sep 2004 14:25:43 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i88IPhb0009122 for conary-list@lists.specifixinc.com; Wed, 8 Sep 2004 14:25:43 -0400 Date: Wed, 8 Sep 2004 14:25:43 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040908182543.GA9062@lambchop.rdu.specifixinc.com> References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> <1094632070.2365.145.camel@january.e-complex.ca> <1094637972.2365.205.camel@january.e-complex.ca> <20040908134613.GA1740@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040908134613.GA1740@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 18:25:44 -0000 On Wed, Sep 08, 2004 at 09:46:13AM -0400, Michael K. Johnson wrote: > SELinux is *very* interesting. I would not be at all surprised if > it becomes one of the expected lines of defense for any secure system. > SELinux policy is still maturing; it's definitely getting better. I meant to say and forgot: the new "targeted" policy seems very promising for general use for servers. Much more so than the previous attempts to control everything happening on the machine, in my opinion. It's going to be easier to get people to accept something that looks a bit more like what they are already used to. It's with selinux in mind that we have a Use flag in Conary for selinux. From johnsonm@specifixinc.com Thu Sep 9 10:18:58 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i89EIvbI029678 for ; Thu, 9 Sep 2004 10:18:58 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id CD5DB16610 for ; Thu, 9 Sep 2004 07:18:59 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i89EIwNI002764 for ; Thu, 9 Sep 2004 10:18:58 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i89EIwnv002762 for conary-list@lists.specifixinc.com; Thu, 9 Sep 2004 10:18:58 -0400 Date: Thu, 9 Sep 2004 10:18:58 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040909141858.GB2599@lambchop.rdu.specifixinc.com> References: <20040907204138.GA13643@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040907204138.GA13643@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: dependencies: IRC summary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 14:18:58 -0000 On Tue, Sep 07, 2004 at 04:41:38PM -0400, Michael K. Johnson wrote: > to express. I said that leading "/" means DEP_CLASS_FILES, leading Obviously (at least, that's the way it feels to me), that leading "/" only makes sense in the context of r.Requires; providing a file should be implicit in the existance of a file... From johnsonm@specifixinc.com Thu Sep 9 14:39:53 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i89IdqbI030076 for ; Thu, 9 Sep 2004 14:39:52 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 3331116212 for ; Thu, 9 Sep 2004 11:39:54 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i89IdqNI009725 for ; Thu, 9 Sep 2004 14:39:52 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i89IdqjW009723 for conary-list@lists.specifixinc.com; Thu, 9 Sep 2004 14:39:52 -0400 Date: Thu, 9 Sep 2004 14:39:52 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040909183952.GA8569@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: metadata X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 18:39:53 -0000 I've been thinking about metadata for Conary. o I want minimal possible metadata -- the fewer blanks to fill in, the better job people will do filling in each blank. o I do not want to have to re-cook metadata with packages; it should live separately. Re-translating after re-cooking and re-cooking after re-translating are both wastes of time. o I'd like to cooperate with other projects for collecting metadata I've looked at two existing metadata projects that look interesting for different reasons: DOAP and freshmeat. Freshmeat has reasonable coverage of possible metadata per project, and extremely complete coverage of projects out there. DOAP has perhaps the most complete description of things that might go in metadata. For considering metadata candidates, I have found valuable the table at http://www-106.ibm.com/developerworks/xml/library/x-osproj2/ We don't have DOAP's problem of uniquely identifying a project; we have repositories and troves that we are describing, so we do not want to use (name, homepage-or-old_homepage) as the unique ID. We definitely don't want to recreate or try to compete with freshmeat; that would be silly and counterproductive. I suggest that the items of metadata that we really want to have in the repository, referenced by troves (i.e. we do not store the name in the metadata), are: o summary (short description, a sentence fragment) o description (arbitrarily long description) o URL(s) (arbitrarily many top-level URLs, potentially including project homepage (if any), freshmeat home page, list home page, etc.) o License, comprised of - Name - URL either of which may be empty. Furthermore, if the trove contains items with multiple licenses, then there can be multiple license items, each with a name and URL. Alternatively, each license could be a reference to some other item cooked into the repository, referenced by full version of the object in the repository? The summary and description should be translateable. The repository versioning should make it possible to track when translations may be out of date. I'd be interested if anyone here with expertise in translation has ideas about how well this might work. There is the possibility that we'd want the ability to put troves in categories, like freshmeat-style troves; the example for Conary is: [Development Status] 3 - Alpha [Environment] Console (Text Based), X11 Applications :: GTK [License] OSI Approved :: Common Public License [Operating System] POSIX [Programming Language] C, Python [Topic] Software Development :: Version Control, System :: Archiving :: Packaging, System :: Installation/Setup, System :: Software Distribution Tools However, that might be more information than we really need. We do not need development status (irrelevant; it's the status of the branch it is on that matters), license (included separately), operating system (implied by branchname as much as we need), programming language (implied by buildrequires and dependencies as much as we need it). Our Use flags should pretty much cover Environment, as much as we need it covered, For example, Use.gtk indicates the same thing as "[Environment] X11 Applications::GTK". Topic is kind of like a multi-valued version of what RPM, at least, calls a category. Now, groups can contain groups, and troves can be in arbitrarily many groups. My idea is that the description, summary, and even URL metadata items can apply to ANY trove, not just to components or packages, and this can substitute for category/topics. So group-text-apps and group-desktop and group-system-archiving and group-software-distribution-tools and group-gnome ... could all exist, and contain references to these troves. My idea is that you really do not usually care to which categories any particular trove belongs; instead, you wish to search for troves fitting a particular category. So I'm kind of standing the idea of category on its head; I think that pointers go backwards in at least RPM's way of encoding this information. Opinions about the content of metadata? I'm guessing that most of this information could be harvested from a variety of sources. I could see one way of getting this information would be to, from within a directory with a CONARY file defining what you are committing the description to, run a command like: cvc describe --freshmeat[=] By default, it would get the name from the CONARY file, and use the URL http://freshmeat.net/projects-xml//.xml but it would use if you specified it as an argument. It would then get the information off freshmeat, and store it in a local xml file, which would not be committed to the :source trove but would instead be stored separately in the repository (though I suspect on the same branch as the source trove), thus would not affect cooking the trove, and could be updated (for translation, etc) entirely separately from the :source trove. Similarly, cvc describe --doap=/path/to/doapfile or the equivalent cvc describe --doap=http://host/path/something.rdf to grab DOAP information and store relevant bits in our local, simpler record. Opinions about this mechanism? From msw@specifixinc.com Thu Sep 9 17:45:25 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i89LjPbI030386 for ; Thu, 9 Sep 2004 17:45:25 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 628B31622A for ; Thu, 9 Sep 2004 14:45:27 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i89LjQNI014737 for ; Thu, 9 Sep 2004 17:45:26 -0400 Received: (from msw@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i89LjQa8014735 for conary-list@lists.specifixinc.com; Thu, 9 Sep 2004 17:45:26 -0400 Date: Thu, 9 Sep 2004 17:45:25 -0400 From: Matt Wilson To: conary-list@lists.specifixinc.com Message-ID: <20040909214525.GA3982@specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: distributed branching is broken in 0.9.4 X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 21:45:25 -0000 I needed to make a change to fix fetching the contents from a renamed file, but this will break distributed branching. We'll get it fixed soon. Cheers, Matt From conary-list@groks.org Thu Sep 9 18:44:45 2004 Received: from bubba.e-complex.com (new.userful.com [69.44.60.111] (may be forged)) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i89MijbI030471 for ; Thu, 9 Sep 2004 18:44:45 -0400 Received: from [192.168.2.2] (d137-186-198-143.abhsia.telus.net [137.186.198.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bubba.e-complex.com (Postfix) with ESMTP id C884D29C147 for ; Thu, 9 Sep 2004 17:38:16 -0600 (MDT) From: Stephen Deasey To: Conary Discussion In-Reply-To: <20040908142616.GB1740@lambchop.rdu.specifixinc.com> References: <1094633238.2365.166.camel@january.e-complex.ca> <20040908142616.GB1740@lambchop.rdu.specifixinc.com> Content-Type: text/plain Message-Id: <1094769878.2365.770.camel@january.e-complex.ca> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 09 Sep 2004 16:44:38 -0600 Content-Transfer-Encoding: 7bit Subject: Re: Conary vs. RHN X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 22:44:45 -0000 Thanks, that was helpful. Couple more questions... How would you define a subset of a custom distro that say includes a couple of extra packages and some config changes, and then roll that out to some already deployed machines? The definition of the subset would happen server-side by some non-conary tool. The deployed machines may already be grouped correctly (on the same conary branch?), or you may need to regroup them (e.g. merge the bio and phys lab machines). Also, is it possible for the server machine to track local changes on the machines? Or would you have to create a branch for each machine, and is that even feasible? Thanks. On Wed, 2004-09-08 at 08:26, Michael K. Johnson wrote: > Remember, though, that Conary is alpha, and that not all planned features > are implemented yet. > > Several Conary features are specifically designed to help with situations > like this. Two of these are: > o The ability to branch the distribution, and > o Local changesets > Let me try to describe how these two features could do what you want. > > First, you would create your own repository. You would branch group-dist > from (say) conary.specifixinc.com@spx:linux (probably @spx:release-1 or > something like that, actually, once we have a release...) into your > repository, where you would make your local changes. I'm guessing that > your local changes would consist primarily of removing all the packages > that you did not want installed. You would cook into that repository > all the packages that you have made specifically for your installation. > You would add those packages to your branch of group-dist. > > (Once shadows are implemented, you would probably want to shadow rather > than branch group-dist, in order to make it easier to track our > maintenance of the distribution.) > > Now, you could create local changesets that describe the configuration > changes you have made. You have two ways to distribute those local > changesets: > o You can apply them to each system you install, as part of your > kickstart installation. Those changes will be merged as each > system updates as if you had made the changes locally on each > machine. > o You can commit them to your repository and make them part of your > branch. > > You can then run a cron job with any frequency you like, which > does "conary update group-dist"; this will initiate a connection > from the client to the repository server, bringing it up to the > latest version of group-dist on that branch. In the simplest > case, one of your local packages creates the file /etc/cron.hourly > with the contents "#!/bin/bash\nconary update group-dist" -- but > you probably want to put a random wait in there to keep your > repository server from being spammed, or just start a shell > script with (while : ; do sleep 3600; conary update group-dist; done)& > in it. > > Each time Conary sees that group-dist has changed, it will update > it, and save a rollback encoding the entire transaction of updating > group-dist. > > Now, this might sound like every machine you install has to be > identical, or that you have to branch the distribution for each > kind of server you install. But you don't. Conary will preserve > the local modifications to group-dist on each maching, such as > removing all the troves (packages, components, whatever) implementing > services not needed on a particular server. When you update > group-dist, it will note that you have removed (say) bind from > server1, and the new version of group-dist (and everything it > contains) that it installs on server1 will still not include bind, > even though bind is part of group-dist. > > If that's not clear, let me know and I'll expand on it with > examples. > > > > There are alternatives to the simple cron model. You could, say, use > curl to fetch a file from a web site which says what version of group-dist > to update to, and have "conary update group-dist=${VERSION}" instead. > Obviously, there could be a lot more organized automation of this > process. It is very easy to imagine having a web/gui system for > configuring, say, XML files that the clients fetch to give them > more information on what to do, how often to do it, etc. However, > my point is that Conary provides the power to make it possible to do > this very simply; Conary's repository-based model and change-preserving > feature set are designed to make the task much simpler. It should not > be missing huge chunks of implementation for updating a system. > And, as we implement more features and fix bugs, Conary will be more > capable of the task. > > I do understand that RHN does a lot more than package management, and > I don't mean to imply that Conary provides all those features. I just > mean that Conary should provide all the power needed to deal with > provisioning and customization, allowing another tool to concentrate > on system management above that level without that tool having to do > half the package management job on top of the system management. And > local changesets might shift people's thinking a bit about which tasks > are system management and which are provisioning -- Conary might be > capable of more work that it looks like at first blush. > > I'd welcome a discussion of specific tasks and how Conary might be > useful in accomplishing them -- please feel free to bring up examples > of challenges you see, and I'll do my best to see how they might fit > into the Conary model. (Or to say that no, Conary isn't meant to > do that...) > > > On the "still being implemented" side, we're still optimizing > conary to make "conary update group-dist" a reasonable thing to > do in terms of memory. We're getting there; a lot of the necessary > memory use optimization happened a couple of weeks ago. It is a > key concept for deploying Conary. Right now, our *alpha* distribution > isn't even installing group-dist. Finger-in-the-wind estimate: I > expect that will change by the time we release a beta distribution. > > I hope this helps, > _______________________________________________ > conary-list mailing list > conary-list@lists.specifixinc.com > http://lists.specifixinc.com/mailman/listinfo/conary-list From johnsonm@specifixinc.com Thu Sep 9 18:54:43 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i89MsgbI030488 for ; Thu, 9 Sep 2004 18:54:42 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 446C216793 for ; Thu, 9 Sep 2004 15:54:45 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i89MshNI016532 for ; Thu, 9 Sep 2004 18:54:43 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i89Msho1016530 for conary-list@lists.specifixinc.com; Thu, 9 Sep 2004 18:54:43 -0400 Date: Thu, 9 Sep 2004 18:54:42 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040909225442.GA16314@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: #!/bin/env policy X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 22:54:43 -0000 For setting up file dependencies correctly, I need to handle scripts with first lines like "#!/bin/env foo". It's a *wonderful* hack to enable run-everywhere scripts. However, it is not so great for system that has been tested as a whole. A user changes his/her PATH and suddenly scripts start breaking because they were never tested that way... It basically makes QA ineffective. I'm thinking that I ought to create a policy that re-writes /bin/env into the canonical path to foo in the distribution for shell scripts, by default. For example, "#!/bin/env bash" would be re-written as "#!/bin/bash". (Obviously, scripts that really need to use /bin/env specifically because part of the definition of their behavior is that they depend on the user's PATH setting can have exceptions in their recipes so that this auto-mangling isn't done.) If anyone dislikes this idea, please give me some rational arguments for why I should avoid doing this work. :-) From stephen@e-complex.com Thu Sep 9 19:28:11 2004 Received: from bubba.e-complex.com (new.userful.com [69.44.60.111] (may be forged)) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i89NSBbI030571 for ; Thu, 9 Sep 2004 19:28:11 -0400 Received: from [192.168.2.2] (d137-186-198-143.abhsia.telus.net [137.186.198.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bubba.e-complex.com (Postfix) with ESMTP id 3943829C147 for ; Thu, 9 Sep 2004 18:21:43 -0600 (MDT) From: Stephen Deasey To: Conary Discussion In-Reply-To: <20040908134613.GA1740@lambchop.rdu.specifixinc.com> References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> <1094632070.2365.145.camel@january.e-complex.ca> <1094637972.2365.205.camel@january.e-complex.ca> <20040908134613.GA1740@lambchop.rdu.specifixinc.com> Content-Type: text/plain Message-Id: <1094772481.2365.816.camel@january.e-complex.ca> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 09 Sep 2004 17:28:01 -0600 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 09 Sep 2004 20:28:35 -0400 Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 23:28:11 -0000 In Fedora Core 2 if I click Applications -> System Settings -> Date & Time, a dialogue box pops up asking for the root password. This sucks for a couple of obvious reasons: 1) the granularity is too course, you have to give up the whole box just to set the time; 2) the admin users have to remember a second password, and keep a shared secret. >From a packaging perspective you'd really like to be able to tag the system-config-date program as admin (or something). In a Fedora like distro, the tag handler would then set up the consolehelper symlinks etc. to enable the password dialogue box. You could then imagine creating as new tag handler which used sudo with GUI instead -- it would ask you for your own password, not root's. You could take this further. The tag handler could give each admin command it's own privilege which is required to run it, then bundle all the privileges into the admin role. Now someone with the admin role can run all the admin commands, such as 'add user', and arbitrary other people could be given 'change date' privs as needed. If the tag was extended from just admin to admin, sysadmin, you could create two roles, etc... Anyway, the idea is that by simplifying the recipes by providing higher level security concepts, you could achieve a more powerful, flexible system. In practise when a package works with supplementary groups, it's really just looking for finer grained permissions and I'd like to see that idea captured in some way. Thanks. On Wed, 2004-09-08 at 07:46, Michael K. Johnson wrote: > On Wed, Sep 08, 2004 at 04:06:13AM -0600, Stephen Deasey wrote: > > Michael talked about traditional Unix users/groups, I was just wondering > > if it made sense to also consider SELinux at the same time. Perhaps > > it's a separate issue, but they seem to be addressing the same thing to > > me. To some extent so also do ACLs, the setuid bit, sudo etc. > > Sure, separate but somewhat related issues. > > Conary has to support existing practice of creating users and groups. > There's no doubt about that. So we need a way to define how it does > that, while avoiding the rampant bugs that standard packaging systems > have for creating them (even the rpm package itself creates the rpm > user incorrectly). > > ACLs depend on users and groups existing; they are a more flexible way > of specifying permissions. Conary does not yet encode ACLs, but that > is really not hard to add; we just need to wrap libacl in python (if > it has not already been done) and define some new streams that encode > ACLs. > > Setuid we handle a bit; we refuse to make anything setuid unless the > recipe explicitly says that an executable should be setuid. It's one > of the few pieces of information we refuse to trust the installed > filesystem on. It does *warn* if it sees an unexpectedly setuid file > in the filesystem when packaging. But we think that adding new > setuid programs to the system automatically is a mistake. > > Setting up sudo is really an administrative task, and I don't have > any ideas how that would be integrated in a completely generic way > into a packaging system. I'd be interested to hear a proposal. > > SELinux is *very* interesting. I would not be at all surprised if > it becomes one of the expected lines of defense for any secure system. > SELinux policy is still maturing; it's definitely getting better. > > > Conary is for building custom distributions, so I think you have to be > > careful looking at established practise in Redhat, Suse etc. because > > they may not be representative. My own experience of custom > > distribution building suggests they are likely to be much more > > specifically tuned to a given task. I've found users/groups/permissions > > to be important, and painful. I'd really like Conary to fix that for > > me. > > We want it to work for building generic *and* custom distributions. > The custom part is just the hard part. :-) > _______________________________________________ > conary-list mailing list > conary-list@lists.specifixinc.com > http://lists.specifixinc.com/mailman/listinfo/conary-list From ken@biZrace.com Thu Sep 9 21:04:54 2004 Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8A14rbI030681 for ; Thu, 9 Sep 2004 21:04:53 -0400 Received: from [192.168.1.101] (cpe-024-163-091-077.nc.rr.com [24.163.91.77]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i8A14sNr017368 for ; Thu, 9 Sep 2004 21:04:55 -0400 (EDT) Message-ID: <4140FD94.7050207@biZrace.com> Date: Thu, 09 Sep 2004 21:04:20 -0400 From: Ken VanDine User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Conary Discussion References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> <1094632070.2365.145.camel@january.e-complex.ca> <1094637972.2365.205.camel@january.e-complex.ca> <20040908134613.GA1740@lambchop.rdu.specifixinc.com> <1094772481.2365.816.camel@january.e-complex.ca> In-Reply-To: <1094772481.2365.816.camel@january.e-complex.ca> Content-Type: multipart/alternative; boundary="------------080605010208070304050506" X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 01:04:54 -0000 This is a multi-part message in MIME format. --------------080605010208070304050506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree it would be nice to have more of role based setup. However, I don't know how feasable it is right now. Part of the issue is conary isn't designed to build a single distro. The distro you create may differ greatly from the one I create. Therefore, alot of this would be the responsibility of the maintainer. Very little control there. I might use the time-admin tool from gst-tools, and you may use system-config-date. I am not saying it isn't doable, I just think the issue is bigger than conary. We have had to setup sudo access for our users to basic things like that. Which isn't very clean. I think this is more of a unix problem in general. I would like to see things grow beyond the simple user/group model and get into a real role based system... but NOT like the mess M$ has created. Just my .02 --Ken Stephen Deasey wrote: >In Fedora Core 2 if I click Applications -> System Settings -> Date & >Time, a dialogue box pops up asking for the root password. This sucks >for a couple of obvious reasons: 1) the granularity is too course, you >have to give up the whole box just to set the time; 2) the admin users >have to remember a second password, and keep a shared secret. > >>From a packaging perspective you'd really like to be able to tag the >system-config-date program as admin (or something). In a Fedora like >distro, the tag handler would then set up the consolehelper symlinks >etc. to enable the password dialogue box. > >You could then imagine creating as new tag handler which used sudo with >GUI instead -- it would ask you for your own password, not root's. > >You could take this further. The tag handler could give each admin >command it's own privilege which is required to run it, then bundle all >the privileges into the admin role. Now someone with the admin role can >run all the admin commands, such as 'add user', and arbitrary other >people could be given 'change date' privs as needed. If the tag was >extended from just admin to admin, sysadmin, you could create two roles, >etc... > >Anyway, the idea is that by simplifying the recipes by providing higher >level security concepts, you could achieve a more powerful, flexible >system. In practise when a package works with supplementary groups, >it's really just looking for finer grained permissions and I'd like to >see that idea captured in some way. > > > >Thanks. > > > >On Wed, 2004-09-08 at 07:46, Michael K. Johnson wrote: > > >>On Wed, Sep 08, 2004 at 04:06:13AM -0600, Stephen Deasey wrote: >> >> >>>Michael talked about traditional Unix users/groups, I was just wondering >>>if it made sense to also consider SELinux at the same time. Perhaps >>>it's a separate issue, but they seem to be addressing the same thing to >>>me. To some extent so also do ACLs, the setuid bit, sudo etc. >>> >>> >>Sure, separate but somewhat related issues. >> >>Conary has to support existing practice of creating users and groups. >>There's no doubt about that. So we need a way to define how it does >>that, while avoiding the rampant bugs that standard packaging systems >>have for creating them (even the rpm package itself creates the rpm >>user incorrectly). >> >>ACLs depend on users and groups existing; they are a more flexible way >>of specifying permissions. Conary does not yet encode ACLs, but that >>is really not hard to add; we just need to wrap libacl in python (if >>it has not already been done) and define some new streams that encode >>ACLs. >> >>Setuid we handle a bit; we refuse to make anything setuid unless the >>recipe explicitly says that an executable should be setuid. It's one >>of the few pieces of information we refuse to trust the installed >>filesystem on. It does *warn* if it sees an unexpectedly setuid file >>in the filesystem when packaging. But we think that adding new >>setuid programs to the system automatically is a mistake. >> >>Setting up sudo is really an administrative task, and I don't have >>any ideas how that would be integrated in a completely generic way >>into a packaging system. I'd be interested to hear a proposal. >> >>SELinux is *very* interesting. I would not be at all surprised if >>it becomes one of the expected lines of defense for any secure system. >>SELinux policy is still maturing; it's definitely getting better. >> >> >> >>>Conary is for building custom distributions, so I think you have to be >>>careful looking at established practise in Redhat, Suse etc. because >>>they may not be representative. My own experience of custom >>>distribution building suggests they are likely to be much more >>>specifically tuned to a given task. I've found users/groups/permissions >>>to be important, and painful. I'd really like Conary to fix that for >>>me. >>> >>> >>We want it to work for building generic *and* custom distributions. >>The custom part is just the hard part. :-) >>_______________________________________________ >>conary-list mailing list >>conary-list@lists.specifixinc.com >>http://lists.specifixinc.com/mailman/listinfo/conary-list >> >> > >_______________________________________________ >conary-list mailing list >conary-list@lists.specifixinc.com >http://lists.specifixinc.com/mailman/listinfo/conary-list > > > --------------080605010208070304050506 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I agree it would be nice to have more of role based setup.  However, I don't know how feasable it is right now.  Part of the issue is conary isn't designed to build a single distro.  The distro you create may differ greatly from the one I create.  Therefore, alot of this would be the responsibility of the maintainer.  Very little control there.  I might use the time-admin tool from gst-tools, and you may use system-config-date.  I am not saying it isn't doable, I just think the issue is bigger than conary. 

We have had to setup sudo access for our users to basic things like that.  Which isn't very clean.  I think this is more of a unix problem in general.  I would like to see things grow beyond the simple user/group model and get into a real role based system... but NOT like the mess M$ has created.

Just my .02

--Ken


Stephen Deasey wrote: 
In Fedora Core 2 if I click Applications -> System Settings -> Date &
Time, a dialogue box pops up asking for the root password.  This sucks
for a couple of obvious reasons: 1) the granularity is too course, you
have to give up the whole box just to set the time; 2) the admin users
have to remember a second password, and keep a shared secret.

>From a packaging perspective you'd really like to be able to tag the
system-config-date program as admin (or something).  In a Fedora like
distro, the tag handler would then set up the consolehelper symlinks
etc. to enable the password dialogue box.

You could then imagine creating as new tag handler which used sudo with
GUI instead -- it would ask you for your own password, not root's.

You could take this further. The tag handler could give each admin
command it's own privilege which is required to run it, then bundle all
the privileges into the admin role.  Now someone with the admin role can
run all the admin commands, such as 'add user', and arbitrary other
people could be given 'change date' privs as needed.  If the tag was
extended from just admin to admin, sysadmin, you could create two roles,
etc...

Anyway, the idea is that by simplifying the recipes by providing higher
level security concepts, you could achieve a more powerful, flexible
system.  In practise when a package works with supplementary groups,
it's really just looking for finer grained permissions and I'd like to
see that idea captured in some way.



Thanks.



On Wed, 2004-09-08 at 07:46, Michael K. Johnson wrote:
  
On Wed, Sep 08, 2004 at 04:06:13AM -0600, Stephen Deasey wrote:
    
Michael talked about traditional Unix users/groups, I was just wondering
if it made sense to also consider SELinux at the same time.  Perhaps
it's a separate issue, but they seem to be addressing the same thing to
me. To some extent so also do ACLs, the setuid bit, sudo etc.
      
Sure, separate but somewhat related issues.

Conary has to support existing practice of creating users and groups.
There's no doubt about that.  So we need a way to define how it does
that, while avoiding the rampant bugs that standard packaging systems
have for creating them (even the rpm package itself creates the rpm
user incorrectly).

ACLs depend on users and groups existing; they are a more flexible way
of specifying permissions.  Conary does not yet encode ACLs, but that
is really not hard to add; we just need to wrap libacl in python (if
it has not already been done) and define some new streams that encode
ACLs.

Setuid we handle a bit; we refuse to make anything setuid unless the
recipe explicitly says that an executable should be setuid.  It's one
of the few pieces of information we refuse to trust the installed
filesystem on.  It does *warn* if it sees an unexpectedly setuid file
in the filesystem when packaging.  But we think that adding new
setuid programs to the system automatically is a mistake.

Setting up sudo is really an administrative task, and I don't have
any ideas how that would be integrated in a completely generic way
into a packaging system.  I'd be interested to hear a proposal.

SELinux is *very* interesting.  I would not be at all surprised if
it becomes one of the expected lines of defense for any secure system.
SELinux policy is still maturing; it's definitely getting better.

    
Conary is for building custom distributions, so I think you have to be
careful looking at established practise in Redhat, Suse etc. because
they may not be representative.  My own experience of custom
distribution building suggests they are likely to be much more
specifically tuned to a given task.  I've found users/groups/permissions
to be important, and painful.  I'd really like Conary to fix that for
me.
      
We want it to work for building generic *and* custom distributions.
The custom part is just the hard part.  :-)
_______________________________________________
conary-list mailing list
conary-list@lists.specifixinc.com
http://lists.specifixinc.com/mailman/listinfo/conary-list
    

_______________________________________________
conary-list mailing list
conary-list@lists.specifixinc.com
http://lists.specifixinc.com/mailman/listinfo/conary-list

--------------080605010208070304050506-- From conary-list@groks.org Thu Sep 9 22:59:26 2004 Received: from bubba.e-complex.com (new.userful.com [69.44.60.111] (may be forged)) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8A2xQbI030851 for ; Thu, 9 Sep 2004 22:59:26 -0400 Received: from [192.168.2.2] (d137-186-198-143.abhsia.telus.net [137.186.198.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bubba.e-complex.com (Postfix) with ESMTP id 15DCC29C147 for ; Thu, 9 Sep 2004 21:52:58 -0600 (MDT) From: Stephen Deasey To: Conary Discussion In-Reply-To: <4140FD94.7050207@biZrace.com> References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> <1094632070.2365.145.camel@january.e-complex.ca> <1094637972.2365.205.camel@january.e-complex.ca> <20040908134613.GA1740@lambchop.rdu.specifixinc.com> <1094772481.2365.816.camel@january.e-complex.ca> <4140FD94.7050207@biZrace.com> Content-Type: text/plain Message-Id: <1094785161.2365.822.camel@january.e-complex.ca> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 09 Sep 2004 20:59:21 -0600 Content-Transfer-Encoding: 7bit Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 02:59:26 -0000 Sure. I wouldn't like to see policy enforced by conary, just provide the mechanism. I probably got all the conary terminology wrong, but high level metadata in the recipes and policy in the tag scripts would do that, I think... On Thu, 2004-09-09 at 19:04, Ken VanDine wrote: > I agree it would be nice to have more of role based setup. However, I > don't know how feasable it is right now. Part of the issue is conary > isn't designed to build a single distro. The distro you create may > differ greatly from the one I create. Therefore, alot of this would > be the responsibility of the maintainer. Very little control there. > I might use the time-admin tool from gst-tools, and you may use > system-config-date. I am not saying it isn't doable, I just think the > issue is bigger than conary. > > We have had to setup sudo access for our users to basic things like > that. Which isn't very clean. I think this is more of a unix problem > in general. I would like to see things grow beyond the simple > user/group model and get into a real role based system... but NOT like > the mess M$ has created. > > Just my .02 > > --Ken > > > Stephen Deasey wrote: > > In Fedora Core 2 if I click Applications -> System Settings -> Date & > > Time, a dialogue box pops up asking for the root password. This sucks > > for a couple of obvious reasons: 1) the granularity is too course, you > > have to give up the whole box just to set the time; 2) the admin users > > have to remember a second password, and keep a shared secret. > > > > >From a packaging perspective you'd really like to be able to tag the > > system-config-date program as admin (or something). In a Fedora like > > distro, the tag handler would then set up the consolehelper symlinks > > etc. to enable the password dialogue box. > > > > You could then imagine creating as new tag handler which used sudo with > > GUI instead -- it would ask you for your own password, not root's. > > > > You could take this further. The tag handler could give each admin > > command it's own privilege which is required to run it, then bundle all > > the privileges into the admin role. Now someone with the admin role can > > run all the admin commands, such as 'add user', and arbitrary other > > people could be given 'change date' privs as needed. If the tag was > > extended from just admin to admin, sysadmin, you could create two roles, > > etc... > > > > Anyway, the idea is that by simplifying the recipes by providing higher > > level security concepts, you could achieve a more powerful, flexible > > system. In practise when a package works with supplementary groups, > > it's really just looking for finer grained permissions and I'd like to > > see that idea captured in some way. > > > > > > > > Thanks. > > > > > > > > On Wed, 2004-09-08 at 07:46, Michael K. Johnson wrote: > > > > > On Wed, Sep 08, 2004 at 04:06:13AM -0600, Stephen Deasey wrote: > > > > > > > Michael talked about traditional Unix users/groups, I was just wondering > > > > if it made sense to also consider SELinux at the same time. Perhaps > > > > it's a separate issue, but they seem to be addressing the same thing to > > > > me. To some extent so also do ACLs, the setuid bit, sudo etc. > > > > > > > Sure, separate but somewhat related issues. > > > > > > Conary has to support existing practice of creating users and groups. > > > There's no doubt about that. So we need a way to define how it does > > > that, while avoiding the rampant bugs that standard packaging systems > > > have for creating them (even the rpm package itself creates the rpm > > > user incorrectly). > > > > > > ACLs depend on users and groups existing; they are a more flexible way > > > of specifying permissions. Conary does not yet encode ACLs, but that > > > is really not hard to add; we just need to wrap libacl in python (if > > > it has not already been done) and define some new streams that encode > > > ACLs. > > > > > > Setuid we handle a bit; we refuse to make anything setuid unless the > > > recipe explicitly says that an executable should be setuid. It's one > > > of the few pieces of information we refuse to trust the installed > > > filesystem on. It does *warn* if it sees an unexpectedly setuid file > > > in the filesystem when packaging. But we think that adding new > > > setuid programs to the system automatically is a mistake. > > > > > > Setting up sudo is really an administrative task, and I don't have > > > any ideas how that would be integrated in a completely generic way > > > into a packaging system. I'd be interested to hear a proposal. > > > > > > SELinux is *very* interesting. I would not be at all surprised if > > > it becomes one of the expected lines of defense for any secure system. > > > SELinux policy is still maturing; it's definitely getting better. > > > > > > > > > > Conary is for building custom distributions, so I think you have to be > > > > careful looking at established practise in Redhat, Suse etc. because > > > > they may not be representative. My own experience of custom > > > > distribution building suggests they are likely to be much more > > > > specifically tuned to a given task. I've found users/groups/permissions > > > > to be important, and painful. I'd really like Conary to fix that for > > > > me. > > > > > > > We want it to work for building generic *and* custom distributions. > > > The custom part is just the hard part. :-) > > > _______________________________________________ > > > conary-list mailing list > > > conary-list@lists.specifixinc.com > > > http://lists.specifixinc.com/mailman/listinfo/conary-list > > > > > _______________________________________________ > > conary-list mailing list > > conary-list@lists.specifixinc.com > > http://lists.specifixinc.com/mailman/listinfo/conary-list > > > > > > > > ______________________________________________________________________ > _______________________________________________ > conary-list mailing list > conary-list@lists.specifixinc.com > http://lists.specifixinc.com/mailman/listinfo/conary-list From chaos@in.fer.no Fri Sep 10 08:35:25 2004 Received: from mail.network-electronics.com (mail.network-electronics.com [195.1.135.55]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ACZObI032226 for ; Fri, 10 Sep 2004 08:35:25 -0400 Received: from in.fer.no (photon.network-electronics.com [10.10.10.150]) by mail.network-electronics.com (Postfix) with ESMTP id 65A49264369 for ; Fri, 10 Sep 2004 14:35:27 +0200 (CEST) Message-ID: <41419F8F.7000302@in.fer.no> Date: Fri, 10 Sep 2004 14:35:27 +0200 From: Geir Thomassen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Conary Discussion Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Cross compiling with conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 12:35:25 -0000 Some ideas/thoughts for cross compiling (xcook?) for embedded systems: The needed functionality is quite simple: * Support the $CROSS environment variable eg. $(CC) = $(CROSS)$(CC) * Set $HOST, $BUILD and $TARGET correctly for configure. * Add a "SUPPORTS_CROSS" flag to the metadata. When installing packages the user would do something like: "conary --config-file conaryrc.myproject update somepackage" the conaryrc.myproject would contain: root ~/devel/myproject/target_root dbpath ~/devel/myproject/target_db We don't want the database to be installed on the target, so the dbroot variable needs to be absolute (the doc says it is relative to root). It is nice to be able to use ~/ and ./ in the config file, since the developers don't need to fiddle with the conaryrc.myproject file they just checked out of the version system to be able to build. When debugging, you would nfsmount the ~/devel/myproject/target_root on the target. When you are satisfied with the result, you would run something like "mkfs.jffs2 --root= ~/devel/myproject/target_root --output=somefile" to create the final system image. What do you think ? Geir Thomassen (gth on IRC) From ken@bizrace.com Fri Sep 10 09:24:18 2004 Received: from mail.bizrace.com (eth0.bizrace.com [66.45.101.41] (may be forged)) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADOIbI032288 for ; Fri, 10 Sep 2004 09:24:18 -0400 Received: by mail.bizrace.com (Postfix, from userid 48) id 57B255F67A; Fri, 10 Sep 2004 09:24:22 -0400 (EDT) Received: from psphinxa.xh1.lilly.com ( [psphinxa.xh1.lilly.com]) as user ken.bizrace.com@web1.bizrace.com by webmail.bizrace.com with HTTP; Fri, 10 Sep 2004 09:24:22 -0400 Message-ID: <1094822662.4141ab0613516@webmail.bizrace.com> Date: Fri, 10 Sep 2004 09:24:22 -0400 From: Ken VanDine To: Conary Discussion References: <20040909183952.GA8569@lambchop.rdu.specifixinc.com> In-Reply-To: <20040909183952.GA8569@lambchop.rdu.specifixinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 40.254.24.8 Subject: Re: metadata X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 13:24:18 -0000 I think this mechanism might be the easiest way to maintain things. One question, will it be easy to query groups for troves? I would like the ability to find all office applications, so group-office could contain abiword, OOo, gnumeric. Then do something like "conary list group-office" will out put: Abiword -- Short description OpenOffice.org -- Short description Gnumeric -- Short description Also, these groups need to be well defined. I would not want tons of arbitrary groups, but I guess the maintainers of the various repositories will have that control. --Ken Quoting "Michael K. Johnson" : > I've been thinking about metadata for Conary. > o I want minimal possible metadata -- the fewer blanks to fill in, > the better job people will do filling in each blank. > o I do not want to have to re-cook metadata with packages; it > should live separately. Re-translating after re-cooking and > re-cooking after re-translating are both wastes of time. > o I'd like to cooperate with other projects for collecting metadata > > I've looked at two existing metadata projects that look interesting > for different reasons: DOAP and freshmeat. Freshmeat has reasonable > coverage of possible metadata per project, and extremely complete > coverage of projects out there. DOAP has perhaps the most complete > description of things that might go in metadata. > > For considering metadata candidates, I have found valuable the table at > http://www-106.ibm.com/developerworks/xml/library/x-osproj2/ > We don't have DOAP's problem of uniquely identifying a project; we > have repositories and troves that we are describing, so we do not > want to use (name, homepage-or-old_homepage) as the unique ID. > > We definitely don't want to recreate or try to compete with freshmeat; > that would be silly and counterproductive. > > I suggest that the items of metadata that we really want to have in the > repository, referenced by troves (i.e. we do not store the name in the > metadata), are: > o summary (short description, a sentence fragment) > o description (arbitrarily long description) > o URL(s) (arbitrarily many top-level URLs, potentially > including project homepage (if any), freshmeat home > page, list home page, etc.) > o License, comprised of > - Name > - URL > either of which may be empty. Furthermore, if the trove > contains items with multiple licenses, then there can be > multiple license items, each with a name and URL. Alternatively, > each license could be a reference to some other item cooked into > the repository, referenced by full version of the object in the > repository? > > The summary and description should be translateable. The repository > versioning should make it possible to track when translations may be > out of date. I'd be interested if anyone here with expertise in > translation has ideas about how well this might work. > > There is the possibility that we'd want the ability to put troves in > categories, like freshmeat-style troves; the example for Conary is: > [Development Status] 3 - Alpha > [Environment] Console (Text Based), X11 Applications :: GTK > [License] OSI Approved :: Common Public License > [Operating System] POSIX > [Programming Language] C, Python > [Topic] Software Development :: Version Control, System :: Archiving :: > Packaging, System :: Installation/Setup, System :: Software Distribution > Tools > > However, that might be more information than we really need. We > do not need development status (irrelevant; it's the status of the > branch it is on that matters), license (included separately), > operating system (implied by branchname as much as we need), > programming language (implied by buildrequires and dependencies > as much as we need it). > > Our Use flags should pretty much cover Environment, as much as we > need it covered, For example, Use.gtk indicates the same thing as > "[Environment] X11 Applications::GTK". > > Topic is kind of like a multi-valued version of what RPM, at least, > calls a category. Now, groups can contain groups, and troves can be > in arbitrarily many groups. My idea is that the description, summary, > and even URL metadata items can apply to ANY trove, not just to > components or packages, and this can substitute for category/topics. > > So group-text-apps and group-desktop and group-system-archiving > and group-software-distribution-tools and group-gnome ... could all > exist, and contain references to these troves. My idea is that you > really do not usually care to which categories any particular trove > belongs; instead, you wish to search for troves fitting a particular > category. So I'm kind of standing the idea of category on its head; > I think that pointers go backwards in at least RPM's way of encoding > this information. > > Opinions about the content of metadata? > > > I'm guessing that most of this information could be harvested from > a variety of sources. I could see one way of getting this information > would be to, from within a directory with a CONARY file defining what > you are committing the description to, run a command like: > cvc describe --freshmeat[=] > By default, it would get the name from the CONARY file, and use the > URL http://freshmeat.net/projects-xml//.xml > but it would use if you specified it as an argument. > It would then get the information off freshmeat, and store it in a > local xml file, which would not be committed to the :source trove > but would instead be stored separately in the repository (though > I suspect on the same branch as the source trove), thus would not > affect cooking the trove, and could be updated (for translation, > etc) entirely separately from the :source trove. > > Similarly, cvc describe --doap=/path/to/doapfile or the equivalent > cvc describe --doap=http://host/path/something.rdf to grab DOAP > information and store relevant bits in our local, simpler record. > > Opinions about this mechanism? > _______________________________________________ > conary-list mailing list > conary-list@lists.specifixinc.com > http://lists.specifixinc.com/mailman/listinfo/conary-list > > -- Ken VanDine biZrace Inc. http://www.biZrace.com kvandine@biZrace.com From johnsonm@specifixinc.com Fri Sep 10 09:24:24 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADOObI032300 for ; Fri, 10 Sep 2004 09:24:24 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 3B3FA1622D for ; Fri, 10 Sep 2004 06:24:27 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADOPNI006460 for ; Fri, 10 Sep 2004 09:24:26 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8ADOPrL006458 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 09:24:25 -0400 Date: Fri, 10 Sep 2004 09:24:25 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040910132425.GA6376@lambchop.rdu.specifixinc.com> References: <41419F8F.7000302@in.fer.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41419F8F.7000302@in.fer.no> User-Agent: Mutt/1.4.1i Subject: Re: Cross compiling with conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 13:24:24 -0000 On Fri, Sep 10, 2004 at 02:35:27PM +0200, Geir Thomassen wrote: > Some ideas/thoughts for cross compiling (xcook?) for embedded systems: Have you checked the cross-* packages out of the repository and looked at them? Also, take a look at the crossMacros in recipe.py -- those can be set like any macros in conaryrc files and on the command line. The values of crossMacros are also on the wiki at http://wiki.specifixinc.com/ConaryRecipe -- they are labelled with "In addition, a few macros used for cross-compilation include" They do enable cross-compilation. No need for a special xcook command -- although you could write a shell script or alias by that name to set the macros to the values you want, of course, if you like. From johnsonm@specifixinc.com Fri Sep 10 09:27:10 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADR9bI032314 for ; Fri, 10 Sep 2004 09:27:09 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id F39541622D for ; Fri, 10 Sep 2004 06:27:12 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADRBNI006539 for ; Fri, 10 Sep 2004 09:27:11 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8ADRBlj006537 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 09:27:11 -0400 Date: Fri, 10 Sep 2004 09:27:11 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040910132711.GB6376@lambchop.rdu.specifixinc.com> References: <41419F8F.7000302@in.fer.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41419F8F.7000302@in.fer.no> User-Agent: Mutt/1.4.1i Subject: Re: Cross compiling with conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 13:27:10 -0000 On Fri, Sep 10, 2004 at 02:35:27PM +0200, Geir Thomassen wrote: > We don't want the database to be installed on the target, so the dbroot > variable needs to be absolute (the doc says it is relative to root). It Well, you could just exclude the database while creating the image. Two issues with building the image that way: o Doing it as non-root means you won't have permissions correct, and most special files (like devices) just cannot be createed o The taghandlers won't get run, leaving a partial installation. From msw@specifixinc.com Fri Sep 10 09:43:31 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADhVbI032339 for ; Fri, 10 Sep 2004 09:43:31 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 77D9C1622D for ; Fri, 10 Sep 2004 06:43:34 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADhXNI006868 for ; Fri, 10 Sep 2004 09:43:33 -0400 Received: (from msw@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8ADhW6t006866 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 09:43:32 -0400 Date: Fri, 10 Sep 2004 09:43:32 -0400 From: Matt Wilson To: Conary Discussion Message-ID: <20040910134332.GB21793@specifixinc.com> References: <41419F8F.7000302@in.fer.no> <20040910132425.GA6376@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910132425.GA6376@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: Cross compiling with conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 13:43:31 -0000 On Fri, Sep 10, 2004 at 09:24:25AM -0400, Michael K. Johnson wrote: > On Fri, Sep 10, 2004 at 02:35:27PM +0200, Geir Thomassen wrote: > > Some ideas/thoughts for cross compiling (xcook?) for embedded systems: > > Have you checked the cross-* packages out of the repository and looked > at them? Also, take a look at the crossMacros in recipe.py -- those > can be set like any macros in conaryrc files and on the command line. Actually, you want to look at bootstrap-*, not cross-*. cross-* packages are the packages which are cross-compile tools. bootstrap-* packages built with the cross-compile tools. These recipes require certain macros be defined at cook time - most notably host and build (both of the lists, on the wiki and in recipe.py, are incomplete). They also require that you have cross compilers in $PATH with an exec prefix of "%(target)-". Cheers, Matt From johnsonm@specifixinc.com Fri Sep 10 09:44:57 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADiubI032352 for ; Fri, 10 Sep 2004 09:44:57 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 1F52A1622D for ; Fri, 10 Sep 2004 06:45:00 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADiwNI006901 for ; Fri, 10 Sep 2004 09:44:58 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8ADiw2a006899 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 09:44:58 -0400 Date: Fri, 10 Sep 2004 09:44:58 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040910134458.GC6376@lambchop.rdu.specifixinc.com> References: <1094633238.2365.166.camel@january.e-complex.ca> <20040908142616.GB1740@lambchop.rdu.specifixinc.com> <1094769878.2365.770.camel@january.e-complex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094769878.2365.770.camel@january.e-complex.ca> User-Agent: Mutt/1.4.1i Subject: Re: Conary vs. RHN X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 13:44:57 -0000 On Thu, Sep 09, 2004 at 04:44:38PM -0600, Stephen Deasey wrote: > Thanks, that was helpful. Couple more questions... Great! :-) I'll answer out of order... > Also, is it possible for the server machine to track local changes on > the machines? Or would you have to create a branch for each machine, > and is that even feasible? The Conary repository doesn't track what is on the local machines. It merely serves up changesets from within the repository as requested; it doesn't know what is installed on the machine. It would be possible to create a branch for each machine, but I'm not sure how feasible it would be without writing scripts to automate most of that work. It should become more feasible with shadows. I'm not sure if it would be the best approach even then, though. > How would you define a subset of a custom distro that say includes a > couple of extra packages and some config changes, You would create your own repository. You would create the extra packages in your own repository, and for the config changes you could branch the packages in question and cook them with the config changes in question, or you could commit a local changeset to your repository containing those config changes. You would also set up your repository to be a caching mirror of our repository (this last part doesn't work yet). Then, in your own repository, you would create a branch from group-dist in our repository, and on that branch you would change the versions of the changed packages to your branch, and you would add the extra packages. You would then cook the new group-dist. However, if you have multiple different sets of configurations, you might want to do things a bit differently. You might want to create the branched group-dist with your extra packages, but NOT include the local changesets in your branched group-dist. Then you can install your branched group-dist on all the machines, and then choose the correct local changeset to apply based on the machine's role. Those local changesets can either be maintained in the repository, or they can be separate files. Those cases act differently, as described in our OLS paper at http://www.specifixinc.com/technology/Reprint-Wilson-OLS2004.pdf > and then roll that out to some already deployed machines? One new thing we plan to do soon is create an ISO image that does not include any changesets; you'll just specify what you want to install and it will get it directly from the repository and install it. You could use that ISO, put a kickstart file on it specifying your branched group-dist, and then use that for the updates. Or you could use the same image with PXE booting to do exactly the same thing. You might choose to install your branched group-dist, plus the appropriate local changeset or changesets for the machine's role. > The definition of the subset would > happen server-side by some non-conary tool. Sure, no makes sense. > The deployed machines may > already be grouped correctly (on the same conary branch?), or you may > need to regroup them (e.g. merge the bio and phys lab machines). For each group, you would create a local changeset containing the changes that you want to be in that group. Then you simply apply the right changeset or set of changesets for the machine in question. From msw@specifixinc.com Fri Sep 10 09:49:39 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADndbI032373 for ; Fri, 10 Sep 2004 09:49:39 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 735C01622D for ; Fri, 10 Sep 2004 06:49:42 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADnfNI007042 for ; Fri, 10 Sep 2004 09:49:41 -0400 Received: (from msw@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8ADnfFs007040 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 09:49:41 -0400 Date: Fri, 10 Sep 2004 09:49:41 -0400 From: Matt Wilson To: Conary Discussion Message-ID: <20040910134941.GC21793@specifixinc.com> References: <41419F8F.7000302@in.fer.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41419F8F.7000302@in.fer.no> User-Agent: Mutt/1.4.1i Subject: Re: Cross compiling with conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 13:49:39 -0000 On Fri, Sep 10, 2004 at 02:35:27PM +0200, Geir Thomassen wrote: > Some ideas/thoughts for cross compiling (xcook?) for embedded systems: > > The needed functionality is quite simple: > > * Support the $CROSS environment variable eg. $(CC) = $(CROSS)$(CC) setting macros.cc to %(target)s-gcc is probably the right thing to do here, if autoconf doesn't detect the correct gcc automatically via the correct --host=, --target=, --build= arguments. Cheers From johnsonm@specifixinc.com Fri Sep 10 09:49:56 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADnubI032386 for ; Fri, 10 Sep 2004 09:49:56 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 5E5BD1622D for ; Fri, 10 Sep 2004 06:49:59 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADnwNI007048 for ; Fri, 10 Sep 2004 09:49:58 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8ADnwS2007046 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 09:49:58 -0400 Date: Fri, 10 Sep 2004 09:49:58 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040910134958.GD6376@lambchop.rdu.specifixinc.com> References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> <1094632070.2365.145.camel@january.e-complex.ca> <1094637972.2365.205.camel@january.e-complex.ca> <20040908134613.GA1740@lambchop.rdu.specifixinc.com> <1094772481.2365.816.camel@january.e-complex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094772481.2365.816.camel@january.e-complex.ca> User-Agent: Mutt/1.4.1i Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 13:49:56 -0000 On Thu, Sep 09, 2004 at 05:28:01PM -0600, Stephen Deasey wrote: > You could then imagine creating as new tag handler which used sudo with > GUI instead -- it would ask you for your own password, not root's. Well, whether consolehelper asks you for your password or the root password depends on the configuration of that particular application. Check out the files in /etc/security/console.apps/ -- if they say "USER=root" then they ask for the root password. If they do not specify "USER=", or if they specify "USER=" they ask for the password of the logged-in user. So which password to ask for is orthogonal to whether consolehelper or sudo with GUI is used. I hadn't thought about setting up this with taghandlers. It's an interesting idea. > You could take this further. The tag handler could give each admin > command it's own privilege which is required to run it, then bundle all > the privileges into the admin role. Now someone with the admin role can > run all the admin commands, such as 'add user', and arbitrary other > people could be given 'change date' privs as needed. If the tag was > extended from just admin to admin, sysadmin, you could create two roles, > etc... I can't imagine doing this without implementing SELinux pervasively. That doesn't make it a bad idea. :-) > Anyway, the idea is that by simplifying the recipes by providing higher > level security concepts, you could achieve a more powerful, flexible > system. In practise when a package works with supplementary groups, > it's really just looking for finer grained permissions and I'd like to > see that idea captured in some way. I agree in principle. I'm not sure practice is quite ready for that, though. I'd have to think a bit more about that. From johnsonm@specifixinc.com Fri Sep 10 09:55:54 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADtsbI032405 for ; Fri, 10 Sep 2004 09:55:54 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id C82021622D for ; Fri, 10 Sep 2004 06:55:57 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ADtuNI007194 for ; Fri, 10 Sep 2004 09:55:56 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8ADtukd007192 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 09:55:56 -0400 Date: Fri, 10 Sep 2004 09:55:56 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040910135556.GE6376@lambchop.rdu.specifixinc.com> References: <20040909183952.GA8569@lambchop.rdu.specifixinc.com> <1094822662.4141ab0613516@webmail.bizrace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094822662.4141ab0613516@webmail.bizrace.com> User-Agent: Mutt/1.4.1i Subject: Re: metadata X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 13:55:54 -0000 On Fri, Sep 10, 2004 at 09:24:22AM -0400, Ken VanDine wrote: > I think this mechanism might be the easiest way to maintain things. One > question, will it be easy to query groups for troves? Sure -- it's already easy to find out what is in it; and I would expect that we'd end up using the same tools to query groups, packages, and components since they are both troves... > Also, these groups need to be well defined. I would not want tons of arbitrary > groups, but I guess the maintainers of the various repositories will have that > control. Well, we'd define them for our distribution. Then, like any other troves, they could be branched. The main problem with this idea of mine, in which categories nominate troves, rather than troves nominating themselves into categories, does involve multiple repositories. For example, let's say I have installed group-foo from conary.specifixinc.com@spx:linux, and then I install the blah program from conary.example.com@spx:linux. Let's also assume that the blah program logically belongs in group-foo. Too bad, it's not there. Branching group-foo doesn't help, because what if you also want to install the bar program from conary.anotherexample.com@spx:linux; you'd either have to have the group-foo from conary.example.com or from conary.otherexample.com, and so either blah or bar would be left out. So maybe it's not the greatest idea. :-( From david.christian@gmail.com Fri Sep 10 10:07:01 2004 Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AE70bI032436 for ; Fri, 10 Sep 2004 10:07:00 -0400 Received: by mproxy.gmail.com with SMTP id 73so695018rnl for ; Fri, 10 Sep 2004 07:07:04 -0700 (PDT) Received: by 10.38.59.69 with SMTP id h69mr4256657rna; Fri, 10 Sep 2004 07:07:04 -0700 (PDT) Received: by 10.38.81.41 with HTTP; Fri, 10 Sep 2004 07:07:04 -0700 (PDT) Message-ID: <63940b004091007072d2b1e17@mail.gmail.com> Date: Fri, 10 Sep 2004 10:07:04 -0400 From: David Christian To: Conary Discussion In-Reply-To: <20040910134458.GC6376@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1094633238.2365.166.camel@january.e-complex.ca> <20040908142616.GB1740@lambchop.rdu.specifixinc.com> <1094769878.2365.770.camel@january.e-complex.ca> <20040910134458.GC6376@lambchop.rdu.specifixinc.com> Subject: Re: Conary vs. RHN X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Christian , Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 14:07:01 -0000 > > The Conary repository doesn't track what is on the local machines. It > merely serves up changesets from within the repository as requested; it > doesn't know what is installed on the machine. > One thing you can do with conary is create a local changeset of a package -- 'conary localcs ' performs that operation. The changeset includes any changes to the package files that you have made on your local machine, so if the changes to the local machine are known by conary, there is a way to determine what changes have been made. The limitation to this approach is that local changesets will not include any added configuration files. Conary would not have any way of knowing, say, if you add another file in /etc/http/conf.d/. One thing I'd like to see eventually is a way to specify in a recipe that files that match a regex are owned by a package, so that when you are creating a local changeset, they can be included. Such a method would raise some questions about what happens when two filters match a particular file, however. David From chaos@in.fer.no Fri Sep 10 10:09:47 2004 Received: from mail.network-electronics.com (mail.network-electronics.com [195.1.135.55]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AE9lbI032449 for ; Fri, 10 Sep 2004 10:09:47 -0400 Received: from in.fer.no (photon.network-electronics.com [10.10.10.150]) by mail.network-electronics.com (Postfix) with ESMTP id B7A89264369 for ; Fri, 10 Sep 2004 16:09:50 +0200 (CEST) Message-ID: <4141B5AE.2060805@in.fer.no> Date: Fri, 10 Sep 2004 16:09:50 +0200 From: Geir Thomassen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Conary Discussion References: <41419F8F.7000302@in.fer.no> <20040910132711.GB6376@lambchop.rdu.specifixinc.com> In-Reply-To: <20040910132711.GB6376@lambchop.rdu.specifixinc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Cross compiling with conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 14:09:47 -0000 Michael K. Johnson wrote: > On Fri, Sep 10, 2004 at 02:35:27PM +0200, Geir Thomassen wrote: > > o Doing it as non-root means you won't have permissions correct, > and most special files (like devices) just cannot be createed mkfs.jffs2 have the options --squash-uids and --devtable to fix building as root. You will find tools like this for most embedded file systems. I think there is something called genext2 for ext2. Geir From msw@specifixinc.com Fri Sep 10 10:18:24 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AEINbI032471 for ; Fri, 10 Sep 2004 10:18:23 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id DEFCC1622D for ; Fri, 10 Sep 2004 07:18:26 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AEIPNI007834 for ; Fri, 10 Sep 2004 10:18:25 -0400 Received: (from msw@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8AEIPSO007832 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 10:18:25 -0400 Date: Fri, 10 Sep 2004 10:18:25 -0400 From: Matt Wilson To: Conary Discussion Message-ID: <20040910141825.GA7685@specifixinc.com> References: <41419F8F.7000302@in.fer.no> <20040910132711.GB6376@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910132711.GB6376@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: Cross compiling with conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 14:18:24 -0000 On Fri, Sep 10, 2004 at 09:27:11AM -0400, Michael K. Johnson wrote: > > o The taghandlers won't get run, leaving a partial installation. Most likely you wouldn't be able to execute binaries that the scripts call anyway, since host != target. The tag handler execution can be deferred with the --tag-script option and run on the target machine or target emulator later. Cheers, Matt From johnsonm@specifixinc.com Fri Sep 10 10:23:51 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AENpbI032488 for ; Fri, 10 Sep 2004 10:23:51 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 70B1E1622D for ; Fri, 10 Sep 2004 07:23:54 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AENrNI008120 for ; Fri, 10 Sep 2004 10:23:53 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8AENrKY008118 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 10:23:53 -0400 Date: Fri, 10 Sep 2004 10:23:53 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040910142352.GA8041@lambchop.rdu.specifixinc.com> References: <41419F8F.7000302@in.fer.no> <20040910132711.GB6376@lambchop.rdu.specifixinc.com> <4141B5AE.2060805@in.fer.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4141B5AE.2060805@in.fer.no> User-Agent: Mutt/1.4.1i Subject: Re: Cross compiling with conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 14:23:51 -0000 On Fri, Sep 10, 2004 at 04:09:50PM +0200, Geir Thomassen wrote: > Michael K. Johnson wrote: > >On Fri, Sep 10, 2004 at 02:35:27PM +0200, Geir Thomassen wrote: > > > > o Doing it as non-root means you won't have permissions correct, > > and most special files (like devices) just cannot be createed > > mkfs.jffs2 have the options --squash-uids and --devtable to fix building > as root. Well, you still need to get the information from somewhere... Conary doesn't support storing that information at this point. No reason that it couldn't, though, AFAIK. I'm guessing that it has something like --exclude as well? That could be used to ignore the database... > You will find tools like this for most embedded file systems. I think > there is something called genext2 for ext2. Yeah, it's the getting the information to the tool that is the key. From msw@specifixinc.com Fri Sep 10 10:59:08 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AEx7bI032552 for ; Fri, 10 Sep 2004 10:59:07 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id D7FE41622D for ; Fri, 10 Sep 2004 07:59:10 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AEx9NI009147 for ; Fri, 10 Sep 2004 10:59:09 -0400 Received: (from msw@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8AEx9ft009145 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 10:59:09 -0400 Date: Fri, 10 Sep 2004 10:59:09 -0400 From: Matt Wilson To: Conary Discussion Message-ID: <20040910145909.GB7685@specifixinc.com> References: <41419F8F.7000302@in.fer.no> <20040910132711.GB6376@lambchop.rdu.specifixinc.com> <4141B5AE.2060805@in.fer.no> <20040910142352.GA8041@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910142352.GA8041@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: Cross compiling with conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 14:59:08 -0000 On Fri, Sep 10, 2004 at 10:23:53AM -0400, Michael K. Johnson wrote: > > Well, you still need to get the information from somewhere... Conary > doesn't support storing that information at this point. No reason > that it couldn't, though, AFAIK. Support storing it where? Everything you need to build the entries in a devtable file is in the changeset. You could extract devtable entries from the changesets as a separate step, or easily add writing a devtable-like file when the file restore code comes across a device node entry and you're not running as root. > I'm guessing that it has something like --exclude as well? That could > be used to ignore the database... Nope, there's no --exclude. Cheers, Matt From johnsonm@specifixinc.com Fri Sep 10 11:12:34 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AFCXbI032631 for ; Fri, 10 Sep 2004 11:12:33 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 140111622D for ; Fri, 10 Sep 2004 08:12:37 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AFCZNI009586 for ; Fri, 10 Sep 2004 11:12:35 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8AFCZUR009584 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 11:12:35 -0400 Date: Fri, 10 Sep 2004 11:12:35 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040910151235.GA9164@lambchop.rdu.specifixinc.com> References: <41419F8F.7000302@in.fer.no> <20040910132711.GB6376@lambchop.rdu.specifixinc.com> <4141B5AE.2060805@in.fer.no> <20040910142352.GA8041@lambchop.rdu.specifixinc.com> <20040910145909.GB7685@specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910145909.GB7685@specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: Cross compiling with conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 15:12:34 -0000 On Fri, Sep 10, 2004 at 10:59:09AM -0400, Matt Wilson wrote: > On Fri, Sep 10, 2004 at 10:23:53AM -0400, Michael K. Johnson wrote: > > > > Well, you still need to get the information from somewhere... Conary > > doesn't support storing that information at this point. No reason > > that it couldn't, though, AFAIK. > > Support storing it where? On the filesystem. There's no code in conary for pulling device information and writing it to a devtable. Right now. > Everything you need to build the entries in > a devtable file is in the changeset. You could extract devtable > entries from the changesets as a separate step, or easily add writing > a devtable-like file when the file restore code comes across a device > node entry and you're not running as root. Yes, that's my point -- we agree entirely. > > I'm guessing that it has something like --exclude as well? That could > > be used to ignore the database... > > Nope, there's no --exclude. Good thing the source code is available. :-) From msw@specifixinc.com Fri Sep 10 11:17:18 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AFHIbI032647 for ; Fri, 10 Sep 2004 11:17:18 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id CE0FC1622D for ; Fri, 10 Sep 2004 08:17:21 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AFHKNI009804 for ; Fri, 10 Sep 2004 11:17:20 -0400 Received: (from msw@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8AFHKXj009802 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 11:17:20 -0400 Date: Fri, 10 Sep 2004 11:17:20 -0400 From: Matt Wilson To: Conary Discussion Message-ID: <20040910151720.GC7685@specifixinc.com> References: <41419F8F.7000302@in.fer.no> <20040910132711.GB6376@lambchop.rdu.specifixinc.com> <4141B5AE.2060805@in.fer.no> <20040910142352.GA8041@lambchop.rdu.specifixinc.com> <20040910145909.GB7685@specifixinc.com> <20040910151235.GA9164@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910151235.GA9164@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: Cross compiling with conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 15:17:19 -0000 On Fri, Sep 10, 2004 at 11:12:35AM -0400, Michael K. Johnson wrote: > > Nope, there's no --exclude. > > Good thing the source code is available. :-) It doesn't make sense to *require* that the database live inside the root directory for the image... Cheers, Matt From johnsonm@specifixinc.com Fri Sep 10 14:12:00 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AIBxbI000459 for ; Fri, 10 Sep 2004 14:12:00 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id B4E9016230 for ; Fri, 10 Sep 2004 11:12:02 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AIC0NI013683 for ; Fri, 10 Sep 2004 14:12:00 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8AIC0kB013681 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 14:12:00 -0400 Date: Fri, 10 Sep 2004 14:12:00 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040910181200.GA13296@lambchop.rdu.specifixinc.com> References: <20040909183952.GA8569@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909183952.GA8569@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: metadata X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 18:12:00 -0000 On Thu, Sep 09, 2004 at 02:39:52PM -0400, Michael K. Johnson wrote: > o URL(s) (arbitrarily many top-level URLs, potentially > including project homepage (if any), freshmeat home > page, list home page, etc.) I should be more explicit that these are top-level URLs, and that we do not want many of them. Otherwise it's just too many places for a user to look. One topic of discussion would be if we should mark specialized URLs as such. I don't want to get into providing URLs for viewcvs/similar, screenshots, documentation, this, that, and the other thing -- that is what things like freshmeat project pages are for. I'd say home page and maybe one aggregator like a freshmeat project pages should be the max you would normally see. We do not want Conary metadata to become a competing aggregator to things like freshmeat. > There is the possibility that we'd want the ability to put troves in > categories, like freshmeat-style troves; the example for Conary is: ... > Topic is kind of like a multi-valued version of what RPM, at least, > calls a category. Now, groups can contain groups, and troves can be > in arbitrarily many groups. My idea is that the description, summary, > and even URL metadata items can apply to ANY trove, not just to > components or packages, and this can substitute for category/topics. ... > So I'm kind of standing the idea of category on its head; > I think that pointers go backwards in at least RPM's way of encoding > this information. As Ken convinced me by pointing out the elephant in the room, while there is great value in creating groups of troves and having the group and a description, it is not a replacement for categories. I would propose, then, that for categories we use contents defined to be the same as ESR-style trove "Topics". > I'm guessing that most of this information could be harvested from > a variety of sources. I could see one way of getting this information > would be to, from within a directory with a CONARY file defining what It is probably not a good idea to keep them in the same place, for a few reasons. o Versioning confusion -- the more I look at this, the more I realize the implications of the desirable goal of separating the versioning of the metadata from versioning of the packages. o Access controls -- it is quite likely that organizations who want to control changes being made to their repositories will have different rules for who can change recipes versus who can change metadata. It is entirely possible that for some groups the sets could be completely disjoint -- developers touch recipes, documentation specialists touch metadata. I've been changing my mind about associating metadata with specific versions nodes. My old idea was to root branches of metadata relative to specific version nodes. I'm not sure that makes sense. It might make more sense to root branches of metadata relative to a label instead of to a node. I.e. instead of being relative to foo /conary.specifixinc.com@spx:linux/1.2.3-3 it would be relative to foo conary.specifixinc.com@spx:linux That way new metadata applies to older releases on the same branch. The reason to have it label-specific is that over time, two different projects could share a name in the repository, as long as they do not live on the same branch. The repository is meant to live forever and to support multiple trunks of development for the same name, so we really need to account for this possibility. Thoughts? > The summary and description should be translateable. The repository > versioning should make it possible to track when translations may be > out of date. I'd be interested if anyone here with expertise in > translation has ideas about how well this might work. It sounds like however the data is stored in the repository, it is important that we export to standard .pot/po files useable in the tools that translators are already used to, to keep from making their jobs harder. We can also provide other information to them, such as diffs showing changes to the source language. In fact, perhaps we can put the old versions of each string in a comment in the .po file above the new string? I don't have a lot of expertise here, so I am interested in feedback from people with translation expertise. From johnsonm@specifixinc.com Fri Sep 10 14:15:51 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AIFobI000475 for ; Fri, 10 Sep 2004 14:15:50 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 5472A16230 for ; Fri, 10 Sep 2004 11:15:54 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AIFrNI013992 for ; Fri, 10 Sep 2004 14:15:53 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8AIFrWe013990 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 14:15:53 -0400 Date: Fri, 10 Sep 2004 14:15:53 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifixinc.com Message-ID: <20040910181553.GA13936@lambchop.rdu.specifixinc.com> References: <20040909225442.GA16314@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909225442.GA16314@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: #!/bin/env policy X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 18:15:51 -0000 On Thu, Sep 09, 2004 at 06:54:42PM -0400, Michael K. Johnson wrote: > I'm thinking that I ought to create a policy that re-writes /bin/env > into the canonical path to foo in the distribution for shell scripts, > by default. This policy now exists, and works. We also prohibit relative interpreter paths. Those function relative to the current working directory, which is very odd and unreasonable in a packaged script, whatever use it might have in a specific situation. From johnsonm@specifixinc.com Fri Sep 10 14:47:57 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AIlubI000527 for ; Fri, 10 Sep 2004 14:47:57 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 3E24416399 for ; Fri, 10 Sep 2004 11:48:00 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AIlwNI015222 for ; Fri, 10 Sep 2004 14:47:58 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8AIlwvB015220 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 14:47:58 -0400 Date: Fri, 10 Sep 2004 14:47:58 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040910184758.GA14698@lambchop.rdu.specifixinc.com> References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> <1094632070.2365.145.camel@january.e-complex.ca> <1094637972.2365.205.camel@january.e-complex.ca> <20040908134613.GA1740@lambchop.rdu.specifixinc.com> <1094772481.2365.816.camel@january.e-complex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094772481.2365.816.camel@january.e-complex.ca> User-Agent: Mutt/1.4.1i Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 18:47:57 -0000 On Thu, Sep 09, 2004 at 05:28:01PM -0600, Stephen Deasey wrote: > You could take this further. The tag handler could give each admin > command it's own privilege which is required to run it, then bundle all > the privileges into the admin role. Now someone with the admin role can > run all the admin commands, such as 'add user', and arbitrary other > people could be given 'change date' privs as needed. If the tag was > extended from just admin to admin, sysadmin, you could create two roles, > etc... > > Anyway, the idea is that by simplifying the recipes by providing higher > level security concepts, you could achieve a more powerful, flexible > system. In practise when a package works with supplementary groups, > it's really just looking for finer grained permissions and I'd like to > see that idea captured in some way. This *is* a really interesting idea. We do need whatever we do to be canonically reducible to existing practice, but if this higher-level concept can be adequately specified and was compatible with existing practice, then we could use this higher-level concept to design the interface. However, I'm someone who really needs to think in very concerete terms before the abstractions make much sense to me. Could you perhaps come up with examples of how this could look? I'm thinking everything from what it might look like specified in a recipe to how the mechanism works to how this maps both to users/gruops (that is, maps to existing practice) and new ways of handling the information, maybe with SELinux. From kero@arena.game-server.cc Fri Sep 10 14:40:04 2004 Received: from nessus.m38c.nl (c115110.upc-c.chello.nl [212.187.115.110]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8AIe3bI000512 for ; Fri, 10 Sep 2004 14:40:03 -0400 Received: from kero by nessus.m38c.nl with local (Exim 3.36 #1 (Debian)) id 1C5qJT-0006YZ-00 for ; Fri, 10 Sep 2004 20:39:59 +0200 Date: Fri, 10 Sep 2004 20:39:58 +0200 To: Conary Discussion Message-ID: <20040910183958.GA25137@arena.game-server.cc> References: <41419F8F.7000302@in.fer.no> <20040910132711.GB6376@lambchop.rdu.specifixinc.com> <4141B5AE.2060805@in.fer.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4141B5AE.2060805@in.fer.no> User-Agent: Mutt/1.5.6+20040818i From: Kero van Gelder X-Mailman-Approved-At: Fri, 10 Sep 2004 14:53:37 -0400 Subject: Re: Cross compiling with conary X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kero@chello.nl, Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 18:40:04 -0000 On Fri, Sep 10, 2004 at 04:09:50PM +0200, Geir Thomassen wrote: > Michael K. Johnson wrote: > >On Fri, Sep 10, 2004 at 02:35:27PM +0200, Geir Thomassen wrote: > > > > o Doing it as non-root means you won't have permissions correct, > > and most special files (like devices) just cannot be createed > > mkfs.jffs2 have the options --squash-uids and --devtable to fix building > as root. > > You will find tools like this for most embedded file systems. I think > there is something called genext2 for ext2. `fakeroot` has been working fine for me to produce ipkgs. wraps around everything :) From ken@biZrace.com Fri Sep 10 21:22:13 2004 Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8B1MCbI001543 for ; Fri, 10 Sep 2004 21:22:12 -0400 Received: from [192.168.1.101] (cpe-024-163-091-077.nc.rr.com [24.163.91.77]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i8B1MEiA029897 for ; Fri, 10 Sep 2004 21:22:15 -0400 (EDT) Message-ID: <41425346.3000008@biZrace.com> Date: Fri, 10 Sep 2004 21:22:14 -0400 From: Ken VanDine User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Conary Discussion References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> <1094632070.2365.145.camel@january.e-complex.ca> <1094637972.2365.205.camel@january.e-complex.ca> <20040908134613.GA1740@lambchop.rdu.specifixinc.com> <1094772481.2365.816.camel@january.e-complex.ca> <20040910184758.GA14698@lambchop.rdu.specifixinc.com> In-Reply-To: <20040910184758.GA14698@lambchop.rdu.specifixinc.com> Content-Type: multipart/alternative; boundary="------------080606020702070507090901" X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2004 01:22:13 -0000 This is a multi-part message in MIME format. --------------080606020702070507090901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This is something that I find really interesting too. I am usually the guy that likes to challenge the norm, and "think outside the box" (to use some MBA turns). I am not saying this is something that shouldn't be considered, but It may be to far off from your standard Linux practice (what ever that is). I know all distros are different, but things like user/groups are very standard. What would be really nice is to make this work, but still have the capability to build a distro that follows the current practice by simply changing a flag. And in turn, I would hope that the concepts may become more of an accepted standard. What do you guys think? Do you think I am out of line? I know I don't sound like it, but I am excited about it. We have put alot of time in managing sudo rights to do those types of tasks. The problem is that sudo isn't something that most users understand. It also doesn't scale well. Just my .02 worth. --Ken Michael K. Johnson wrote: >On Thu, Sep 09, 2004 at 05:28:01PM -0600, Stephen Deasey wrote: > > >>You could take this further. The tag handler could give each admin >>command it's own privilege which is required to run it, then bundle all >>the privileges into the admin role. Now someone with the admin role can >>run all the admin commands, such as 'add user', and arbitrary other >>people could be given 'change date' privs as needed. If the tag was >>extended from just admin to admin, sysadmin, you could create two roles, >>etc... >> >>Anyway, the idea is that by simplifying the recipes by providing higher >>level security concepts, you could achieve a more powerful, flexible >>system. In practise when a package works with supplementary groups, >>it's really just looking for finer grained permissions and I'd like to >>see that idea captured in some way. >> >> > >This *is* a really interesting idea. We do need whatever we do to be >canonically reducible to existing practice, but if this higher-level >concept can be adequately specified and was compatible with existing >practice, then we could use this higher-level concept to design the >interface. > >However, I'm someone who really needs to think in very concerete terms >before the abstractions make much sense to me. > >Could you perhaps come up with examples of how this could look? I'm >thinking everything from what it might look like specified in a recipe >to how the mechanism works to how this maps both to users/gruops (that >is, maps to existing practice) and new ways of handling the information, >maybe with SELinux. >_______________________________________________ >conary-list mailing list >conary-list@lists.specifixinc.com >http://lists.specifixinc.com/mailman/listinfo/conary-list > > > --------------080606020702070507090901 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit This is something that I find really interesting too.  I am usually the guy that likes to challenge the norm, and "think outside the box" (to use some MBA turns).   I am not saying this is something that shouldn't be considered, but It may be to far off from your standard Linux practice (what ever that is).  I know all distros are different, but things like user/groups are very standard.  What would be really nice is to make this work, but still have the capability to build a distro that follows the current practice by simply changing a flag.  And in turn, I would hope that the concepts may become more of an accepted standard. 

What do you guys think?  Do you think I am out of line?  I know I don't sound like it, but I am  excited about it.  We have put alot of time in managing sudo rights to do those types of tasks.  The problem is that sudo isn't something that most users understand.  It also doesn't scale well. 

Just my .02 worth.

--Ken


Michael K. Johnson wrote: 
On Thu, Sep 09, 2004 at 05:28:01PM -0600, Stephen Deasey wrote:
  
You could take this further. The tag handler could give each admin
command it's own privilege which is required to run it, then bundle all
the privileges into the admin role.  Now someone with the admin role can
run all the admin commands, such as 'add user', and arbitrary other
people could be given 'change date' privs as needed.  If the tag was
extended from just admin to admin, sysadmin, you could create two roles,
etc...

Anyway, the idea is that by simplifying the recipes by providing higher
level security concepts, you could achieve a more powerful, flexible
system.  In practise when a package works with supplementary groups,
it's really just looking for finer grained permissions and I'd like to
see that idea captured in some way.
    

This *is* a really interesting idea.  We do need whatever we do to be
canonically reducible to existing practice, but if this higher-level
concept can be adequately specified and was compatible with existing
practice, then we could use this higher-level concept to design the
interface.

However, I'm someone who really needs to think in very concerete terms
before the abstractions make much sense to me.

Could you perhaps come up with examples of how this could look?  I'm
thinking everything from what it might look like specified in a recipe
to how the mechanism works to how this maps both to users/gruops (that
is, maps to existing practice) and new ways of handling the information,
maybe with SELinux.
_______________________________________________
conary-list mailing list
conary-list@lists.specifixinc.com
http://lists.specifixinc.com/mailman/listinfo/conary-list

--------------080606020702070507090901-- From johnsonm@specifixinc.com Fri Sep 10 22:06:47 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8B26lbI001599 for ; Fri, 10 Sep 2004 22:06:47 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 027E916212 for ; Fri, 10 Sep 2004 19:06:51 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8B26nNI025594 for ; Fri, 10 Sep 2004 22:06:49 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8B26nDc025592 for conary-list@lists.specifixinc.com; Fri, 10 Sep 2004 22:06:49 -0400 Date: Fri, 10 Sep 2004 22:06:49 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040911020649.GA25491@lambchop.rdu.specifixinc.com> References: <20040903200856.GA30987@lambchop.rdu.specifixinc.com> <1094632070.2365.145.camel@january.e-complex.ca> <1094637972.2365.205.camel@january.e-complex.ca> <20040908134613.GA1740@lambchop.rdu.specifixinc.com> <1094772481.2365.816.camel@january.e-complex.ca> <20040910184758.GA14698@lambchop.rdu.specifixinc.com> <41425346.3000008@biZrace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41425346.3000008@biZrace.com> User-Agent: Mutt/1.4.1i Subject: Re: user/group handling X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2004 02:06:48 -0000 On Fri, Sep 10, 2004 at 09:22:14PM -0400, Ken VanDine wrote: > use some MBA turns). I am not saying this is something that shouldn't > be considered, but It may be to far off from your standard Linux > practice (what ever that is). I know all distros are different, but > things like user/groups are very standard. What would be really nice is > to make this work, but still have the capability to build a distro that > follows the current practice by simply changing a flag. And in turn, I My point is that the ONLY way that something beyond what I proposed can make it is if it fully supports existing practice. At this time, the existing practice would be the default behavior, without any doubt. The only question is whether it is reasonably possible to *also*, *optionally* support any alternative practices. If and when some other behavior could become the default would depend on what was proposed and any changes in standard practice over time, and would be a considerable time coming. From johnsonm@specifixinc.com Tue Sep 14 12:19:56 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i8EGJum4014408; Tue, 14 Sep 2004 12:19:56 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 00D601622D; Tue, 14 Sep 2004 09:20:03 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8EGK1NI011022; Tue, 14 Sep 2004 12:20:01 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8EGK0dR011020; Tue, 14 Sep 2004 12:20:00 -0400 Date: Tue, 14 Sep 2004 12:20:00 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifix.com, distro-list@lists.specifix.com Message-ID: <20040914162000.GA10747@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Cc: Subject: Domain name addition X-BeenThere: conary-list@lists.specifixinc.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 16:19:57 -0000 Just wanted to let folks know that Specifix, Inc. now owns the "specifix.com" domain. (Yay!) The mailing list should now respond at both the old and the new address. Please let us know about any difficulties in that regard. For now, the repository will have to continue to live at the "conary.specifixinc.com" and "contrib.specifixinc.com" because the domain name is embedded in the version references. Because we're still alpha, we'll probably end up keeping things as clean as possible by modifying the repository by hand. We'll do this at the same time as another conversion that will need to be applied on the client end, so that we do not add another step. We will need to modify both the repository and client databases in order to enable dependency resolution, and we currently expect to do the version modifications at the same time. From john@metalab.unc.edu Tue Sep 14 14:27:28 2004 Received: from cardoel.metalab.unc.edu (cardoel.metalab.unc.edu [152.2.241.124]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i8EIRRm4014668 for ; Tue, 14 Sep 2004 14:27:28 -0400 Received: by cardoel.metalab.unc.edu (Postfix, from userid 500) id 265374EEFB; Tue, 14 Sep 2004 14:27:36 -0400 (EDT) From: John Reuning To: Conary Discussion In-Reply-To: <20040910181200.GA13296@lambchop.rdu.specifixinc.com> References: <20040909183952.GA8569@lambchop.rdu.specifixinc.com> <20040910181200.GA13296@lambchop.rdu.specifixinc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1095186455.541.156.camel@cardoel.metalab.unc.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 14 Sep 2004 14:27:35 -0400 Cc: Subject: Re: metadata X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 18:27:28 -0000 After digesting a bit more about Conary and the metadata question, I think maybe using a metadata scheme such as OMF would work well. OMF has the benefit of being general, very close to dublin core, and designed for open source software. Mapping from sourceforge, freshmeat, LSM, and others should be straightforward. DOAP would also work, but AFAIK, it only exists as an RDF vocabulary. It's easy to validate the RDF syntax, but not the metadata itself. So, you'd have to embed the required field or data formatting checks into the application. If the plan is to have large numbers of xml metadata files, it might be helpful to rely on an xml dtd or xsd schema to validate the content on the way in. The current version of OMF (http://www.ibiblio.org/osrt/omf/) looks like this. All fields are optional & repeatable except where noted. creator (mandatory) maintainer contributor title (mandatory) date (not repeatable) version.identifier version.date version.description subject (i.e. keywords) description type format.dtd format.mime identifier source language relation coverage.geographic coverage.distribution coverage.kernel coverage.architecture coverage.os rights.type rights.license rights.license.version rights.holder Of course, since the elements are general, metadata authors would need some guidance on what info to put where. Scrollkeeper has made a few changes to OMF, such as adding subject.category for the trove (ESR definition) categories: I'm working on a new version of OMF that will integrate most of the scrollkeeper changes. It'll be released in dtd, xsd schema, and rdf schema form. If you'd like to see other element additions, I'm open to suggestion. :) Thanks, -John R. From johnsonm@specifixinc.com Tue Sep 14 14:49:10 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i8EIn9m4014696 for ; Tue, 14 Sep 2004 14:49:10 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifixinc.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id EBE241622D for ; Tue, 14 Sep 2004 11:49:17 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8EInGGP018433 for ; Tue, 14 Sep 2004 14:49:16 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8EInGWC018431 for conary-list@lists.specifix.com; Tue, 14 Sep 2004 14:49:16 -0400 Date: Tue, 14 Sep 2004 14:49:16 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040914184916.GA18298@lambchop.rdu.specifixinc.com> References: <20040909183952.GA8569@lambchop.rdu.specifixinc.com> <20040910181200.GA13296@lambchop.rdu.specifixinc.com> <1095186455.541.156.camel@cardoel.metalab.unc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095186455.541.156.camel@cardoel.metalab.unc.edu> User-Agent: Mutt/1.4.1i Subject: Re: metadata X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 18:49:10 -0000 On Tue, Sep 14, 2004 at 02:27:35PM -0400, John Reuning wrote: > After digesting a bit more about Conary and the metadata question, I > think maybe using a metadata scheme such as OMF would work well. OMF > has the benefit of being general, very close to dublin core, and > designed for open source software. Mapping from sourceforge, freshmeat, > LSM, and others should be straightforward. Well, I'd want to use a restricted subset, for sure. Like I've said a few times, we don't want to compete with aggregators. I'd rather link to aggregators and have only the information we really need in the repository. So for any field beyond what I've specified, I'm looking for reasons why, specifically, it should be in a conary repository, as opposed to a more general aggregator. Remember that Conary metadata I'm currentl thinking being uniquely identified by a branch in a Conary repository; that's very different from things like freshmeat projects. Now, URLs that link to various well-defined resource records for a project (like OMF) might make sense to me. Is there a canonical source for OMF records that already exist for a wide variety of projects? From john@metalab.unc.edu Tue Sep 14 15:25:52 2004 Received: from cardoel.metalab.unc.edu (cardoel.metalab.unc.edu [152.2.241.124]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i8EJPqm4014924 for ; Tue, 14 Sep 2004 15:25:52 -0400 Received: by cardoel.metalab.unc.edu (Postfix, from userid 500) id D181A4EEFB; Tue, 14 Sep 2004 15:26:00 -0400 (EDT) From: John Reuning To: Conary Discussion In-Reply-To: <20040914184916.GA18298@lambchop.rdu.specifixinc.com> References: <20040909183952.GA8569@lambchop.rdu.specifixinc.com> <20040910181200.GA13296@lambchop.rdu.specifixinc.com> <1095186455.541.156.camel@cardoel.metalab.unc.edu> <20040914184916.GA18298@lambchop.rdu.specifixinc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1095189960.541.188.camel@cardoel.metalab.unc.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 14 Sep 2004 15:26:00 -0400 Subject: Re: metadata X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 19:25:52 -0000 On Tue, 2004-09-14 at 14:49, Michael K. Johnson wrote: > Well, I'd want to use a restricted subset, for sure. Like I've said a > few times, we don't want to compete with aggregators. I'd rather link > to aggregators and have only the information we really need in the > repository. So for any field beyond what I've specified, I'm looking > for reasons why, specifically, it should be in a conary repository, as > opposed to a more general aggregator. Remember that Conary metadata > I'm currentl thinking being uniquely identified by a branch in a Conary > repository; that's very different from things like freshmeat projects. > > Now, URLs that link to various well-defined resource records for a > project (like OMF) might make sense to me. Is there a canonical > source for OMF records that already exist for a wide variety of > projects? OMF is very relaxed about the amount of information stored it the metadata records. You can use as many or as few of the elements as you like, except for the ones that are required (creator, title, & date). Identifier and source would also be useful. The identifier could be a conary-generated value linking to the appropriate trove. And the URL to a sourceforge or freshmeat xml record or project page could be stored in the source field. One problem might be if you wanted to expressly prevent people from putting too much information into conary metadata files. Any elements present in OMF would be valid. If you use automatic extraction, though, (you mentioned something like 'cvc describe ...'), it can just ignore what you don't want. I'm not aware of an OMF-based project repository, but the other project repositories are similar enough to be compatible. Using the OMF spec to validate conary metadata isn't necessary to do what you want. You could use another scheme or write your own. But OMF exists already and is general and flexible. The metadata community loves schemes that work for a variety of collections. Being close to dublin core, using the OMF as a base might make it easier for other groups to build a federated conary metadata repository? Thanks, -jrr From johnsonm@specifixinc.com Tue Sep 14 17:30:54 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i8ELUrm4015149 for ; Tue, 14 Sep 2004 17:30:54 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 19D1D16706 for ; Tue, 14 Sep 2004 14:31:02 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8ELV0GP026025 for ; Tue, 14 Sep 2004 17:31:00 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8ELV0le026023 for conary-list@lists.specifix.com; Tue, 14 Sep 2004 17:31:00 -0400 Date: Tue, 14 Sep 2004 17:31:00 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040914213100.GA23233@lambchop.rdu.specifixinc.com> References: <20040909183952.GA8569@lambchop.rdu.specifixinc.com> <20040910181200.GA13296@lambchop.rdu.specifixinc.com> <1095186455.541.156.camel@cardoel.metalab.unc.edu> <20040914184916.GA18298@lambchop.rdu.specifixinc.com> <1095189960.541.188.camel@cardoel.metalab.unc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095189960.541.188.camel@cardoel.metalab.unc.edu> User-Agent: Mutt/1.4.1i Subject: Re: metadata X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 21:30:54 -0000 On Tue, Sep 14, 2004 at 03:26:00PM -0400, John Reuning wrote: > One problem might be if you wanted to expressly prevent people from > putting too much information into conary metadata files. Exactly! Every element in our metadata will have to be stored as a stream with enumerated type in our repository. XML won't be the final format; if we use XML it will be to avoid writing our own syntax for a human-read/writeable file. We need to cook this information into the repository just like we cook a recipe; we just want to decouple it from the recipes because translation is a pain otherwise. I'm going for minimalistic because my whole goal for building Conary packages has been to lift burdens off packagers' shoulders by requiring only what is really necessary of them. It's worked very well for recipes. I want the same minimalistic approach to conary metadata. Minimalism has another benefit besides making it easy to get the necessary metadata collected: it makes it download faster! The more bits we have to shove over the wire, the longer it is going to take. When you are browsing a network repository, that makes a difference. Now, I think that references to richer data sources are a good idea. It might make sense to be able to apply sematic tags to URLs in our metadata that make it easier for some rich browsing tool to augment our data. References to freshmeat XML records, DOAP records, OMF records, whatever, can be resolved on the client side -- but there is really no reason to store the actual records in the repository. > Any elements > present in OMF would be valid. If you use automatic extraction, though, > (you mentioned something like 'cvc describe ...'), it can just ignore > what you don't want. That's just to prime a file that can then be edited and committed. I'd hope that it would normally be done via a URL, and the URL itself could very well be one of the URLs that is stored in the metadata record for the theoretical rich content browser to go look at. From john@metalab.unc.edu Tue Sep 14 18:37:56 2004 Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i8EMbum4021154 for ; Tue, 14 Sep 2004 18:37:56 -0400 Received: from [192.168.1.101] (rdu26-246-048.nc.rr.com [66.26.246.48]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i8EMc2Nr008032 for ; Tue, 14 Sep 2004 18:38:03 -0400 (EDT) From: John Reuning To: Conary Discussion In-Reply-To: <20040914213100.GA23233@lambchop.rdu.specifixinc.com> References: <20040909183952.GA8569@lambchop.rdu.specifixinc.com> <20040910181200.GA13296@lambchop.rdu.specifixinc.com> <1095186455.541.156.camel@cardoel.metalab.unc.edu> <20040914184916.GA18298@lambchop.rdu.specifixinc.com> <1095189960.541.188.camel@cardoel.metalab.unc.edu> <20040914213100.GA23233@lambchop.rdu.specifixinc.com> Content-Type: text/plain Message-Id: <1095201394.23267.66.camel@orcanie> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 14 Sep 2004 18:36:34 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: Re: metadata X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 22:37:56 -0000 Okay, gotcha. I had the notion that the metadata was to be stored in xml format somewhere. If the human-readable file is only used precook, it could be in any format. As you say, everyone knows and loves xml. ;) You could still use a known metadata scheme (doap, omf, etc.) to validate the xml doc during cooking and ignore metadata elements you don't want. An auto-generated xml file would contain only the desired set of tags. And the validation would be an extra sanity check performed by cvc. Thanks, -jrr On Tue, 2004-09-14 at 17:31, Michael K. Johnson wrote: > Every element in our metadata will have to be stored as a stream > with enumerated type in our repository. XML won't be the final > format; if we use XML it will be to avoid writing our own syntax > for a human-read/writeable file. We need to cook this information > into the repository just like we cook a recipe; we just want to > decouple it from the recipes because translation is a pain otherwise. > That's just to prime a file that can then be edited and committed. > I'd hope that it would normally be done via a URL, and the URL itself > could very well be one of the URLs that is stored in the metadata > record for the theoretical rich content browser to go look at. From msw@specifixinc.com Wed Sep 22 14:38:10 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i8MIcAVR012400 for ; Wed, 22 Sep 2004 14:38:10 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 94E0B16610 for ; Wed, 22 Sep 2004 11:38:27 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8MIcQGP024618 for ; Wed, 22 Sep 2004 14:38:26 -0400 Received: (from msw@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8MIcQ6d024616 for conary-list@lists.specifix.com; Wed, 22 Sep 2004 14:38:26 -0400 Date: Wed, 22 Sep 2004 14:38:26 -0400 From: Matt Wilson To: conary-list@lists.specifix.com Message-ID: <20040922183826.GC29638@specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: New releases of Conary are available X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2004 18:38:11 -0000 Since I didn't send a notice about the very exciting 0.10.0 release, I've included the NEWS entries for both 0.10.1 and 0.10.0. Note that if you're using a version of Conary older than 0.10.0, you'll need to convert your database. Changes in 0.10.1: * when applying a changeset, dependency failures are resolved by querying servers in the installLabelPath * troves that satisfy a dependency can automatically be added to a transaction. This behavior is controlled by the "autoResolve" variable in conaryrc or the "--resolve" command line option to "conary update" * dependency resolution is calculated recursively. To limit the recursion depth to check only first order dependencies, a "--no-deps-recurse" option has been added to "conary update" * "conary repquery" now takes a "--deps" argument, which prints the Requires and Provides information for the trove that is being queried. * changes have been made to the build side of Conary to facilitate building recipes that use cross compilers * symlinks now get the appropriate ownership set when they are restored * groups can now specify which flavor of a trove to include * repository queries that don't need file information no longer ask the repository for files. * various bug fixes and cleanups Changes in 0.10.0: * dependency checking is now performed before changesets are applied. This uses new tables in the local system's database. If you are using a database created by a version of Conary older than 0.10.0, it must be converted before it can be used. See: http://wiki.specifix.com/ConaryConversion for details * Shared library dependency information in changesets is now stored in a different format. This means that repositories that use old versions of Conary will be unable to give valid changesets to Conary 0.10.0 or later. Therefore, the protocol version number has been increased. * --no-deps argument added * "cvc co" is now a synonym for "cvc checkout" From johnsonm@specifixinc.com Mon Sep 27 19:01:27 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i8RN1QVR004217 for ; Mon, 27 Sep 2004 19:01:27 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 0AAA51623E for ; Mon, 27 Sep 2004 16:01:50 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8RN1mGP029542 for ; Mon, 27 Sep 2004 19:01:48 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8RN1llC029540 for conary-list@lists.specifix.com; Mon, 27 Sep 2004 19:01:47 -0400 Date: Mon, 27 Sep 2004 19:01:47 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifix.com Message-ID: <20040927230147.GA19267@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Flavor enhancements X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 23:01:27 -0000 Warning: the contents of this email may cause your eyes to glaze over. Keep reading anyway, as this email may affect you. :-) We have known for months that our encoding of flavors was not quite sufficient. Some flags express a preference, others an absolute requirement, and we had no way to represent this semantic distinction. When we started to delve into the potentially desirable semantics, we realized that they were rather complex. We classified the potentially desirable semantics for every single use flag, and then found a way to specify those semantics compactly. One important idea is that flag settings on a file/trove are fundamentally different from the same flags settings on the system. The settings on a trove are kind of like a statement of requirement ("Requires"), and the settings on the system are kind of like a statement of capability ("Provides"). They aren't quite the same as requires/provides, but they have the same assymetric nature. We have come up with a modifier to express "preference" for flavors. The "~" character, when prepended to a flag, expresses preference. So you can build a component that requires that a flag be enabled on the system, or a component that merely prefers that a flag be enabled on the system. The system can be set to prefer flavors with a flag enabled, or it can require that if that flag is mentioned for a package, it MUST be enabled. All these semantics are applied to selecting from a number of available flavors. Note that this is only done when it is not clear which flavor to install. This is generally only a consideration when no version of the trove is already installed. We should have flavor affinity just like we have version affinity -- once you have installed a trove from a certain branch, updates to that trove come from the same branch unless you explicitly request otherwise. The same will be true for flavors. I will describe first the semantics we defined, and second the syntax we created. A flag setting on a file/trove can have one of three choices: o Capability is required to be on the system o Capability is desired to be on the system o Capability is desired not to be on the system Note the conspicuous absence of "capability is required not to be on the system" -- we considered adding that, but ran into two difficulties. One was that we could not come up with a single example where it was a meaningful thing to say, and the other was that when combined with the system flag settings, it was difficult to actually describe what the setting would really mean. So for each flag, we need to define whether a value of "True" implies that the capability is required or desired; "False" never changes semantics here. This setting is part of the Conary build system. By contrast, a flag setting on a system can have one of four choices: o The capability is provided, and if the trove is built with respect to this capability (i.e. this flag is mentioned) it must be enabled in the trove. (e.g. Use.ssl) o The capability is not provided, and troves that are built with respect to this capability must not be installed if the capability is enabled in the trove. (e.g. Use.nptl, Flags.kernel.smp on uniprocessor systems that cannot boot an SMP kernel.) You might call this an "incompatible capability". o The capability is provided, and troves that use this flag are preferred, but both will work. (e.g. Use.gtk) o The capability is not provided, but troves that use this capability will still function, though perhaps not optimally, so they are not the best options given all possible choices. (e.g. Flags.kernel.smp on most uniprocessor systems) Note, from the Flags.kernel.smp example, that the choice between these options needs to be per-system. We can have a default for each, but it is important to be able to override the default for any system. To implement those semantics, we will enable the following syntax (I'll use F as the meta-variable for a flag): o For troves: - Flag required: F - Flag desired: ~F - Flag undesired: ~!F o For the system: - Capability available and Flag required to be enabled: F - Capability unavailable and Flag required to be disabled: !F - Capability available and Flag preferred to be enabled: ~F - Capability unavailable and Flag preferred to be disabled: ~!F The semantics have three purposes: to rank the available flavors to come up with a best match; to remove from consideration flavors that the system administrator simply never wants on the system; and to throw away any flavors that would not pass a dependency check, since dependency checking is much more expensive than flavor ranking. The idea is that for each flavor, conary will iterate over the flags mentioned in the flavor, and for each flag will do one of: + Promote the flavor (add to the flavor's current "score") - Demote the flavor (subtract from the flavor's current "score") D Disallow the flavor (immediately remove this flavor from consideration, without considering any more flags from this flavor) What to do in each case depends on the following matrix: TROVE S F ~F ~!F Y F + + D S !F D D + T ~F + + - E !~F - - + M N/S D - + "N/S" means "not specified" (We need to get this table up on the wiki in a more readable form, obviously.) System flag settings will be considered in this order: Flag settings from the command line override any flags settings in /etc/conary/flags, which override any flag setttings in /etc/conary/flags.d/ This means that we can provide reasonable defaults, where the defaults for different flags can reasonably be provided by different packages and repositories (this is important both for package-local flags like Flags.kernel.smp and for repositories that have flags that are not specified in the default Conary set), and where the flags can reasonably be overridden. Thanks for reading this far. This is my summary of what we decided; others here can chip in with corrections, or to expand on what I wrote or fill in missing pieces. From johnsonm@specifixinc.com Mon Sep 27 19:04:45 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i8RN4jVR004234 for ; Mon, 27 Sep 2004 19:04:45 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 3A2C61623E for ; Mon, 27 Sep 2004 16:05:08 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8RN56GP004985 for ; Mon, 27 Sep 2004 19:05:06 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8RN56h1004979 for conary-list@lists.specifix.com; Mon, 27 Sep 2004 19:05:06 -0400 Date: Mon, 27 Sep 2004 19:05:06 -0400 From: "Michael K. Johnson" To: conary-list@lists.specifix.com Message-ID: <20040927230505.GB19267@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Conary 0.10.2 available X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 23:04:45 -0000 Note that if you're using a version of Conary older than 0.10.0, you'll need to convert your database. For details, please see http://wiki.specifix.com/ConaryConversion Changes in 0.10.2: * the repository code is now included in the main conary source archive * "conary showchangeset" produces a more user-friendly output * large responses from the repository server are now compressed * the protocol for getFileContents() changed to take a fileId instead of the file's path. The repository code can still handle old requests, but the client code now requires the latest repository code. * bug fixes From johnsonm@specifixinc.com Mon Sep 27 19:07:27 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i8RN7QVR004297 for ; Mon, 27 Sep 2004 19:07:27 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 2A0AE1623E for ; Mon, 27 Sep 2004 16:07:50 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i8RN7mGP012771 for ; Mon, 27 Sep 2004 19:07:48 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i8RN7lCQ012768 for conary-list@lists.specifixinc.com; Mon, 27 Sep 2004 19:07:47 -0400 Date: Mon, 27 Sep 2004 19:07:46 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20040927230746.GC19267@lambchop.rdu.specifixinc.com> References: <20040909214525.GA3982@specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909214525.GA3982@specifixinc.com> User-Agent: Mutt/1.4.1i Cc: Subject: Re: distributed branching is broken in 0.9.4 X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 23:07:27 -0000 On Thu, Sep 09, 2004 at 05:45:25PM -0400, Matt Wilson wrote: > I needed to make a change to fix fetching the contents from a renamed > file, but this will break distributed branching. We'll get it fixed > soon. This is now fixed in 0.10.2, by a protocol change (getFileContents() taking fileId instead of path). From ewt@specifix.com Fri Oct 1 07:37:07 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i91Bb6VR024986 for ; Fri, 1 Oct 2004 07:37:07 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id F056F164DB for ; Fri, 1 Oct 2004 04:37:33 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i91BbWGP003840 for ; Fri, 1 Oct 2004 07:37:32 -0400 Received: from localhost (ewt@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) with ESMTP id i91BbW0v003836 for ; Fri, 1 Oct 2004 07:37:32 -0400 X-Authentication-Warning: lambchop.rdu.specifixinc.com: ewt owned process doing -bs Date: Fri, 1 Oct 2004 07:37:32 -0400 (EDT) From: ewt@specifix.com X-X-Sender: ewt@lambchop.rdu.specifixinc.com To: Conary Discussion In-Reply-To: <20040907204138.GA13643@lambchop.rdu.specifixinc.com> Message-ID: References: <20040907204138.GA13643@lambchop.rdu.specifixinc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 01 Oct 2004 09:14:24 -0400 Cc: Subject: Re: dependencies: IRC summary X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2004 11:37:07 -0000 (what? me? behind?) On Tue, 7 Sep 2004, Michael K. Johnson wrote: > In that context, we have had the idea for months that we'd be able > to use parameterized deps for version comparisons. We said something > like foo(>= 1.2.3-1-2). However, we don't really want to implement > version comparison algorithms -- the repository tree has gotten us > away from bad version comparison algorithms. Matt had the idea > that we could cook all version number references in dependencies > into the changeset into a full version reference, resolved against > the repository at build time; this would allow comparisons to be > meaningful in respect to the repository. It's not clear exactly > how that would be implemented. Matt's correct about this. If we turn short version checks (a > 1.1-1-1) into full version checks (a > /conary.specifix.com@a:b/1.1-2-1) which include timestamps, then we have a well-defined way of doing version comparisons, and performing this conversion at build time is straightforward. Erik From ken@biZrace.com Mon Oct 18 21:19:52 2004 Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i9J1JpVR030946 for ; Mon, 18 Oct 2004 21:19:52 -0400 Received: from [192.168.1.106] (cpe-024-163-091-077.nc.rr.com [24.163.91.77]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i9J1KYKj018033 for ; Mon, 18 Oct 2004 21:20:37 -0400 (EDT) Message-ID: <41746B75.4090302@biZrace.com> Date: Mon, 18 Oct 2004 21:18:45 -0400 From: Ken VanDine User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Conary Discussion Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: Suggestion for excluding components X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 01:19:52 -0000 I would like to see a flag that prevents :devel components from getting installed, unless it gets overrided. So, example is a desktop box that doesn't get any compilers. I would like to set a flag at install time that prevents all those :devel components from getting installed. And after install time, that flag will prevent those components from getting installed by default. Any thoughts? --Ken From ken@biZrace.com Mon Oct 18 22:45:20 2004 Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i9J2jJVR031035 for ; Mon, 18 Oct 2004 22:45:20 -0400 Received: from [192.168.1.106] (cpe-024-163-091-077.nc.rr.com [24.163.91.77]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i9J2k5Ch018919 for ; Mon, 18 Oct 2004 22:46:05 -0400 (EDT) Message-ID: <41747F7E.8040602@biZrace.com> Date: Mon, 18 Oct 2004 22:44:14 -0400 From: Ken VanDine User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Conary Discussion Content-Type: multipart/mixed; boundary="------------070100080707060205070405" X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: dependancy resolution issue X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 02:45:20 -0000 This is a multi-part message in MIME format. --------------070100080707060205070405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think I have found a bug. Here is what I am doing. Installing from my branched repo, to a specified --root with autoResolve True. It does display all the troves it needs to grab to solve the deps, but after chewing on it for a while is crashes. Here is the debug info. Thanks, --Ken --------------070100080707060205070405 Content-Type: text/plain; name="conary-stack-N6ttUT" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="conary-stack-N6ttUT" Exception: FileIdsConflictError Traceback (most recent call last): File "/usr/share/conary/conary", line 21, in ? sys.exit(conary.main()) File "/usr/share/conary/conary.py", line 447, in main realMain(cfg, argv) File "/usr/share/conary/conary.py", line 422, in realMain updatecmd.doUpdate(cfg, otherArgs[2:], **kwargs) File "/usr/share/conary/updatecmd.py", line 90, in doUpdate client.applyUpdate(cs, replaceFiles, tagScript, keepExisting) File "/usr/share/conary/conaryclient.py", line 250, in applyUpdate cs.merge(newCs) File "/usr/share/conary/repository/changeset.py", line 779, in merge self.fileQueueCmp) File "/usr/share/conary/lib/util.py", line 404, in tupleListBsearchInse= rt rc =3D cmpFn(haystack[start], newItem) File "/usr/share/conary/repository/changeset.py", line 595, in fileQueu= eCmp raise FileIdsConflictError FileIdsConflictError >> /usr/share/conary/conary:21: __main__.?() >> /usr/share/conary/conary.py:470: conary.main(argv) Params:=20 argv =3D ['/usr/share/conary/conary', 'update', 'gnome-desktop', '--r= eplace-files', '--root=3D/export/GNOMECD2'] Locals:=20 cfg =3D >> /usr/share/conary/conary.py:422: conary.realMain(cfg, argv) Params:=20 cfg =3D argv =3D ['/usr/share/conary/conary', 'update', 'gnome-desktop', '--r= eplace-files', '--root=3D/export/GNOMECD2'] Locals:=20 MULT_PARAM =3D 3 NO_PARAM =3D 0 ONE_PARAM =3D 1 OPT_PARAM =3D 2 argDef =3D {'all': 0, 'sha1s': 0, 'install-label': 3, 'no-resolve': 0= , 'keep-existing': 0, 'replace-files': 0, 'version': 0, 'ls': 0, 'tag-scr= ipt': 1, 'config': 3, 'profile': 0, 'tags': 0, 'target-branch': 1, 'path'= : 3, 'full-versions': 0, 'no-deps': 0, 'info': 0, 'resolve': 0, 'leaves':= 0, 'ids': 0, 'config-file': 1, 'no-deps-recurse': 0, 'show-changes': 0, = 'deps': 0, 'debug': 0, 'root': 1, 'build-label': 1} argSet =3D {} cfgMap =3D {'root': 'root', 'build-label': 'buildLabel'} keepExisting =3D False kwargs =3D {'replaceFiles': True} l =3D [] otherArgs =3D ['/usr/share/conary/conary', 'update', 'gnome-desktop']= profile =3D False >> /usr/share/conary/updatecmd.py:94: updatecmd.doUpdate(cfg, pkgList, re= placeFiles, tagScript, keepExisting, depCheck, recurse) Params:=20 cfg =3D pkgList =3D ['gnome-desktop'] replaceFiles =3D True tagScript =3D None keepExisting =3D False depCheck =3D True recurse =3D True Locals:=20 applyList =3D ['gnome-desktop'] brokenByErase =3D [] client =3D cs =3D depFailures =3D [] items =3D ['GConf:lib', 'ORBit2:lib', 'atk:lib', 'audiofile:lib', 'es= ound:lib', 'expat:lib', 'fontconfig:lib', 'gnome-keyring:lib', 'gnome-vfs= :lib', 'gtk:lib', 'krb5:lib', 'libIDL:lib', 'libart_lgpl:lib', 'libbonobo= :lib', 'libbonoboui:lib', 'libgnome:lib', 'libgnomecanvas:lib', 'libgnome= ui:lib', 'libtiff:lib', 'libxml2:lib', 'openssl:lib', 'pango:lib', 'popt:= lib', 'startup-notification:lib', 'xorg-x11-Mesa-libGL:lib', 'xorg-x11:li= b'] pkgStr =3D gnome-desktop suggList =3D [['xorg-x11:lib', '/conary.specifix.com@spx:linux/6.8.0-= 5-1'], ['gtk:lib', '/conary.specifix.com@spx:linux/2.4.10-1-1'], ['libgno= meui:lib', '/conary.specifix.com@spx:linux/2.8.0-1-1'], ['libbonoboui:lib= ', '/conary.specifix.com@spx:linux/2.8.0-1-1'], ['libgnome:lib', '/conary= =2Especifix.com@spx:linux/2.8.0-1-1'], ['gnome-vfs:lib', '/conary.specifi= x.com@spx:linux/2.8.0-1-1'], ['libbonobo:lib', '/conary.specifix.com@spx:= linux/2.8.0-1-1'], ['GConf:lib', '/conary.specifix.com@spx:linux/2.8.0.1-= 1-1'], ['libxml2:lib', '/conary.specifix.com@spx:linux/2.6.13-1-1'], ['pa= ngo:lib', '/conary.specifix.com@spx:linux/1.6.0-1-1'], ['ORBit2:lib', '/c= onary.specifix.com@spx:linux/2.12.0-1-1'], ['atk:lib', '/conary.specifix.= com@spx:linux/1.8.0-1-1'], ['popt:lib', '/conary.specifix.com@spx:linux/1= =2E8.1-3-1'], ['startup-notification:lib', '/conary.specifix.com@spx:linu= x/0.7-1-1'], ['libgnomecanvas:lib', '/conary.specifix.com@spx:linux/2.6.1= =2E1-3-1'], ['libart_lgpl:lib', '/conary.specifix.com@spx:linux/2.3.16-3-= 1']] suggMap =3D {'gtk:lib': [['libIDL:lib', '/conary.specifix.com@spx:lin= ux/0.8.4-1-1']], 'libgnome:lib': [['fontconfig:lib', '/conary.specifix.co= m@spx:linux/2.2.95-7-1']], 'gnome-desktop:lib': [['xorg-x11:lib', '/conar= y.specifix.com@spx:linux/6.8.0-5-1'], ['gtk:lib', '/conary.specifix.com@s= px:linux/2.4.10-1-1'], ['libgnomeui:lib', '/conary.specifix.com@spx:linux= /2.8.0-1-1'], ['libbonoboui:lib', '/conary.specifix.com@spx:linux/2.8.0-1= -1'], ['libgnome:lib', '/conary.specifix.com@spx:linux/2.8.0-1-1'], ['gno= me-vfs:lib', '/conary.specifix.com@spx:linux/2.8.0-1-1'], ['libbonobo:lib= ', '/conary.specifix.com@spx:linux/2.8.0-1-1'], ['GConf:lib', '/conary.sp= ecifix.com@spx:linux/2.8.0.1-1-1'], ['libxml2:lib', '/conary.specifix.com= @spx:linux/2.6.13-1-1'], ['pango:lib', '/conary.specifix.com@spx:linux/1.= 6.0-1-1'], ['ORBit2:lib', '/conary.specifix.com@spx:linux/2.12.0-1-1'], [= 'atk:lib', '/conary.specifix.com@spx:linux/1.8.0-1-1'], ['popt:lib', '/co= nary.specifix.com@spx:linux/1.8.1-3-1'], ['libgnomecanvas:lib', '/conary.= specifix.com@spx:linux/2.6.1.1-3-1'], ['libart_lgpl:lib', '/conary.specif= ix.com@spx:linux/2.3.16-3-1']], 'libgnomeui:lib': [['gnome-keyring:lib', = '/conary.specifix.com@spx:linux/0.4.0-1-1']], 'pango:lib': [['esound:lib'= , '/conary.specifix.com@spx:linux/0.2.35-1-1'], ['audiofile:lib', '/conar= y.specifix.com@spx:linux/0.2.6-2-1']], 'gnome-vfs:lib': [['xorg-x11-Mesa-= libGL:lib', '/conary.specifix.com@spx:linux/6.8.0-5-1'], ['fontconfig:lib= ', '/conary.specifix.com@spx:linux/2.2.95-7-1'], ['expat:lib', '/conary.s= pecifix.com@spx:linux/1.95.7-3-1']], 'ORBit2:lib': [['fontconfig:lib', '/= conary.specifix.com@spx:linux/2.2.95-7-1'], ['libtiff:lib', '/conary.spec= ifix.com@spx:linux/3.5.7-2-1']], 'xorg-x11:lib': [['krb5:lib', '/conary.s= pecifix.com@spx:linux/1.2.7-10-1'], ['openssl:lib', '/conary.specifix.com= @spx:linux/0.9.7a-2-1']], 'gnome-desktop:runtime': [['xorg-x11:lib', '/co= nary.specifix.com@spx:linux/6.8.0-5-1'], ['gtk:lib', '/conary.specifix.co= m@spx:linux/2.4.10-1-1'], ['libgnomeui:lib', '/conary.specifix.com@spx:li= nux/2.8.0-1-1'], ['libbonoboui:lib', '/conary.specifix.com@spx:linux/2.8.= 0-1-1'], ['libgnome:lib', '/conary.specifix.com@spx:linux/2.8.0-1-1'], ['= gnome-vfs:lib', '/conary.specifix.com@spx:linux/2.8.0-1-1'], ['libbonobo:= lib', '/conary.specifix.com@spx:linux/2.8.0-1-1'], ['GConf:lib', '/conary= =2Especifix.com@spx:linux/2.8.0.1-1-1'], ['libxml2:lib', '/conary.specifi= x.com@spx:linux/2.6.13-1-1'], ['pango:lib', '/conary.specifix.com@spx:lin= ux/1.6.0-1-1'], ['ORBit2:lib', '/conary.specifix.com@spx:linux/2.12.0-1-1= '], ['atk:lib', '/conary.specifix.com@spx:linux/1.8.0-1-1'], ['popt:lib',= '/conary.specifix.com@spx:linux/1.8.1-3-1'], ['startup-notification:lib'= , '/conary.specifix.com@spx:linux/0.7-1-1'], ['libgnomecanvas:lib', '/con= ary.specifix.com@spx:linux/2.6.1.1-3-1'], ['libart_lgpl:lib', '/conary.sp= ecifix.com@spx:linux/2.3.16-3-1']]} x =3D ['libart_lgpl:lib', '/conary.specifix.com@spx:linux/2.3.16-3-1'= ] >> /usr/share/conary/conaryclient.py:250: conaryclient.applyUpdate(self, = theCs, replaceFiles, tagScript, keepExisting) Params:=20 self =3D theCs =3D replaceFiles =3D True tagScript =3D None keepExisting =3D False Locals:=20 cs =3D how =3D > newCs =3D what =3D [('startup-notification:lib', (None, None), (, ), 0), ('xorg-x11-Mesa-libGL:lib', (None, None), (, ), 0), ('popt:lib', (None, None), (, ), 0), ('libgnome:lib', (None, None), (, ),= 0), ('libart_lgpl:lib', (None, None), (, ), 0),= ('openssl:lib', (None, None), (, ), 0), ('krb5:= lib', (None, None), (, = ), 0), ('libgnomeui:lib',= (None, None), (, ), 0), ('audiofile:lib', (No= ne, None), (, ), 0), ('libtiff:lib', (None, None= ), (, ), 0), ('esound:lib', (None, None), (, ), 0), ('expat:lib', (None, None), (, ), 0), ('xorg-x11:lib', (None, None), (, ), 0), ('libbonoboui:lib', (None, None), (, ), 0), ('GConf:lib', (None, None), (, ), 0), ('= fontconfig:lib', (None, None), (, ), 0), ('gtk:l= ib', (None, None), (, <= deps.deps.DependencySet instance at 0x408b488c>), 0), ('libgnomecanvas:li= b', (None, None), (, ), 0), ('pango:lib', (None,= None), (, ), 0), ('libxml2:lib', (None, None), = (, ), 0), ('atk:lib', (None, None), (, ), 0), ('ORBit2:lib', (None, None), (, ), 0), ('libbonobo:lib', (None, None), (, ), 0), ('gnome-keyring:lib', (None, None), (, )= , 0), ('libIDL:lib', (None, None), (, ), 0), ('g= nome-vfs:lib', (None, None), (, ), 0)] >> /usr/share/conary/repository/changeset.py:779: repository.changeset.me= rge(self, otherCs) Params:=20 self =3D otherCs =3D Locals:=20 entry =3D ('\x05&\xdcJZ\xd1^\xa2m\t\x10\xba\x0bGzJ4\x12|\x02', '0 fil= e', , 18625L, ) >> /usr/share/conary/lib/util.py:404: lib.util.tupleListBsearchInsert(hay= stack, newItem, cmpFn) Params:=20 haystack =3D [('\xb6\x0e\xa3\xb7\x17\xc5\xeae\xeda\x08\xf3M8V\xab\xe2= Nm\xa8', '1 file', , 640L, ), ('\x04+\t= Y\xe7R0\xe71\x95\xe0\xab\x96\r\xa7\x02Y\xb4u\x91', '0 file', , 7663L, ), ('\x05&\xdcJZ\xd1^\xa2m\t\x10\xba\x0bGz= J4\x12|\x02', '0 file', , 186= 25L, ), ('= \tIz\xb0\xc1\xc5C\x1d\x19\xc4\xe1\xa4B\xfd\x07\x81r\xa7Z\xb4', '0 file', = , 35683L, ), ('\x0f\x02(\x01\xd5^ \x905= \xf1\x0f\xe2\r\xa9\xdc\xf8\x9d4_L', '0 file', , 91618L, ), ('\x0f\xc4\x9cg\xb8\xf8\xb5z\xd9]\x8aDD\xe3\x8c\xe1\x= c0\xa9=3D\x02', '0 file', , 4= 59968L, ),= ('+\xc5d\x94\xa5]\xe8V"\xd1\x17\x99\xdc]S\xa7\xe4\x9e\xb0\xa4', '0 file'= , , 201702L, ), ('0\xd7C\xce\x06Q\xfb\x= 95\xd4\xda%\x7f\x8f1b\x9a\xe1\xc2~y', '0 file', , 238865L, ), ('E+\x162\x9f4\xc4\xf1l\xecB\xcf\xe5\x88\xa2c$#SQ'= , '0 file', , 25152L, ), ('J\x0c\xa01X,= f\xc0\xd6\x06%\x05k\xb6\xd53\xcf\xf3\xbe6', '0 file', , 35040L, ), ('K\xb9\xc0\x00\xe6PxB\xbdx\xc3\x1e\xb6\x1enj= \x03\xed\x7fr', '0 file', , 4= 36189L, ),= ('T\x90g\xf6y\x02U\x06J\xaa\x99\xb0~\xda\xa2Ab\xeb\xc7,', '0 file', , 445019L, ), ('`\x8f\xdb\xf14\xc0\xaf\x0= 5B\x0b\xb5\x9e\x0e\xdep+\xce\xe9\xd5$', '0 file', , 29638L, ), ('b\xb0\xfdY\xaaY+4A\xa6\xec\xd55\x81\xe6\xdd\xd7= \x80&\x11', '0 file', , 63432= 7L, ), ('w= \xa9N\xd7lt\x1e\xc9\xe2\xd9g\xc9\xa8\x1d!\xfa\xf8\x84\x7f\x12', '0 file',= , 115714L, ), ('{:>\xa3\xa9\xb2 \xbd1\= xda/h{\xb2\x84~{\xf1\xa9\xa6', '0 file', , 171184L, ), ('\x97g\xbc\xc3-v\xa9\x9fFD\x8a0m\xf9\xb0\xb1\xf5\xd4\x04= \x1d', '0 file', , 91608L, ), ('\xc4\xd= c\x9b\xcfe\xf17\x1c2\xb9\xc4\xb4\xd8\xc0\xd2\x98\xbd\xef\x87\xfc', '0 fil= e', , 1129382L, )] newItem =3D ('\x05&\xdcJZ\xd1^\xa2m\t\x10\xba\x0bGzJ4\x12|\x02', '0 f= ile', , 18625L, ) cmpFn =3D Locals:=20 finish =3D 2 i =3D 1 rc =3D -1 start =3D 2 >> /usr/share/conary/repository/changeset.py:595: repository.changeset.fi= leQueueCmp(a, b) Params:=20 a =3D ('\x05&\xdcJZ\xd1^\xa2m\t\x10\xba\x0bGzJ4\x12|\x02', '0 file', = , 18625L, ) b =3D ('\x05&\xdcJZ\xd1^\xa2m\t\x10\xba\x0bGzJ4\x12|\x02', '0 file', = , 18625L, ) --------------070100080707060205070405-- From johnsonm@specifixinc.com Tue Oct 19 08:47:46 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i9JCljVR002337 for ; Tue, 19 Oct 2004 08:47:46 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 5733C16228 for ; Tue, 19 Oct 2004 05:48:33 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i9JCmVGP025360 for ; Tue, 19 Oct 2004 08:48:31 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i9JCmTFg025358 for conary-list@lists.specifix.com; Tue, 19 Oct 2004 08:48:29 -0400 Date: Tue, 19 Oct 2004 08:48:29 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20041019124829.GA25282@lambchop.rdu.specifixinc.com> References: <41746B75.4090302@biZrace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41746B75.4090302@biZrace.com> User-Agent: Mutt/1.4.1i Subject: Re: Suggestion for excluding components X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 12:47:46 -0000 On Mon, Oct 18, 2004 at 09:18:45PM -0400, Ken VanDine wrote: > I would like to see a flag that prevents :devel components from getting > installed, unless it gets overrided. So, example is a desktop box that > doesn't get any compilers. I would like to set a flag at install time > that prevents all those :devel components from getting installed. And > after install time, that flag will prevent those components from getting > installed by default. > > Any thoughts? One of the main points of components is that instead of having haphazard names for subpackages (as in old-style packaging systems), the names are consistent for such packages, and being able to exclude arbitrarily-named subpackages programatically is part of the design intention. So you're just racing ahead of planned functionality. :-) We expected this implementation to trail individual package selection in anaconda, which is also not implemented yet. So yes, we plan to do this, but generically, not just for :devel, but for whatever names you want. :doc comes to mind, for example. From ewt@specifix.com Tue Oct 19 11:11:12 2004 Received: from bradley.rdu.specifix.com (rdu-nat.specifix.com [24.172.59.42]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i9JFBBVR002534 for ; Tue, 19 Oct 2004 11:11:12 -0400 Received: from bradley.rdu.specifix.com (localhost [127.0.0.1]) by bradley.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id i9JFAR37005350 for ; Tue, 19 Oct 2004 11:10:27 -0400 Received: from localhost (ewt@localhost) by bradley.rdu.specifix.com (8.12.10/8.12.10/Submit) with ESMTP id i9JFARjC005347 for ; Tue, 19 Oct 2004 11:10:27 -0400 X-Authentication-Warning: bradley.rdu.specifix.com: ewt owned process doing -bs Date: Tue, 19 Oct 2004 11:10:27 -0400 (EDT) From: Erik Troan X-X-Sender: ewt@bradley.rdu.specifix.com To: Conary Discussion In-Reply-To: <41746B75.4090302@biZrace.com> Message-ID: References: <41746B75.4090302@biZrace.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: Suggestion for excluding components X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 15:11:12 -0000 On Mon, 18 Oct 2004, Ken VanDine wrote: > I would like to see a flag that prevents :devel components from getting > installed, unless it gets overrided. So, example is a desktop box that > doesn't get any compilers. I would like to set a flag at install time that > prevents all those :devel components from getting installed. And after > install time, that flag will prevent those components from getting installed > by default. > > Any thoughts? You'll get this, but there is work to be done first... Right now the handling of packages and groups (as opposed to components and filesets) leaves a lot to be desired, and I'm not all that excited about adding this until I fix those things. Erik From tgerla@specifixinc.com Tue Oct 26 15:45:54 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i9QJjrVR013363 for ; Tue, 26 Oct 2004 15:45:54 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 981541649C for ; Tue, 26 Oct 2004 12:46:47 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i9QJkkj5002334 for ; Tue, 26 Oct 2004 15:46:46 -0400 Received: (from tgerla@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i9QJkkIh002332 for conary-list@lists.specifixinc.com; Tue, 26 Oct 2004 15:46:46 -0400 Date: Tue, 26 Oct 2004 15:46:46 -0400 From: Tim Gerla To: conary-list@lists.specifixinc.com Message-ID: <20041026194645.GA26148@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Cc: Subject: Command-line metadata interface X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 19:45:54 -0000 I've been working on the command-line interface to the trove metadata, and here's what I've come up with as far as a set of options. I figure people will either want to retrieve data from an external source, like Freshmeat, or set it by hand on the command line or from a script. So, I've come up with the following set of commands for 'cvc describe': --source --source-name -- to use a different project name for freshmeat, etc. freshmeat-only right now, and I suppose for things like DOAP, etc, we'd need a --source-file to load a specific XML file. maybe this could be generalized? --short-desc --long-desc --url + --category + --license + --no-save -- to prevent writing to the repository--to do a dry-run, maybe even print out the entire set of parsed data from freshmeat to verify its accuracy? So, a simple metadata population command would look like this: cvc describe --source=freshmeat a2ps To override the short description: cvc describe --source=freshmeat --short-desc "my description" a2ps Suggestions before I implement all of this would be appreciated. Thanks, -Tim From johnsonm@specifixinc.com Tue Oct 26 22:31:47 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i9R2VkVR013750 for ; Tue, 26 Oct 2004 22:31:47 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id E387C167D3 for ; Tue, 26 Oct 2004 19:32:42 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i9R2Wfj5010464 for ; Tue, 26 Oct 2004 22:32:41 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i9R2WegX010462 for conary-list@lists.specifix.com; Tue, 26 Oct 2004 22:32:40 -0400 Date: Tue, 26 Oct 2004 22:32:40 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20041027023240.GA10410@lambchop.rdu.specifixinc.com> References: <20041026194645.GA26148@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041026194645.GA26148@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: Command-line metadata interface X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 02:31:47 -0000 Might make more sense to have a tool that builds an XML file, and have 'cvc describe' just pull in the contents of the XML file? On Tue, Oct 26, 2004 at 03:46:46PM -0400, Tim Gerla wrote: > I've been working on the command-line interface to the trove metadata, > and here's what I've come up with as far as a set of options. I figure > people will either want to retrieve data from an external source, like > Freshmeat, or set it by hand on the command line or from a script. > > So, I've come up with the following set of commands for 'cvc describe': > > --source > --source-name -- to use a different project name for freshmeat, etc. > freshmeat-only right now, and I suppose for things > like DOAP, etc, we'd need a --source-file to load > a specific XML file. maybe this could be generalized? > --short-desc > --long-desc > --url + > --category + > --license + > --no-save -- to prevent writing to the repository--to do a dry-run, > maybe even print out the entire set of parsed data from > freshmeat to verify its accuracy? > > So, a simple metadata population command would look like this: > > cvc describe --source=freshmeat a2ps > > To override the short description: > > cvc describe --source=freshmeat --short-desc "my description" a2ps > > Suggestions before I implement all of this would be appreciated. From tgerla@specifixinc.com Thu Oct 28 12:11:32 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i9SGBVVR017099 for ; Thu, 28 Oct 2004 12:11:32 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 45931167D8 for ; Thu, 28 Oct 2004 09:12:28 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i9SGCQj5022951 for ; Thu, 28 Oct 2004 12:12:26 -0400 Received: (from tgerla@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i9SGCQOD022949 for conary-list@lists.specifix.com; Thu, 28 Oct 2004 12:12:26 -0400 Date: Thu, 28 Oct 2004 12:12:26 -0400 From: Tim Gerla To: Conary Discussion Message-ID: <20041028161226.GA18458@lambchop.rdu.specifixinc.com> References: <20041026194645.GA26148@lambchop.rdu.specifixinc.com> <20041027023240.GA10410@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041027023240.GA10410@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: Command-line metadata interface X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 16:11:32 -0000 On Tue, Oct 26, 2004 at 10:32:40PM -0400, Michael K. Johnson wrote: > Might make more sense to have a tool that builds an XML file, and > have 'cvc describe' just pull in the contents of the XML file? > This might make more sense. We'll have to define a format or use a subset of an existing format; I think we talked about OMF? I assume there's a subset of that we could use. This would solve the problem that made me want to add a --no-save option. I think it's a good idea to make it as easy as possible for a human to scan the automatically-retrieved data before applying it to the repo. -Tim From johnsonm@specifixinc.com Thu Oct 28 12:49:21 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id i9SGnLVR017135 for ; Thu, 28 Oct 2004 12:49:21 -0400 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 99324167D8 for ; Thu, 28 Oct 2004 09:50:19 -0700 (PDT) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id i9SGoHj5023808 for ; Thu, 28 Oct 2004 12:50:18 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id i9SGoFoj023806 for conary-list@lists.specifix.com; Thu, 28 Oct 2004 12:50:15 -0400 Date: Thu, 28 Oct 2004 12:50:15 -0400 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20041028165015.GA23780@lambchop.rdu.specifixinc.com> References: <20041026194645.GA26148@lambchop.rdu.specifixinc.com> <20041027023240.GA10410@lambchop.rdu.specifixinc.com> <20041028161226.GA18458@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041028161226.GA18458@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: Command-line metadata interface X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 16:49:22 -0000 On Thu, Oct 28, 2004 at 12:12:26PM -0400, Tim Gerla wrote: > This might make more sense. We'll have to define a format or use a subset > of an existing format; I think we talked about OMF? I assume there's a > subset of that we could use. Doesn't matter very much. I'd hesitate to use another DTD just becuase people would validate against that DTD and then wonder why their (extraneous) data items disappeared. From ken@bizrace.com Tue Nov 2 09:33:58 2004 Received: from mail.bizrace.com (eth0.bizrace.com [66.45.101.41] (may be forged)) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id iA2EXvUJ012879 for ; Tue, 2 Nov 2004 09:33:58 -0500 Received: by mail.bizrace.com (Postfix, from userid 48) id 1F16B5F61D; Tue, 2 Nov 2004 09:34:25 -0500 (EST) Received: from psphinxa.xh1.lilly.com ( [psphinxa.xh1.lilly.com]) as user ken.bizrace.com@web1.bizrace.com by webmail.bizrace.com with HTTP; Tue, 2 Nov 2004 09:34:24 -0500 Message-ID: <1099406064.41879af0a7289@webmail.bizrace.com> Date: Tue, 2 Nov 2004 09:34:24 -0500 From: Ken VanDine To: conary-list@lists.specifix.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 40.254.24.8 Subject: transient files X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 14:33:58 -0000 Looking for some opinions here. When conary creates a ".conflict" file, that file needs to be there to see what needs to be done. But, what if the package is erased? Shouldn't that file belong to the package that created it so it gets cleaned up? Erik pointed out that if it added the file to a trove on the local side, it would then start showing up in local changesets. I agree that is bad. But, I also think it should get cleaned up somehow. Opinions? Comments? Flames? Suggestions? --Ken From johnsonm@specifixinc.com Tue Nov 2 09:46:18 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id iA2EkHUJ012900 for ; Tue, 2 Nov 2004 09:46:18 -0500 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 532E1167DC for ; Tue, 2 Nov 2004 06:46:45 -0800 (PST) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id iA2Ekhj5019377 for ; Tue, 2 Nov 2004 09:46:43 -0500 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id iA2EkhQt019375 for conary-list@lists.specifix.com; Tue, 2 Nov 2004 09:46:43 -0500 Date: Tue, 2 Nov 2004 09:46:43 -0500 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20041102144643.GA19298@lambchop.rdu.specifixinc.com> References: <1099406064.41879af0a7289@webmail.bizrace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1099406064.41879af0a7289@webmail.bizrace.com> User-Agent: Mutt/1.4.1i Subject: Re: transient files X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 14:46:18 -0000 On Tue, Nov 02, 2004 at 09:34:24AM -0500, Ken VanDine wrote: > Looking for some opinions here. When conary creates a ".conflict" file, that > file needs to be there to see what needs to be done. But, what if the package > is erased? Shouldn't that file belong to the package that created it so it gets > cleaned up? Naw. In fact, we've been suggesting that modified configuration files should not be removed with their packages, either, and that configurations files should not be replaced if they already exist on the system when a changeset adds a configuration file. (BTW, "transient file" also has a jargon meaning in Conary: it's a type of file that has transient contents; contents that are always replaced by the new contents in the changeset even if the file has changed on disk, without comment from Conary. Right now, our example is .pyc and .pyo files.) From johnsonm@specifixinc.com Mon Nov 22 11:39:14 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id iAMGdDUJ012947 for ; Mon, 22 Nov 2004 11:39:14 -0500 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 3A90F162A2 for ; Mon, 22 Nov 2004 08:39:13 -0800 (PST) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id iAMGdCj5005694 for ; Mon, 22 Nov 2004 11:39:12 -0500 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id iAMGdBuu005692 for conary-list@lists.specifix.com; Mon, 22 Nov 2004 11:39:11 -0500 Date: Mon, 22 Nov 2004 11:39:11 -0500 From: "Michael K. Johnson" To: conary-list@lists.specifix.com Message-ID: <20041122163911.GA5370@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: runtime-only user definition X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 16:39:14 -0000 Sometimes, including daemons being run without priviledges, the point of having a separate user/group for the daemon is that it gives NO priviledges for filesystem I/O. However, Conary deals with all information relative to files, as part of having working changesets. This means that all information in the changeset is tied to a file. This means that even if I define a user/ group, unless that user/group is referenced by a file, there is no place to put it. (Ignore the fact that the user/group specifications are not yet stored at all, that's just an implementation issue...) Two possible ways of handling this: o When r.User() or r.Group() has been called, and there are insufficent file references to store the information, then r.User()/r.Group could create something like /var/lib/conary/users/%(name)s-%(version)s/ where /var/lib/conary/users is mode 700 and the file is owned by the user and/or group specified. The mode 700 directory should prevent the daemon from getting at the file, thus getting around the exess privildge issue. o A stream of supplemental information could be attached to the binary or configuration file that references the user/group names. We'd want to be able to have multiple entries of course, and they would need to be sorted reliably. We'd have to do something like r.UtilizeUser('username', ) and r.UtilizeGroup('username', ) to attach those streams of supplemental information. (Thanks to Matt for coming up with this second suggestion.) Thoughts? From ewt@specifix.com Sun Nov 28 21:01:37 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id iAT21aUJ007454 for ; Sun, 28 Nov 2004 21:01:37 -0500 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 16EDF162C5 for ; Sun, 28 Nov 2004 18:01:33 -0800 (PST) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id iAT21Vj5015987 for ; Sun, 28 Nov 2004 21:01:31 -0500 Received: from localhost (ewt@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) with ESMTP id iAT21VFa015983 for ; Sun, 28 Nov 2004 21:01:31 -0500 X-Authentication-Warning: lambchop.rdu.specifixinc.com: ewt owned process doing -bs Date: Sun, 28 Nov 2004 21:01:30 -0500 (EST) From: ewt@specifix.com X-X-Sender: ewt@lambchop.rdu.specifixinc.com To: Conary Discussion In-Reply-To: <20041122163911.GA5370@lambchop.rdu.specifixinc.com> Message-ID: References: <20041122163911.GA5370@lambchop.rdu.specifixinc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: runtime-only user definition X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 02:01:37 -0000 On Mon, 22 Nov 2004, Michael K. Johnson wrote: > o A stream of supplemental information could be attached to the > binary or configuration file that references the user/group names. > We'd want to be able to have multiple entries of course, and they > would need to be sorted reliably. We'd have to do something like > r.UtilizeUser('username', ) > and > r.UtilizeGroup('username', ) > to attach those streams of supplemental information. > (Thanks to Matt for coming up with this second suggestion.) > > Thoughts? Easy choice -- this one is much better. Erik From johnsonm@specifixinc.com Tue Dec 7 14:44:29 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id iB7JiSQv021273 for ; Tue, 7 Dec 2004 14:44:29 -0500 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 7C351163AA for ; Tue, 7 Dec 2004 11:44:24 -0800 (PST) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id iB7JiNnE003376 for ; Tue, 7 Dec 2004 14:44:23 -0500 Received: (from johnsonm@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id iB7JiM86003374 for conary-list@lists.specifix.com; Tue, 7 Dec 2004 14:44:22 -0500 Date: Tue, 7 Dec 2004 14:44:22 -0500 From: "Michael K. Johnson" To: conary-list@lists.specifix.com Message-ID: <20041207194422.GA3225@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: versions and paths between recipes X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 19:44:29 -0000 For some time, we've been wondering how best to deal with things like the python site-packages path. There are several packages that put files in a per-version site-packages directory (/usr/lib{,64}/python/site-packages -- but the best way to figure out within a recipe other than python.recipe what was the system python version eluded us. Not any more. At the top of your recipe file, run loadRecipe('python.recipe') just as if you were going to subclass python. But then, you can access some variables. For example: r.macros.pythonversion = Python.version r.macros.pythonmajorversion = Python.majversion r.macros.pythonsitepkgs = Python.sitepkgs (You can give the macros shorter names, of course; anything that doesn't conflict for that package.) The nice thing about using loadRecipe that way is that it will always pull the latest python recipe off the current label. So if you branch your recipe into a branch that also contains a modified python with a different version, you'll automatically start picking up the new pythong version to match the branch. We'll use this in more cases, I'm sure. From msw@specifixinc.com Tue Dec 7 16:21:11 2004 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id iB7LLAQv021975 for ; Tue, 7 Dec 2004 16:21:10 -0500 Received: from lambchop.rdu.specifixinc.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id CC6A5162C5 for ; Tue, 7 Dec 2004 13:21:06 -0800 (PST) Received: from lambchop.rdu.specifixinc.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10) with ESMTP id iB7LL5nE009851 for ; Tue, 7 Dec 2004 16:21:05 -0500 Received: (from msw@localhost) by lambchop.rdu.specifixinc.com (8.12.10/8.12.10/Submit) id iB7LL5eV009849 for conary-list@lists.specifix.com; Tue, 7 Dec 2004 16:21:05 -0500 Date: Tue, 7 Dec 2004 16:21:05 -0500 From: Matt Wilson To: Conary Discussion Message-ID: <20041207212105.GA23324@specifix.com> References: <20041122163911.GA5370@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: runtime-only user definition X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 21:21:11 -0000 On Sun, Nov 28, 2004 at 09:01:30PM -0500, ewt@specifix.com wrote: > > r.UtilizeUser('username', ) > > and > > r.UtilizeGroup('username', ) > > Easy choice -- this one is much better. Indeed. If you attached it to a random file in /var/lib, it could be excluded in a fileset. The executable file has the real requirement on the user/group existing, so it should carry the information that creates it. Cheers, Matt From dbc@lambchop.rdu.specifix.com Thu Jan 6 10:43:56 2005 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j06FhtQv012545 for ; Thu, 6 Jan 2005 10:43:55 -0500 Received: from lambchop.rdu.specifix.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id EF8DB16A15 for ; Thu, 6 Jan 2005 07:43:38 -0800 (PST) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j06Fhbfb010189 for ; Thu, 6 Jan 2005 10:43:37 -0500 Received: (from dbc@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j06Fhbwo010181 for conary-list@lists.specifix.com; Thu, 6 Jan 2005 10:43:37 -0500 Date: Thu, 6 Jan 2005 10:43:37 -0500 From: "David B. Christian" To: conary-list@lists.specifix.com Message-ID: <20050106154337.GC18122@lambchop.rdu.specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Overlapping instruction sets X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 15:43:56 -0000 oot and msw and I were talking about subarch flags, esp. flags like i586 and i686. An i686 machine should provide the flags x86(i586 i686) (probably others, like cmov, etc, but ignoring those...) Now, suppose a trove foo is built with two flavors, one with i586 and i686. When trying to decide which version of foo to install, the i586 and i686 versions will score the same when trying to install on a platform that provides x86(i586 i686)! oot suggested that troves that require x86(i686) be fleshed out to require x86(i586 i686). That way, if a system has to choose between a trove that requires x86(i586) and one that requires x86(i586 i686), the i686 one wins. We think that this is a general solution when one instruction set is a superset of the other. The alternative would be to somehow track these instruction set hierarchies while doing flavor scoring, which would be ugly since the scoring code is mostly (all?) sql code. It should be much easier to track the hierarchies on the build side when creating the trove flavors. Comments? David From johnsonm@lambchop.rdu.specifix.com Thu Jan 6 16:00:18 2005 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j06L0IQv013522 for ; Thu, 6 Jan 2005 16:00:18 -0500 Received: from lambchop.rdu.specifix.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 95C26164E0 for ; Thu, 6 Jan 2005 13:00:01 -0800 (PST) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j06L00fb019265 for ; Thu, 6 Jan 2005 16:00:00 -0500 Received: (from johnsonm@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j06L00pC019263 for conary-list@lists.specifix.com; Thu, 6 Jan 2005 16:00:00 -0500 Date: Thu, 6 Jan 2005 16:00:00 -0500 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20050106210000.GA19157@lambchop.rdu.specifix.com> References: <20050106154337.GC18122@lambchop.rdu.specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050106154337.GC18122@lambchop.rdu.specifix.com> User-Agent: Mutt/1.4.1i Subject: Re: Overlapping instruction sets X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 21:00:19 -0000 On Thu, Jan 06, 2005 at 10:43:37AM -0500, David B. Christian wrote: > oot suggested that troves that require x86(i686) be fleshed out to require > x86(i586 i686). That way, if a system has to choose between a trove that > requires x86(i586) and one that requires x86(i586 i686), the i686 one wins. > We think that this is a general solution when one instruction set is a > superset of the other. You could still theoretically have two troves that are built with two disjoint sets that happen to score the same, but if you care between those two, you probably should be explicitly providing the flavor on the command line anyway. And once you have installed the trove, flavor affinity will avoid surprises. Hmm, there are two ways you could see this problem: o x86(foo bar) and x86(blah baz) available, where the current system implements x86(foo bar blah baz) o x86(foo bar) and x86_64(blah baz) available, where the current system implements x86(foo bar) and x86_64(blah baz) The first one shouldn't generally matter, I think -- you can always do foo[is:x86(foo bar)] to get the flavor you want, and if you do not care, you'll get something that works. The second one I don't know what we do... From fedora64@leaper.linuxtx.org Thu Jan 6 16:09:06 2005 Received: from leaper.linuxtx.org (c-24-1-16-159.client.comcast.net [24.1.16.159]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j06L96Qv013554 for ; Thu, 6 Jan 2005 16:09:06 -0500 Received: from leaper.linuxtx.org (localhost.localdomain [127.0.0.1]) by leaper.linuxtx.org (8.12.11/8.12.11) with ESMTP id j06L8o9H024742 for ; Thu, 6 Jan 2005 15:08:50 -0600 Received: (from fedora64@localhost) by leaper.linuxtx.org (8.12.11/8.12.11/Submit) id j06L8jZR024741 for conary-list@lists.specifix.com; Thu, 6 Jan 2005 15:08:45 -0600 Date: Thu, 6 Jan 2005 15:08:45 -0600 From: "Justin M. Forbes" To: Conary Discussion Message-ID: <20050106210845.GA17996@linuxtx.org> References: <20050106154337.GC18122@lambchop.rdu.specifix.com> <20050106210000.GA19157@lambchop.rdu.specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050106210000.GA19157@lambchop.rdu.specifix.com> User-Agent: Mutt/1.4.1i Subject: Re: Overlapping instruction sets X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 21:09:06 -0000 On Thu, Jan 06, 2005 at 04:00:00PM -0500, Michael K. Johnson wrote: > > Hmm, there are two ways you could see this problem: > o x86(foo bar) and x86(blah baz) available, where the current > system implements x86(foo bar blah baz) > o x86(foo bar) and x86_64(blah baz) available, where the current > system implements x86(foo bar) and x86_64(blah baz) > > The second one I don't know what we do... The second should not score the same, since arch takes precedence (or does it?) Conary update would give x86_64(blah baz) and if you want the x86(foo bar) version, you specify. Flavor affinity should take care of it from there. Of course you can always --keep-existing and install both of they do not overlap. Justin From johnsonm@lambchop.rdu.specifix.com Thu Jan 6 16:28:21 2005 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j06LSLQv013618 for ; Thu, 6 Jan 2005 16:28:21 -0500 Received: from lambchop.rdu.specifix.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 84BB9164E0 for ; Thu, 6 Jan 2005 13:28:04 -0800 (PST) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j06LS3fb020893 for ; Thu, 6 Jan 2005 16:28:03 -0500 Received: (from johnsonm@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j06LS2CX020891 for conary-list@lists.specifix.com; Thu, 6 Jan 2005 16:28:02 -0500 Date: Thu, 6 Jan 2005 16:28:02 -0500 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20050106212802.GA20572@lambchop.rdu.specifix.com> References: <20050106154337.GC18122@lambchop.rdu.specifix.com> <20050106210000.GA19157@lambchop.rdu.specifix.com> <20050106210845.GA17996@linuxtx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050106210845.GA17996@linuxtx.org> User-Agent: Mutt/1.4.1i Subject: Re: Overlapping instruction sets X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 21:28:22 -0000 On Thu, Jan 06, 2005 at 03:08:45PM -0600, Justin M. Forbes wrote: > On Thu, Jan 06, 2005 at 04:00:00PM -0500, Michael K. Johnson wrote: > > > > Hmm, there are two ways you could see this problem: > > o x86(foo bar) and x86(blah baz) available, where the current > > system implements x86(foo bar blah baz) > > o x86(foo bar) and x86_64(blah baz) available, where the current > > system implements x86(foo bar) and x86_64(blah baz) > > > > The second one I don't know what we do... > The second should not score the same, since arch takes precedence (or does > it?) Conary update would give x86_64(blah baz) and if you want the > x86(foo bar) version, you specify. Flavor affinity should take care of it > from there. Of course you can always --keep-existing and install both of > they do not overlap. Sure, flavor affinity works once you have something installed. So the only case to consider is the "not yet installed" case. The rest of my mail assumes that case. What do you mean by "arch takes precedence"? Client tells server what its flavor is, which basically is a representation of what it supports. Server scores and returns best match. I don't know where arch scoring fits in here... Possibly client could send multiple a flavor with multiple is: entries, with first being best, and if first doesn't exist, then walk down the chain. For example, it might pass the client flavor as use: ~foo !bar baz is: x86_64(~sse3 ~3dnow) is: x86(~i686 ~i586 ~i486 ~cmov ~mmx ~mmxext ~sse ~sse2) split across multiple lines for readability, of course, I'm talking all one flavor here. Then the server would look first for x86_64 matches and only fall back to x86 matches if x86_64 fails? From fedora64@leaper.linuxtx.org Thu Jan 6 16:43:45 2005 Received: from leaper.linuxtx.org (c-24-1-16-159.client.comcast.net [24.1.16.159]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j06LhiQv013652 for ; Thu, 6 Jan 2005 16:43:44 -0500 Received: from leaper.linuxtx.org (localhost.localdomain [127.0.0.1]) by leaper.linuxtx.org (8.12.11/8.12.11) with ESMTP id j06LhSqS025182 for ; Thu, 6 Jan 2005 15:43:28 -0600 Received: (from fedora64@localhost) by leaper.linuxtx.org (8.12.11/8.12.11/Submit) id j06LhNZo025181 for conary-list@lists.specifix.com; Thu, 6 Jan 2005 15:43:23 -0600 Date: Thu, 6 Jan 2005 15:43:23 -0600 From: "Justin M. Forbes" To: Conary Discussion Message-ID: <20050106214323.GB17996@linuxtx.org> References: <20050106154337.GC18122@lambchop.rdu.specifix.com> <20050106210000.GA19157@lambchop.rdu.specifix.com> <20050106210845.GA17996@linuxtx.org> <20050106212802.GA20572@lambchop.rdu.specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050106212802.GA20572@lambchop.rdu.specifix.com> User-Agent: Mutt/1.4.1i Subject: Re: Overlapping instruction sets X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 21:43:45 -0000 On Thu, Jan 06, 2005 at 04:28:02PM -0500, Michael K. Johnson wrote: > > What do you mean by "arch takes precedence"? > > Client tells server what its flavor is, which basically is a representation > of what it supports. Server scores and returns best match. I don't know > where arch scoring fits in here... > > Possibly client could send multiple a flavor with multiple is: entries, > with first being best, and if first doesn't exist, then walk down the > chain. For example, it might pass the client flavor as > use: ~foo !bar baz > is: x86_64(~sse3 ~3dnow) > is: x86(~i686 ~i586 ~i486 ~cmov ~mmx ~mmxext ~sse ~sse2) > split across multiple lines for readability, of course, I'm talking > all one flavor here. Then the server would look first for x86_64 matches > and only fall back to x86 matches if x86_64 fails? The client should not pass as x86 and x86_64, it is one or the other. In the x86_64 case, you would have to specify x86 as an override to install an x86 trove. Basically the server should never tell the client that an x86 trove is available for consideration unless the client specifically asks for it. Justin From johnsonm@lambchop.rdu.specifix.com Thu Jan 6 18:06:58 2005 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j06N6wQv014008 for ; Thu, 6 Jan 2005 18:06:58 -0500 Received: from lambchop.rdu.specifix.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 76CA9164E0 for ; Thu, 6 Jan 2005 15:06:41 -0800 (PST) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j06N6efb025893 for ; Thu, 6 Jan 2005 18:06:40 -0500 Received: (from johnsonm@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j06N6eL3025890 for conary-list@lists.specifix.com; Thu, 6 Jan 2005 18:06:40 -0500 Date: Thu, 6 Jan 2005 18:06:40 -0500 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20050106230640.GA25714@lambchop.rdu.specifix.com> References: <20050106154337.GC18122@lambchop.rdu.specifix.com> <20050106210000.GA19157@lambchop.rdu.specifix.com> <20050106210845.GA17996@linuxtx.org> <20050106212802.GA20572@lambchop.rdu.specifix.com> <20050106214323.GB17996@linuxtx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050106214323.GB17996@linuxtx.org> User-Agent: Mutt/1.4.1i Subject: Re: Overlapping instruction sets X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 23:06:58 -0000 On Thu, Jan 06, 2005 at 03:43:23PM -0600, Justin M. Forbes wrote: > The client should not pass as x86 and x86_64, it is one or the other. In > the x86_64 case, you would have to specify x86 as an override to install an > x86 trove. Basically the server should never tell the client that an x86 > trove is available for consideration unless the client specifically asks > for it. Oh, I just saw that you and Erik were working on multiple instruction sets for multilib and also re-doing x86_64 handling and conflated the two. Good. Then I'm having trouble worrying too much about this, unless someone can come up with a bad cornercase. From dbc@lambchop.rdu.specifix.com Wed Jan 12 12:26:54 2005 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j0CHQrQv027434 for ; Wed, 12 Jan 2005 12:26:54 -0500 Received: from lambchop.rdu.specifix.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 616C616550 for ; Wed, 12 Jan 2005 09:26:34 -0800 (PST) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j0CHQWfb021658 for ; Wed, 12 Jan 2005 12:26:32 -0500 Received: (from dbc@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j0CHQVC9021656 for conary-list@lists.specifix.com; Wed, 12 Jan 2005 12:26:31 -0500 Date: Wed, 12 Jan 2005 12:26:31 -0500 From: "David B. Christian" To: Conary Discussion Message-ID: <20050112172631.GE19205@lambchop.rdu.specifix.com> References: <20041207194422.GA3225@lambchop.rdu.specifixinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041207194422.GA3225@lambchop.rdu.specifixinc.com> User-Agent: Mutt/1.4.1i Subject: Re: versions and paths between recipes X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 17:26:54 -0000 I'm including this entire previous post since the mesage I'm responding to is a month old. On Tue, Dec 07, 2004 at 02:44:22PM -0500, Michael K. Johnson commented: > For some time, we've been wondering how best to deal with things > like the python site-packages path. There are several packages > that put files in a per-version site-packages directory > (/usr/lib{,64}/python/site-packages -- but the best way > to figure out within a recipe other than python.recipe what was > the system python version eluded us. > > Not any more. > > At the top of your recipe file, run > loadRecipe('python.recipe') > just as if you were going to subclass python. But then, you > can access some variables. For example: > r.macros.pythonversion = Python.version > r.macros.pythonmajorversion = Python.majversion > r.macros.pythonsitepkgs = Python.sitepkgs > (You can give the macros shorter names, of course; anything > that doesn't conflict for that package.) > > The nice thing about using loadRecipe that way is that it will > always pull the latest python recipe off the current label. > So if you branch your recipe into a branch that also contains > a modified python with a different version, you'll automatically > start picking up the new pythong version to match the branch. I was working with loadRecipe today, and was bothered by something: versions and information loaded in this manner could be incorrect. For example, if I had not yet upgraded to python2.4, and tried to cook pyparted, which includes the lines: loadRecipe('python.recipe') r.macros.pyver = Python.majversion r.Configure('--with-python-version=%(pyver)s') Since the latest python recipe on my default install label is python-2.4, it would substitute in r.Configure('--with-python-version=2.4'), which would then probably fail to compile. Hypothetically (this is not implemented), I could modify the recipe to say loadRecipe('python.recipe', version='2.3-1'), or something along those lines. But what it seems like we really want to do is look at the installed system. It might even be worthwhile to require the installation of the recipe with the cooked trove, and to load that. Comments? David From johnsonm@lambchop.rdu.specifix.com Thu Jan 13 11:01:57 2005 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j0DG1uQv004000 for ; Thu, 13 Jan 2005 11:01:57 -0500 Received: from lambchop.rdu.specifix.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 4F23A169C4 for ; Thu, 13 Jan 2005 08:01:37 -0800 (PST) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j0DG1Zfb010999 for ; Thu, 13 Jan 2005 11:01:35 -0500 Received: (from johnsonm@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j0DG1ZuM010997 for conary-list@lists.specifix.com; Thu, 13 Jan 2005 11:01:35 -0500 Date: Thu, 13 Jan 2005 11:01:35 -0500 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20050113160135.GA10890@lambchop.rdu.specifix.com> References: <20041207194422.GA3225@lambchop.rdu.specifixinc.com> <20050112172631.GE19205@lambchop.rdu.specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050112172631.GE19205@lambchop.rdu.specifix.com> User-Agent: Mutt/1.4.1i Subject: Re: versions and paths between recipes X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 16:01:57 -0000 On Wed, Jan 12, 2005 at 12:26:31PM -0500, David B. Christian wrote: > I was working with loadRecipe today, and was bothered by something: versions > and information loaded in this manner could be incorrect. > > For example, if I had not yet upgraded to python2.4, and tried to cook > pyparted, which includes the lines: > loadRecipe('python.recipe') > r.macros.pyver = Python.majversion > r.Configure('--with-python-version=%(pyver)s') > > Since the latest python recipe on my default install label is python-2.4, it > would substitute in r.Configure('--with-python-version=2.4'), which would > then probably fail to compile. > > Hypothetically (this is not implemented), I could modify the recipe to say > loadRecipe('python.recipe', version='2.3-1'), or something along those lines. > But what it seems like we really want to do is look at the installed system. > It might even be worthwhile to require the installation of the recipe with > the cooked trove, and to load that. > > Comments? I disagree, we don't want version= at all, since the whole point is to pick up the current version as defined in the distribution, not whatever happens to be currently installed on the system. The only thing that needs to be changed, I think, is to check that any version of the packages defined by the recipe loaded by loadRecipe installed on the system is up to date relative to the repository, and give either an error message or a warning message if that's not the case. (That careful, though convoluted, wording deals with pure virtual base class recipes like gnomepackage.) But that really probably needs to wait until Conary proper actually implements buildRequires, since this is just a special case of something like buildRequires. From dbc@lambchop.rdu.specifix.com Thu Jan 13 11:24:56 2005 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j0DGOuQv004046 for ; Thu, 13 Jan 2005 11:24:56 -0500 Received: from lambchop.rdu.specifix.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id CEAE7169C4 for ; Thu, 13 Jan 2005 08:24:36 -0800 (PST) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j0DGOZfb011484 for ; Thu, 13 Jan 2005 11:24:35 -0500 Received: (from dbc@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j0DGOZZZ011482 for conary-list@lists.specifix.com; Thu, 13 Jan 2005 11:24:35 -0500 Date: Thu, 13 Jan 2005 11:24:35 -0500 From: "David B. Christian" To: Conary Discussion Message-ID: <20050113162435.GA7070@lambchop.rdu.specifix.com> References: <20041207194422.GA3225@lambchop.rdu.specifixinc.com> <20050112172631.GE19205@lambchop.rdu.specifix.com> <20050113160135.GA10890@lambchop.rdu.specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050113160135.GA10890@lambchop.rdu.specifix.com> User-Agent: Mutt/1.4.1i Subject: Re: versions and paths between recipes X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 16:24:57 -0000 On Thu, Jan 13, 2005 at 11:01:35AM -0500, Michael K. Johnson commented: > I disagree, we don't want version= at all, since the whole point is to > pick up the current version as defined in the distribution, not whatever > happens to be currently installed on the system. This is not the whole point, it is one point. You should also be able to cook a recipe locally without needing to upgrade everything on your system to be equal to the repository's latest versions. It seems like there are two cases here: 1. when you are cooking a changeset locally, 2. when you are cooking the changeset into the repository. I agree that if you are committing the resule of a cook to head, the changeset committed should work with other recipes on head. But if you're cooking locally, there should be no such restriction. I'd say that if you are cooking locally, you should load the recipe that matches what is installed on the local system. > The only thing that needs to be changed, I think, is to check that any > version of the packages defined by the recipe loaded by loadRecipe > installed on the system is up to date relative to the repository, and give > either an error message or a warning message if that's not the case. > (That careful, though convoluted, wording deals with pure virtual base > class recipes like gnomepackage.) A warning like this might even make sense if you are cooking locally. But there should be a way to override the warning and cook anyway, and that way should load the recipe that corresponds to what you have installed. Otherwise you are loading recipe that may be completely unrelated to the reality of the system you are cooking the package for. Virtual base class recipes are an interesting case. I suspect we'll have to store the version used somewhere in the cooked trove along with other information. > But that really probably needs to wait until Conary proper actually > implements buildRequires, since this is just a special case of something > like buildRequires. I agree. David From johnsonm@lambchop.rdu.specifix.com Thu Jan 13 12:05:48 2005 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j0DH5mQv004144 for ; Thu, 13 Jan 2005 12:05:48 -0500 Received: from lambchop.rdu.specifix.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id A348C167C2 for ; Thu, 13 Jan 2005 09:05:28 -0800 (PST) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j0DH5Rfb012194 for ; Thu, 13 Jan 2005 12:05:27 -0500 Received: (from johnsonm@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j0DH5QoW012192 for conary-list@lists.specifix.com; Thu, 13 Jan 2005 12:05:26 -0500 Date: Thu, 13 Jan 2005 12:05:26 -0500 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20050113170526.GA11833@lambchop.rdu.specifix.com> References: <20041207194422.GA3225@lambchop.rdu.specifixinc.com> <20050112172631.GE19205@lambchop.rdu.specifix.com> <20050113160135.GA10890@lambchop.rdu.specifix.com> <20050113162435.GA7070@lambchop.rdu.specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050113162435.GA7070@lambchop.rdu.specifix.com> User-Agent: Mutt/1.4.1i Subject: Re: versions and paths between recipes X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 17:05:48 -0000 On Thu, Jan 13, 2005 at 11:24:35AM -0500, David B. Christian wrote: > It seems like there are two cases here: 1. when you are cooking a changeset > locally, 2. when you are cooking the changeset into the repository. I agree > that if you are committing the resule of a cook to head, the changeset > committed should work with other recipes on head. But if you're cooking > locally, there should be no such restriction. > > I'd say that if you are cooking locally, you should load the recipe that > matches what is installed on the local system. Yes, I agree that this makes more sense. From ken@bizrace.com Thu Jan 27 07:53:47 2005 Received: from mail.bizrace.com (eth0.bizrace.com [66.45.101.41] (may be forged)) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j0RCrlQv012978 for ; Thu, 27 Jan 2005 07:53:47 -0500 Received: by mail.bizrace.com (Postfix, from userid 48) id 022CE5F694; Thu, 27 Jan 2005 07:53:21 -0500 (EST) Received: from 66-194-221-254.gen.twtelecom.net ( [66-194-221-254.gen.twtelecom.net]) as user ken.bizrace.com@web1.bizrace.com by webmail.bizrace.com with HTTP; Thu, 27 Jan 2005 07:53:21 -0500 Message-ID: <1106830401.41f8e441c54ca@webmail.bizrace.com> Date: Thu, 27 Jan 2005 07:53:21 -0500 From: Ken VanDine To: Conary Discussion MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ11068304013de7c71da0b2da34ccd4aefe419280cd" User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 66.194.221.254 Subject: Shadow of kernel X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 12:53:47 -0000 This message is in MIME format. ---MOQ11068304013de7c71da0b2da34ccd4aefe419280cd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I have created a shadow of the kernel and patched it for inotify support. Cooking it fails, here is the traceback. Any ideas? Thanks, --Ken ---MOQ11068304013de7c71da0b2da34ccd4aefe419280cd Content-Type: application/octet-stream; name="conary-stack-tTFcLL" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="conary-stack-tTFcLL" RXhjZXB0aW9uOiBLZXlFcnJvcjogJycKCgpUcmFjZWJhY2sgKG1vc3QgcmVjZW50IGNhbGwgbGFz dCk6CiAgRmlsZSAiL3Vzci9zaGFyZS9jb25hcnkvY3ZjIiwgbGluZSAyMSwgaW4gPwogICAgc3lz LmV4aXQoY3ZjLm1haW4oKSkKICBGaWxlICIvdXNyL3NoYXJlL2NvbmFyeS9jdmMucHkiLCBsaW5l IDMxNiwgaW4gbWFpbgogICAgcmVhbE1haW4oY2ZnLCBhcmd2KQogIEZpbGUgIi91c3Ivc2hhcmUv Y29uYXJ5L2N2Yy5weSIsIGxpbmUgMTI4LCBpbiByZWFsTWFpbgogICAgc291cmNlQ29tbWFuZChj ZmcsIG90aGVyQXJnc1sxOl0sIGFyZ1NldCkKICBGaWxlICIvdXNyL3NoYXJlL2NvbmFyeS9jdmMu cHkiLCBsaW5lIDI4MSwgaW4gc291cmNlQ29tbWFuZAogICAgYWxsb3dVbmtub3duRmxhZ3M9dW5r bm93bkZsYWdzKQogIEZpbGUgIi91c3Ivc2hhcmUvY29uYXJ5L2J1aWxkL2Nvb2sucHkiLCBsaW5l IDc4NywgaW4gY29va0NvbW1hbmQKICAgIGFsbG93VW5rbm93bkZsYWdzID0gYWxsb3dVbmtub3du RmxhZ3MpCiAgRmlsZSAiL3Vzci9zaGFyZS9jb25hcnkvYnVpbGQvY29vay5weSIsIGxpbmUgNzI1 LCBpbiBjb29rSXRlbQogICAgYWxsb3dVbmtub3duRmxhZ3MgPSBhbGxvd1Vua25vd25GbGFncykK ICBGaWxlICIvdXNyL3NoYXJlL2NvbmFyeS9idWlsZC9jb29rLnB5IiwgbGluZSAyNjEsIGluIGNv b2tPYmplY3QKICAgIGFsd2F5c0J1bXBDb3VudCA9IGFsd2F5c0J1bXBDb3VudCkKICBGaWxlICIv dXNyL3NoYXJlL2NvbmFyeS9idWlsZC9jb29rLnB5IiwgbGluZSA1NDUsIGluIGNvb2tQYWNrYWdl T2JqZWN0CiAgICBibGRMaXN0ID0gcmVjaXBlT2JqLmdldFBhY2thZ2VzKCkKICBGaWxlICIvdXNy L3NoYXJlL2NvbmFyeS9idWlsZC9yZWNpcGUucHkiLCBsaW5lIDUwMiwgaW4gZ2V0UGFja2FnZXMK ICAgIHBvbGljeS5kb1Byb2Nlc3Moc2VsZikKICBGaWxlICIvdXNyL3NoYXJlL2NvbmFyeS9idWls ZC9wb2xpY3kucHkiLCBsaW5lIDIwNiwgaW4gZG9Qcm9jZXNzCiAgICBzZWxmLmRvKCkKICBGaWxl ICIvdXNyL3NoYXJlL2NvbmFyeS9idWlsZC9wb2xpY3kucHkiLCBsaW5lIDIxOCwgaW4gZG8KICAg IG9zLnBhdGgud2FsayhmdWxscGF0aCwgc2VsZi53YWxrRGlyLCBOb25lKQogIEZpbGUgIi91c3Iv bGliL3B5dGhvbjIuNC9wb3NpeHBhdGgucHkiLCBsaW5lIDI5OCwgaW4gd2FsawogICAgd2Fsayhu YW1lLCBmdW5jLCBhcmcpCiAgRmlsZSAiL3Vzci9saWIvcHl0aG9uMi40L3Bvc2l4cGF0aC5weSIs IGxpbmUgMjk4LCBpbiB3YWxrCiAgICB3YWxrKG5hbWUsIGZ1bmMsIGFyZykKICBGaWxlICIvdXNy L2xpYi9weXRob24yLjQvcG9zaXhwYXRoLnB5IiwgbGluZSAyOTgsIGluIHdhbGsKICAgIHdhbGso bmFtZSwgZnVuYywgYXJnKQogIEZpbGUgIi91c3IvbGliL3B5dGhvbjIuNC9wb3NpeHBhdGgucHki LCBsaW5lIDI5MCwgaW4gd2FsawogICAgZnVuYyhhcmcsIHRvcCwgbmFtZXMpCiAgRmlsZSAiL3Vz ci9zaGFyZS9jb25hcnkvYnVpbGQvcG9saWN5LnB5IiwgbGluZSAyMzIsIGluIHdhbGtEaXIKICAg IHNlbGYuZG9GaWxlKHRoaXNwYXRoKQogIEZpbGUgIi91c3Ivc2hhcmUvY29uYXJ5L2J1aWxkL3Bh Y2thZ2Vwb2xpY3kucHkiLCBsaW5lIDEzOTgsIGluIGRvRmlsZQogICAgc2V0LnVuaW9uKHVzZS5j cmVhdGVGbGF2b3IoTm9uZSwgdXNlLkFyY2guX2l0ZXJVc2VkKCkpKQogIEZpbGUgIi91c3Ivc2hh cmUvY29uYXJ5L2J1aWxkL3VzZS5weSIsIGxpbmUgNjU2LCBpbiBjcmVhdGVGbGF2b3IKICAgIHNl dC51bmlvbihmbGFnLl90b0RlcGVuZGVuY3koKSkKICBGaWxlICIvdXNyL3NoYXJlL2NvbmFyeS9i dWlsZC91c2UucHkiLCBsaW5lIDUxMywgaW4gX3RvRGVwZW5kZW5jeQogICAgZGVwRmxhZ3MuZXh0 ZW5kKChwYXJlbnRbeF0uX25hbWUsIHNlbnNlKSBcCiAgRmlsZSAiL3Vzci9zaGFyZS9jb25hcnkv YnVpbGQvdXNlLnB5IiwgbGluZSA1MTMsIGluIDxnZW5lcmF0b3IgZXhwcmVzc2lvbj4KICAgIGRl cEZsYWdzLmV4dGVuZCgocGFyZW50W3hdLl9uYW1lLCBzZW5zZSkgXAogIEZpbGUgIi91c3Ivc2hh cmUvY29uYXJ5L2J1aWxkL3VzZS5weSIsIGxpbmUgMjEzLCBpbiBfX2dldGl0ZW1fXwogICAgcmV0 dXJuIGRpY3QuX19nZXRpdGVtX18oc2VsZiwga2V5KQpLZXlFcnJvcjogJycKPj4gL3Vzci9zaGFy ZS9jb25hcnkvY3ZjOjIxOiBfX21haW5fXy4/KCkKPj4gL3Vzci9zaGFyZS9jb25hcnkvY3ZjLnB5 OjMzNzogY3ZjLm1haW4oYXJndikKICBQYXJhbXM6IAogICAgYXJndiA9IFsnL3Vzci9zaGFyZS9j b25hcnkvY3ZjJywgJ2Nvb2snLCAnLS1uby1jbGVhbicsICdrZXJuZWwnXQogIExvY2FsczogCiAg ICBjZmcgPSAiJzx1bnByaW50YWJsZSBvZiBjbGFzcyBjb25hcnljZmcuQ29uYXJ5Q29uZmlndXJh dGlvbj4nIgo+PiAvdXNyL3NoYXJlL2NvbmFyeS9jdmMucHk6MTI4OiBjdmMucmVhbE1haW4oY2Zn LCBhcmd2KQogIFBhcmFtczogCiAgICBjZmcgPSAnPHVucHJpbnRhYmxlIG9mIGNsYXNzIGNvbmFy eWNmZy5Db25hcnlDb25maWd1cmF0aW9uPicKICAgIGFyZ3YgPSBbJy91c3Ivc2hhcmUvY29uYXJ5 L2N2YycsICdjb29rJywgJy0tbm8tY2xlYW4nLCAna2VybmVsJ10KICBMb2NhbHM6IAogICAgTVVM VF9QQVJBTSA9ICczJwogICAgTk9fUEFSQU0gPSAnMCcKICAgIE9ORV9QQVJBTSA9ICcxJwogICAg T1BUX1BBUkFNID0gJzInCiAgICBhcmdEZWYgPSAieydidWlsZC1sYWJlbCc6IDEsICdjb25maWcn OiAzLCAnY29uZmlnLWZpbGUnOiAxLCAnZGVidWcnOiAwLCAuLi59IgogICAgYXJnU2V0ID0gJ3t9 JwogICAgY2ZnTWFwID0gInsnYnVpbGQtbGFiZWwnOiAnYnVpbGRMYWJlbCd9IgogICAgb3RoZXJB cmdzID0gIlsnL3Vzci9zaGFyZS9jb25hcnkvY3ZjJywgJ2Nvb2snLCAna2VybmVsJ10iCj4+IC91 c3Ivc2hhcmUvY29uYXJ5L2N2Yy5weToyODE6IGN2Yy5zb3VyY2VDb21tYW5kKGNmZywgYXJncywg YXJnU2V0KQogIFBhcmFtczogCiAgICBjZmcgPSAnPHVucHJpbnRhYmxlIG9mIGNsYXNzIGNvbmFy eWNmZy5Db25hcnlDb25maWd1cmF0aW9uPicKICAgIGFyZ3MgPSBbJ2Nvb2snLCAna2VybmVsJ10K ICAgIGFyZ1NldCA9IHt9CiAgTG9jYWxzOiAKICAgIGJ1aWxkQnJhbmNoID0gJ05vbmUnCiAgICBs ZXZlbCA9ICczMCcKICAgIG1hY3JvcyA9ICJ7J2J1aWxkYnJhbmNoJzogJy9jb25hcnkuc3BlY2lm aXguY29tQHNweDpsaW51eC8vY29uYXJ5LnZhbmRpbmUub3JnQGtlbjpkZXNrdG9wJywgJ2J1aWxk bGFiZWwnOiAnY29uYXJ5LnZhbmRpbmUub3JnQGtlbjpkZXNrdG9wJ30iCiAgICBwcmVwID0gJzAn CiAgICByZXN1bWUgPSAnTm9uZScKICAgIHVua25vd25GbGFncyA9ICdGYWxzZScKPj4gL3Vzci9z aGFyZS9jb25hcnkvYnVpbGQvY29vay5weTo3OTA6IGJ1aWxkLmNvb2suY29va0NvbW1hbmQoY2Zn LCBhcmdzLCBwcmVwLCBtYWNyb3MsIGJ1aWxkQnJhbmNoLCBlbWVyZ2UsIHJlc3VtZSwgYWxsb3dV bmtub3duRmxhZ3MpCiAgUGFyYW1zOiAKICAgIGNmZyA9ICc8dW5wcmludGFibGUgb2YgY2xhc3Mg Y29uYXJ5Y2ZnLkNvbmFyeUNvbmZpZ3VyYXRpb24+JwogICAgYXJncyA9IFsna2VybmVsJ10KICAg IHByZXAgPSAwCiAgICBtYWNyb3MgPSB7J2J1aWxkYnJhbmNoJzogJy9jb25hcnkuc3BlY2lmaXgu Y29tQHNweDpsaW51eC8vY29uYXJ5LnZhbmRpbmUub3JnQGtlbjpkZXNrdG9wJywgJ2J1aWxkbGFi ZWwnOiAnY29uYXJ5LnZhbmRpbmUub3JnQGtlbjpkZXNrdG9wJ30KICAgIGJ1aWxkQnJhbmNoID0g Tm9uZQogICAgZW1lcmdlID0gRmFsc2UKICAgIHJlc3VtZSA9IE5vbmUKICAgIGFsbG93VW5rbm93 bkZsYWdzID0gRmFsc2UKICBMb2NhbHM6IAogICAgaXRlbSA9ICIna2VybmVsJyIKICAgIHBpZCA9 ICcwJwogICAgcmVwb3MgPSAnPHJlcG9zaXQuLi40MDM0YjQ2Yz4nCj4+IC91c3Ivc2hhcmUvY29u YXJ5L2J1aWxkL2Nvb2sucHk6NzMxOiBidWlsZC5jb29rLmNvb2tJdGVtKHJlcG9zLCBjZmcsIGl0 ZW0sIHByZXAsIG1hY3JvcywgYnVpbGRCcmFuY2gsIGVtZXJnZSwgcmVzdW1lLCBhbGxvd1Vua25v d25GbGFncykKICBQYXJhbXM6IAogICAgcmVwb3MgPSA8cmVwb3NpdC4uLjQwMzRiNDZjPgogICAg Y2ZnID0gJzx1bnByaW50YWJsZSBvZiBjbGFzcyBjb25hcnljZmcuQ29uYXJ5Q29uZmlndXJhdGlv bj4nCiAgICBpdGVtID0gJ2tlcm5lbCcKICAgIHByZXAgPSAwCiAgICBtYWNyb3MgPSB7J2J1aWxk YnJhbmNoJzogJy9jb25hcnkuc3BlY2lmaXguY29tQHNweDpsaW51eC8vY29uYXJ5LnZhbmRpbmUu b3JnQGtlbjpkZXNrdG9wJywgJ2J1aWxkbGFiZWwnOiAnY29uYXJ5LnZhbmRpbmUub3JnQGtlbjpk ZXNrdG9wJ30KICAgIGJ1aWxkQnJhbmNoID0gTm9uZQogICAgZW1lcmdlID0gRmFsc2UKICAgIHJl c3VtZSA9IE5vbmUKICAgIGFsbG93VW5rbm93bkZsYWdzID0gRmFsc2UKICBMb2NhbHM6IAogICAg YnVpbGRMaXN0ID0gJ1tdJwogICAgYnVpbHQgPSAnTm9uZScKICAgIGNoYW5nZVNldEZpbGUgPSAn Tm9uZScKICAgIGxhYmVsID0gJ05vbmUnCiAgICBsb2FkZXIgPSAiJzx1bnByaW50YWJsZSBvZiBj bGFzcyBidWlsZC5yZWNpcGUuUmVjaXBlTG9hZGVyPiciCiAgICByZWNpcGVDbGFzcyA9ICInPENs YXNzIHRlbXAta2VybmVsLXprOGJ1Si1yZWNpcGUuS2VybmVsPiciCiAgICBzb3VyY2VWZXJzaW9u ID0gIicvY29uYXJ5LnNwZWNpZml4LmNvbUBzcHg6bGludXgvL2NvbmFyeS52YW5kaW5lLm9yZ0Br ZW46ZGVza3RvcC8yLjYuMTAtOC4xJyIKICAgIHRhcmdldExhYmVsID0gJ05vbmUnCj4+IC91c3Iv c2hhcmUvY29uYXJ5L2J1aWxkL2Nvb2sucHk6MjYxOiBidWlsZC5jb29rLmNvb2tPYmplY3QocmVw b3MsIGNmZywgcmVjaXBlQ2xhc3MsIGJ1aWxkTGFiZWwsIGNoYW5nZVNldEZpbGUsIHByZXAsIG1h Y3JvcywgYnVpbGRCcmFuY2gsIHRhcmdldExhYmVsLCBzb3VyY2VWZXJzaW9uLCByZXN1bWUsIGFs d2F5c0J1bXBDb3VudCwgYWxsb3dVbmtub3duRmxhZ3MpCiAgUGFyYW1zOiAKICAgIHJlcG9zID0g PHJlcG9zaXQuLi40MDM0YjQ2Yz4KICAgIGNmZyA9ICc8dW5wcmludGFibGUgb2YgY2xhc3MgY29u YXJ5Y2ZnLkNvbmFyeUNvbmZpZ3VyYXRpb24+JwogICAgcmVjaXBlQ2xhc3MgPSAnPENsYXNzIHRl bXAta2VybmVsLXprOGJ1Si1yZWNpcGUuS2VybmVsPicKICAgIGJ1aWxkTGFiZWwgPSAnY29uYXJ5 LnZhbmRpbmUub3JnQGtlbjpkZXNrdG9wJwogICAgY2hhbmdlU2V0RmlsZSA9IE5vbmUKICAgIHBy ZXAgPSAwCiAgICBtYWNyb3MgPSB7J2J1aWxkYnJhbmNoJzogJy9jb25hcnkuc3BlY2lmaXguY29t QHNweDpsaW51eC8vY29uYXJ5LnZhbmRpbmUub3JnQGtlbjpkZXNrdG9wJywgJ2J1aWxkbGFiZWwn OiAnY29uYXJ5LnZhbmRpbmUub3JnQGtlbjpkZXNrdG9wJ30KICAgIGJ1aWxkQnJhbmNoID0gJy9j b25hcnkuc3BlY2lmaXguY29tQHNweDpsaW51eC8vY29uYXJ5LnZhbmRpbmUub3JnQGtlbjpkZXNr dG9wJwogICAgdGFyZ2V0TGFiZWwgPSBOb25lCiAgICBzb3VyY2VWZXJzaW9uID0gJy9jb25hcnku c3BlY2lmaXguY29tQHNweDpsaW51eC8vY29uYXJ5LnZhbmRpbmUub3JnQGtlbjpkZXNrdG9wLzIu Ni4xMC04LjEnCiAgICByZXN1bWUgPSBOb25lCiAgICBhbHdheXNCdW1wQ291bnQgPSBGYWxzZQog ICAgYWxsb3dVbmtub3duRmxhZ3MgPSBGYWxzZQogIExvY2FsczogCiAgICBicmFuY2hlcyA9ICdb PHZlcnNpb24uLi40MDhmNWJhYz5dJwogICAgZnVsbE5hbWUgPSAiJ2tlcm5lbCciCiAgICBzcmNO YW1lID0gIidrZXJuZWw6c291cmNlJyIKICAgIHZlcnMgPSAnWzx2ZXJzaW9uLi4uNDA4ZWNhMmM+ XScKICAgIHZlcnNpb24gPSAiJ2NvbmFyeS52YW5kaW5lLm9yZ0BrZW46ZGVza3RvcCciCiAgICB4 ID0gIicvY29uYXJ5LnNwZWNpZml4LmNvbUBzcHg6bGludXgvL2NvbmFyeS52YW5kaW5lLm9yZ0Br ZW46ZGVza3RvcC8yLjYuMTAtOC4xJyIKPj4gL3Vzci9zaGFyZS9jb25hcnkvYnVpbGQvY29vay5w eTo1NDU6IGJ1aWxkLmNvb2suY29va1BhY2thZ2VPYmplY3QocmVwb3MsIGNmZywgcmVjaXBlQ2xh c3MsIGJ1aWxkQnJhbmNoLCBwcmVwLCBtYWNyb3MsIHRhcmdldExhYmVsLCBzb3VyY2VWZXJzaW9u LCByZXN1bWUsIGFsd2F5c0J1bXBDb3VudCkKICBQYXJhbXM6IAogICAgcmVwb3MgPSA8cmVwb3Np dC4uLjQwMzRiNDZjPgogICAgY2ZnID0gJzx1bnByaW50YWJsZSBvZiBjbGFzcyBjb25hcnljZmcu Q29uYXJ5Q29uZmlndXJhdGlvbj4nCiAgICByZWNpcGVDbGFzcyA9ICc8Q2xhc3MgdGVtcC1rZXJu ZWwtems4YnVKLXJlY2lwZS5LZXJuZWw+JwogICAgYnVpbGRCcmFuY2ggPSAnL2NvbmFyeS5zcGVj aWZpeC5jb21Ac3B4OmxpbnV4Ly9jb25hcnkudmFuZGluZS5vcmdAa2VuOmRlc2t0b3AnCiAgICBw cmVwID0gMAogICAgbWFjcm9zID0geydidWlsZGJyYW5jaCc6ICcvY29uYXJ5LnNwZWNpZml4LmNv bUBzcHg6bGludXgvL2NvbmFyeS52YW5kaW5lLm9yZ0BrZW46ZGVza3RvcCcsICdidWlsZGxhYmVs JzogJ2NvbmFyeS52YW5kaW5lLm9yZ0BrZW46ZGVza3RvcCd9CiAgICB0YXJnZXRMYWJlbCA9IE5v bmUKICAgIHNvdXJjZVZlcnNpb24gPSAnL2NvbmFyeS5zcGVjaWZpeC5jb21Ac3B4OmxpbnV4Ly9j b25hcnkudmFuZGluZS5vcmdAa2VuOmRlc2t0b3AvMi42LjEwLTguMScKICAgIHJlc3VtZSA9IE5v bmUKICAgIGFsd2F5c0J1bXBDb3VudCA9IEZhbHNlCiAgTG9jYWxzOiAKICAgIGJsZEluZm8gPSAi eydlbmQnOiAuLi5sZC1pbmZvJ30iCiAgICBidWlsZGRpciA9ICInL2hvbWUva3ZhbmRpbmUvY29u YXJ5L2J1aWxkcy9rZXJuZWwnIgogICAgYnVpbHQgPSAnW10nCiAgICBjd2QgPSAiJy9ob21lL2t2 YW5kaW5lL2NvbmFyeS9rZW4vZGVza3RvcC9rZXJuZWwnIgogICAgZGVzdGRpciA9ICInL2hvbWUv a3ZhbmRpbmUvY29uYXJ5L2J1aWxkcy9rZXJuZWwvX1JPT1RfJyIKICAgIGZ1bGxOYW1lID0gIidr ZXJuZWwnIgogICAgZ3JwTmFtZSA9ICIna2VybmVsJyIKICAgIGxjYWNoZSA9ICInPHVucHJpbnRh YmxlIG9mIGNsYXNzIGJ1aWxkLmxvb2thc2lkZS5SZXBvc2l0b3J5Q2FjaGU+JyIKICAgIHJlY2lw ZU9iaiA9ICInPHVucHJpbnRhYmxlIG9mIGNsYXNzIHRlbXAta2VybmVsLXprOGJ1Si1yZWNpcGUu S2VybmVsPiciCiAgICBzcmNkaXJzID0gIlsnL3RtcCcsICcuJ10iCj4+IC91c3Ivc2hhcmUvY29u YXJ5L2J1aWxkL3JlY2lwZS5weTo1MDI6IGJ1aWxkLnJlY2lwZS5nZXRQYWNrYWdlcyhzZWxmKQog IFBhcmFtczogCiAgICBzZWxmID0gJzx1bnByaW50YWJsZSBvZiBjbGFzcyB0ZW1wLWtlcm5lbC16 azhidUotcmVjaXBlLktlcm5lbD4nCiAgTG9jYWxzOiAKICAgIHBvbGljeSA9ICInPHVucHJpbnRh YmxlIG9mIGNsYXNzIGJ1aWxkLnBhY2thZ2Vwb2xpY3kuRmxhdm9yPiciCj4+IC91c3Ivc2hhcmUv Y29uYXJ5L2J1aWxkL3BvbGljeS5weToyMDY6IGJ1aWxkLnBvbGljeS5kb1Byb2Nlc3Moc2VsZiwg cmVjaXBlKQogIFBhcmFtczogCiAgICBzZWxmID0gJzx1bnByaW50YWJsZSBvZiBjbGFzcyBidWls ZC5wYWNrYWdlcG9saWN5LkZsYXZvcj4nCiAgICByZWNpcGUgPSAnPHVucHJpbnRhYmxlIG9mIGNs YXNzIHRlbXAta2VybmVsLXprOGJ1Si1yZWNpcGUuS2VybmVsPicKPj4gL3Vzci9zaGFyZS9jb25h cnkvYnVpbGQvcG9saWN5LnB5OjIxODogYnVpbGQucG9saWN5LmRvKHNlbGYpCiAgUGFyYW1zOiAK ICAgIHNlbGYgPSAnPHVucHJpbnRhYmxlIG9mIGNsYXNzIGJ1aWxkLnBhY2thZ2Vwb2xpY3kuRmxh dm9yPicKICBMb2NhbHM6IAogICAgZnVsbHBhdGggPSAiJy9ob21lL2t2YW5kaW5lL2NvbmFyeS9i dWlsZHMva2VybmVsL19ST09UXy8nIgo+PiAvdXNyL2xpYi9weXRob24yLjQvcG9zaXhwYXRoLnB5 OjI5ODogcG9zaXhwYXRoLndhbGsodG9wLCBmdW5jLCBhcmcpCiAgUGFyYW1zOiAKICAgIHRvcCA9 ICcvaG9tZS9rdmFuZGluZS9jb25hcnkvYnVpbGRzL2tlcm5lbC9fUk9PVF8vJwogICAgZnVuYyA9 IDxib3VuZCBtLi4uMDhmYzNjYz4+CiAgICBhcmcgPSBOb25lCiAgTG9jYWxzOiAKICAgIG5hbWUg PSAiJy9ob21lL2t2YW5kaW5lL2NvbmFyeS9idWlsZHMva2VybmVsL19ST09UXy9saWInIgogICAg bmFtZXMgPSAiWydsaWInLCAnYm9vdCddIgogICAgc3QgPSAnKDE2ODc3LCAuLi4wNjc4MzM0NCkn Cj4+IC91c3IvbGliL3B5dGhvbjIuNC9wb3NpeHBhdGgucHk6Mjk4OiBwb3NpeHBhdGgud2Fsayh0 b3AsIGZ1bmMsIGFyZykKICBQYXJhbXM6IAogICAgdG9wID0gJy9ob21lL2t2YW5kaW5lL2NvbmFy eS9idWlsZHMva2VybmVsL19ST09UXy9saWInCiAgICBmdW5jID0gPGJvdW5kIG0uLi4wOGZjM2Nj Pj4KICAgIGFyZyA9IE5vbmUKICBMb2NhbHM6IAogICAgbmFtZSA9ICInL2hvbWUva3ZhbmRpbmUv Y29uYXJ5L2J1aWxkcy9rZXJuZWwvX1JPT1RfL2xpYi9tb2R1bGVzJyIKICAgIG5hbWVzID0gIlsn bW9kdWxlcyddIgogICAgc3QgPSAnKDE2ODc3LCAuLi4wNjc4MzM0NCknCj4+IC91c3IvbGliL3B5 dGhvbjIuNC9wb3NpeHBhdGgucHk6Mjk4OiBwb3NpeHBhdGgud2Fsayh0b3AsIGZ1bmMsIGFyZykK ICBQYXJhbXM6IAogICAgdG9wID0gJy9ob21lL2t2YW5kaW5lL2NvbmFyeS9idWlsZHMva2VybmVs L19ST09UXy9saWIvbW9kdWxlcycKICAgIGZ1bmMgPSA8Ym91bmQgbS4uLjA4ZmMzY2M+PgogICAg YXJnID0gTm9uZQogIExvY2FsczogCiAgICBuYW1lID0gIicvaG9tZS9rdmFuZGluZS9jb25hcnkv YnVpbGRzL2tlcm5lbC9fUk9PVF8vbGliL21vZHVsZXMvMi42LjEwLTIuc21wLng4Ni5pNjg2LmNt b3YnIgogICAgbmFtZXMgPSAiWycyLjYuMTAtMi5zbXAueDg2Lmk2ODYuY21vdiddIgogICAgc3Qg PSAnKDE2ODc3LCAuLi4wNjc4MzQ3NiknCj4+IC91c3IvbGliL3B5dGhvbjIuNC9wb3NpeHBhdGgu cHk6MjkwOiBwb3NpeHBhdGgud2Fsayh0b3AsIGZ1bmMsIGFyZykKICBQYXJhbXM6IAogICAgdG9w ID0gJy9ob21lL2t2YW5kaW5lL2NvbmFyeS9idWlsZHMva2VybmVsL19ST09UXy9saWIvbW9kdWxl cy8yLjYuMTAtMi5zbXAueDg2Lmk2ODYuY21vdicKICAgIGZ1bmMgPSA8Ym91bmQgbS4uLjA4ZmMz Y2M+PgogICAgYXJnID0gTm9uZQogIExvY2FsczogCiAgICBuYW1lcyA9ICJbJ2tlcm5lbCcsICdz b3VyY2UnLCAnYnVpbGQnLCAnY29uZmlncycsICd2bWxpbnV4J10iCj4+IC91c3Ivc2hhcmUvY29u YXJ5L2J1aWxkL3BvbGljeS5weToyMzI6IGJ1aWxkLnBvbGljeS53YWxrRGlyKHNlbGYsIGlnbm9y ZSwgZGlybmFtZSwgbmFtZXMpCiAgUGFyYW1zOiAKICAgIHNlbGYgPSAnPHVucHJpbnRhYmxlIG9m IGNsYXNzIGJ1aWxkLnBhY2thZ2Vwb2xpY3kuRmxhdm9yPicKICAgIGlnbm9yZSA9IE5vbmUKICAg IGRpcm5hbWUgPSAnL2hvbWUva3ZhbmRpbmUvY29uYXJ5L2J1aWxkcy9rZXJuZWwvX1JPT1RfL2xp Yi9tb2R1bGVzLzIuNi4xMC0yLnNtcC54ODYuaTY4Ni5jbW92JwogICAgbmFtZXMgPSBbJ2tlcm5l bCcsICdzb3VyY2UnLCAnYnVpbGQnLCAnY29uZmlncycsICd2bWxpbnV4J10KICBMb2NhbHM6IAog ICAgbmFtZSA9ICIndm1saW51eCciCiAgICBwYXRoID0gIicvbGliL21vZHVsZXMvMi42LjEwLTIu c21wLng4Ni5pNjg2LmNtb3YnIgogICAgcm9vdGRpcmxlbiA9ICc0MicKICAgIHRoaXNwYXRoID0g IicvbGliL21vZHVsZXMvMi42LjEwLTIuc21wLng4Ni5pNjg2LmNtb3Yvdm1saW51eCciCj4+IC91 c3Ivc2hhcmUvY29uYXJ5L2J1aWxkL3BhY2thZ2Vwb2xpY3kucHk6MTM5ODogYnVpbGQucGFja2Fn ZXBvbGljeS5kb0ZpbGUoc2VsZiwgcGF0aCkKICBQYXJhbXM6IAogICAgc2VsZiA9ICc8dW5wcmlu dGFibGUgb2YgY2xhc3MgYnVpbGQucGFja2FnZXBvbGljeS5GbGF2b3I+JwogICAgcGF0aCA9ICcv bGliL21vZHVsZXMvMi42LjEwLTIuc21wLng4Ni5pNjg2LmNtb3Yvdm1saW51eCcKICBMb2NhbHM6 IAogICAgZiA9ICc8ZmlsZXMuUi4uLjQwOWQwNWVjPicKICAgIGlzbnNldCA9ICIneDg2JyIKICAg IHBrZyA9ICJ7Jy9saWIvbS4uLmFjY2EyYz4pfSIKICAgIHBrZ01hcCA9ICJ7Jy9ib290L1N5c3Rl bS5tYXAtMi42LjEwLTIuc21wLng4Ni5pNjg2LmNtb3YnOiB7Jy9saWIvbS4uLmFjY2EyYz4pfSwg Jy9ib290L2NvbmZpZy0yLjYuMTAtMi5zbXAueDg2Lmk2ODYuY21vdic6IHsnL2xpYi9tLi4uYWNj YTJjPil9LCAnL2Jvb3Qvdm1saW51eC0yLjYuMTAtMi5zbXAueDg2Lmk2ODYuY21vdic6IHsnL2xp Yi9tLi4uYWNjYTJjPil9LCAnL2Jvb3Qvdm1saW51ei0yLjYuMTAtMi5zbXAueDg2Lmk2ODYuY21v dic6IHsnL2xpYi9tLi4uYWNjYTJjPil9LCAuLi59IgogICAgc2V0ID0gJzxkZXBzLmRlcHMuRGVw ZW5kZW5jeVNldCBpbnN0YW5jZSBhdCAweDQwOWE0NmFjPicKPj4gL3Vzci9zaGFyZS9jb25hcnkv YnVpbGQvdXNlLnB5OjY1NjogYnVpbGQudXNlLmNyZWF0ZUZsYXZvcihyZWNpcGVOYW1lKQogIFBh cmFtczogCiAgICByZWNpcGVOYW1lID0gTm9uZQogIExvY2FsczogCiAgICBhcmNoRmxhZ3MgPSAn e30nCiAgICBmbGFnID0gJ2Ntb3Y6IFRydWUnCiAgICBmbGFnSXRlcmFibGVzID0gJyg8Z2VuZXJh dC4uLjQwOWE0NThjPiwpJwogICAgZmxhZ1R5cGUgPSAiJzxDbGFzcyBidWlsZC51c2UuU3ViQXJj aD4nIgogICAgbWFqQXJjaCA9ICIneDg2JyIKICAgIHNldCA9ICc8ZGVwcy5kZXBzLkRlcGVuZGVu Y3lTZXQgaW5zdGFuY2UgYXQgMHg0MTU4YjVlYz4nCiAgICBzdWJzdW1lZCA9ICd7fScKICAgIHVz ZUZsYWdzID0gJ1tdJwo+PiAvdXNyL3NoYXJlL2NvbmFyeS9idWlsZC91c2UucHk6NTEzOiBidWls ZC51c2UuX3RvRGVwZW5kZW5jeShzZWxmKQogIFBhcmFtczogCiAgICBzZWxmID0gY21vdjogVHJ1 ZQogIExvY2FsczogCiAgICBkZXBGbGFncyA9ICJbKCdjbW92JywgMSldIgogICAgcGFyZW50ID0g J3g4NjogVHJ1Li4udDogRmFsc2V9JwogICAgc2Vuc2UgPSAnMScKICAgIHNldCA9ICc8ZGVwcy5k ZXBzLkRlcGVuZGVuY3lTZXQgaW5zdGFuY2UgYXQgMHg0MTQ5N2U0Yz4nCj4+IC91c3Ivc2hhcmUv Y29uYXJ5L2J1aWxkL3VzZS5weTo1MTM6IGJ1aWxkLnVzZS48Z2VuZXJhdG9yIGV4cHJlc3Npb24+ KFtvdXRtb3N0LWl0ZXJhYmxlXSkKICBQYXJhbXM6IAogICAgW291dG1vc3QtaXRlcmFibGVdID0g PGxpc3RpdGUuLi40MTQ5N2NlYz4KICBMb2NhbHM6IAogICAgcGFyZW50ID0gJ3g4NjogVHJ1Li4u dDogRmFsc2V9JwogICAgc2Vuc2UgPSAnMScKICAgIHggPSAiJyciCj4+IC91c3Ivc2hhcmUvY29u YXJ5L2J1aWxkL3VzZS5weToyMTM6IGJ1aWxkLnVzZS5fX2dldGl0ZW1fXyhzZWxmLCBrZXkpCiAg UGFyYW1zOiAKICAgIHNlbGYgPSB4ODY6IFRydS4uLnQ6IEZhbHNlfQogICAga2V5ID0gJycK ---MOQ11068304013de7c71da0b2da34ccd4aefe419280cd-- From johnsonm@lambchop.rdu.specifix.com Thu Jan 27 08:02:35 2005 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j0RD2YQv013029 for ; Thu, 27 Jan 2005 08:02:35 -0500 Received: from lambchop.rdu.specifix.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id F2384164DA for ; Thu, 27 Jan 2005 05:02:08 -0800 (PST) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j0RD27fb031078 for ; Thu, 27 Jan 2005 08:02:07 -0500 Received: (from johnsonm@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j0RD27CF031076 for conary-list@lists.specifix.com; Thu, 27 Jan 2005 08:02:07 -0500 Date: Thu, 27 Jan 2005 08:02:07 -0500 From: "Michael K. Johnson" To: conary-list@lists.specifix.com Message-ID: <20050127130207.GA31040@lambchop.rdu.specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Update to Conary technical overview X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 13:02:35 -0000 A new version of the technical overview, Repository-based System Management Using Conary, is available at: http://www.specifix.com/technology/techoverview/ or in PDF format at http://www.specifix.com/technology/techoverview.pdf Comments appreciated. Thanks! From david.christian@gmail.com Thu Jan 27 10:18:14 2005 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j0RFICQv013385 for ; Thu, 27 Jan 2005 10:18:13 -0500 Received: by wproxy.gmail.com with SMTP id 68so252805wra for ; Thu, 27 Jan 2005 07:17:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=V32fbB2t4IVC5/rEQu4eKCuRLRnHujQOjXltcVp4Bg6taVDlRYdO4QkLrUhylp7k5kkbmK/wWpGqohUqxBWW6LnqdUwGtvJey6o8dUNZAYe5krCJK//BE2W4Diq3E11yfCHjQs520j/TidzXmAASLRTrE49Y8BTjW5DOYx5CxpA= Received: by 10.54.53.17 with SMTP id b17mr52277wra; Thu, 27 Jan 2005 07:17:41 -0800 (PST) Received: by 10.54.57.60 with HTTP; Thu, 27 Jan 2005 07:17:41 -0800 (PST) Message-ID: <63940b00501270717682f6edc@mail.gmail.com> Date: Thu, 27 Jan 2005 10:17:41 -0500 From: David Christian To: Conary Discussion In-Reply-To: <1106830401.41f8e441c54ca@webmail.bizrace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1106830401.41f8e441c54ca@webmail.bizrace.com> Subject: Re: Shadow of kernel X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Christian , Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2005 15:18:14 -0000 hey ken, this bug will be fixed in the next release of conary, which will (as always) be pretty soon. David On Thu, 27 Jan 2005 07:53:21 -0500, Ken VanDine wrote: > > I have created a shadow of the kernel and patched it for inotify support. > Cooking it fails, here is the traceback. > > Any ideas? > > Thanks, > --Ken > > _______________________________________________ > conary-list mailing list > conary-list@lists.specifix.com > http://lists.specifix.com/mailman/listinfo/conary-list > > > > From ewt@specifix.com Mon Feb 14 08:32:21 2005 Received: from bradley.rdu.specifix.com (rdu-nat.specifix.com [24.172.59.42]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j1EDWKQv009858; Mon, 14 Feb 2005 08:32:20 -0500 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id j1C0b4ku004905; Fri, 11 Feb 2005 19:37:24 -0500 Received: from localhost (ewt@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) with ESMTP id j1C0b4Nh004902; Fri, 11 Feb 2005 19:37:04 -0500 X-Authentication-Warning: localhost.localdomain: ewt owned process doing -bs Date: Fri, 11 Feb 2005 19:37:04 -0500 (EST) From: Erik Troan X-X-Sender: ewt@localhost.localdomain To: conary-list@lists.specifix.com In-Reply-To: <200502112342.j1BNgwuY009742@lambchop.rdu.specifix.com> Message-ID: References: <200502112342.j1BNgwuY009742@lambchop.rdu.specifix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: synccvs@specifix.com, conary-commits@lists.specifix.com Subject: Re: conary/repository/netrepos fsrepos.py,1.97,1.98 X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 13:32:21 -0000 Never mind. I guess this was it. Erik On Fri, 11 Feb 2005, Matt Wilson wrote: > Update of /mnt/specifix/cvs/conary/repository/netrepos > In directory lambchop.rdu.specifix.com:/tmp/cvs-serv9730/netrepos > > Modified Files: > fsrepos.py > Log Message: > handle symlinks turning into config files > > > Index: fsrepos.py > =================================================================== > RCS file: /mnt/specifix/cvs/conary/repository/netrepos/fsrepos.py,v > retrieving revision 1.97 > retrieving revision 1.98 > diff -u -r1.97 -r1.98 > --- fsrepos.py 10 Feb 2005 21:59:43 -0000 1.97 > +++ fsrepos.py 11 Feb 2005 23:42:56 -0000 1.98 > @@ -305,7 +305,7 @@ > # to include in the local database > if (hash or (oldFile and newFile.flags.isConfig() > and not oldFile.flags.isConfig())): > - if oldFileVersion : > + if oldFileVersion and oldFile.hasContents: > oldCont = self.getFileContents( > [ (oldFileId, oldFileVersion, oldFile) ])[0] > > > _______________________________________________ > conary-commits mailing list > conary-commits@lists.specifix.com > http://lists.specifix.com/mailman/listinfo/conary-commits > From johnsonm@specifix.com Tue Feb 15 18:33:04 2005 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j1FNX4Qv016844; Tue, 15 Feb 2005 18:33:04 -0500 Received: from lambchop.rdu.specifix.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 1E15316A17; Tue, 15 Feb 2005 15:32:31 -0800 (PST) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j1FNWTfb009284; Tue, 15 Feb 2005 18:32:29 -0500 Received: (from johnsonm@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j1FNWT5B009282; Tue, 15 Feb 2005 18:32:29 -0500 Date: Tue, 15 Feb 2005 18:32:29 -0500 From: "Michael K. Johnson" To: distro-list@lists.specifix.com, conary-list@lists.specifix.com Message-ID: <20050215233228.GA9233@lambchop.rdu.specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Cc: Subject: The Great Renaming X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 23:33:04 -0000 We are in the process of instituting the new naming conventions described at http://wiki.specifix.com/ReleaseManagementStructure I suggest that you not try to build anything tonight (Tuesday night EST) until we have finished the conversion. When the conversion is finished, we will remove the warnings from the http://wiki.specifix.com/ConaryConversion page that warn you not to update yet. Summary of the renaming: @spx:linux becomes @spx:devel Thanks for your patience. From johnsonm@specifix.com Tue Feb 15 19:02:21 2005 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j1G02LQv016985; Tue, 15 Feb 2005 19:02:21 -0500 Received: from lambchop.rdu.specifix.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 31E4D16A17; Tue, 15 Feb 2005 16:01:48 -0800 (PST) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j1G01kfb010555; Tue, 15 Feb 2005 19:01:46 -0500 Received: (from johnsonm@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j1G01jri010553; Tue, 15 Feb 2005 19:01:45 -0500 Date: Tue, 15 Feb 2005 19:01:45 -0500 From: "Michael K. Johnson" To: distro-list@lists.specifix.com, conary-list@lists.specifix.com Message-ID: <20050216000145.GA10530@lambchop.rdu.specifix.com> References: <20050215233228.GA9233@lambchop.rdu.specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050215233228.GA9233@lambchop.rdu.specifix.com> User-Agent: Mutt/1.4.1i Cc: Subject: Re: The Great Renaming X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2005 00:02:21 -0000 On Tue, Feb 15, 2005 at 06:32:29PM -0500, Michael K. Johnson wrote: > When the conversion is finished, we will remove the warnings from the > http://wiki.specifix.com/ConaryConversion page that warn you > not to update yet. That went more quickly than I anticipated. Please feel free to update now. From ken@bizrace.com Mon Mar 7 06:53:41 2005 Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j27BrfQv031760 for ; Mon, 7 Mar 2005 06:53:41 -0500 Received: from [192.168.0.94] (cpe-069-133-144-145.nc.rr.com [69.133.144.145]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j27BrMCh010228; Mon, 7 Mar 2005 06:53:25 -0500 (EST) From: Ken VanDine To: Conary Discussion Content-Type: multipart/mixed; boundary="=-l8SNoek6UlhBzKCWovpa" Date: Mon, 07 Mar 2005 06:53:15 -0500 Message-Id: <1110196396.10711.6.camel@vision> Mime-Version: 1.0 X-Mailer: Evolution 2.1.6 X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: capnkirby@netscape.net Subject: [Fwd: Re: [Foresight Linux] Conary Error] X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 11:53:41 -0000 --=-l8SNoek6UlhBzKCWovpa Content-Type: text/plain Content-Transfer-Encoding: 7bit I am forwarding this thread from the foresight list. Conary finds no troves in the foresight repo, but finds things in the specifix repos. The only thing I can think of is flavors, however looking at his buildFlavor things look ok. However, I am not sure if the label "rq" looks for is the same as the buildFlavor. What would be a good next step in debugging? Thanks, --Ken --=-l8SNoek6UlhBzKCWovpa Content-Disposition: inline Content-Description: Forwarded message - Re: [Foresight Linux] Conary Error Content-Type: message/rfc822 Return-Path: Received: from mail.bizrace.com ([unix socket]) by mail.bizrace.com (Cyrus v2.1.9) with LMTP; Sun, 06 Mar 2005 21:10:31 -0500 X-Sieve: CMU Sieve 2.2 Received: by mail.bizrace.com (Postfix, from userid 33346) id 8CA185F5EE; Sun, 6 Mar 2005 21:10:31 -0500 (EST) Received: from web1.bizrace.com (localhost.localdomain [127.0.0.1]) by mail.bizrace.com (Postfix) with ESMTP id 6AEB15F584; Sun, 6 Mar 2005 21:10:03 -0500 (EST) Delivered-To: desktop-distro@bizrace.com Received: by mail.bizrace.com (Postfix, from userid 33346) id 379795F5EE; Sun, 6 Mar 2005 21:09:36 -0500 (EST) Received: from imo-d02.mx.aol.com (imo-d02.mx.aol.com [205.188.157.34]) by mail.bizrace.com (Postfix) with ESMTP id 828385F574 for ; Sun, 6 Mar 2005 21:09:16 -0500 (EST) Received: from capnkirby@netscape.net by imo-d02.mx.aol.com (mail_out_v37_r3.8.) id 5.e9.10b34dc7 (22682) for ; Sun, 6 Mar 2005 21:09:13 -0500 (EST) Received: from netscape.net (mow-d26.webmail.aol.com [205.188.139.167]) by air-in04.mx.aol.com (v104.18) with ESMTP id MAILININ43-589a422bb7c9ba; Sun, 06 Mar 2005 21:09:13 -0500 From: capnkirby@netscape.net To: desktop-distro@bizrace.com Subject: Re: [Foresight Linux] Conary Error MIME-Version: 1.0 Message-ID: <2D619CB8.6C3AE779.02E2F0CB@netscape.net> X-Mailer: Atlas Mailer 2.0 X-AOL-IP: 69.128.240.197 X-AOL-Language: english Content-Type: text/plain; charset=iso-8859-1 X-AOL-Test: Testing Sender: desktop-distro-admin@bizrace.com Errors-To: desktop-distro-admin@bizrace.com X-BeenThere: desktop-distro@bizrace.com X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: desktop-distro@bizrace.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sun, 06 Mar 2005 21:09:13 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on web1.bizrace.com X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_50,NO_REAL_NAME, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.0.1 X-Spam-Level: * Content-Transfer-Encoding: 7bit I had originally installed 0.3 on Friday March 4th and had the same issues, seeing that 0.4 was released I downloaded and installed that from scratch, allowing the installer to rewrite everything, including re-creating the partitions, I did this Saturday evening and have been working it over since. Here are the outputs you requested: [root@localhost capnkirby]# conary config archDir /etc/conary/arch autoResolve True buildFlavor ~X,~!alternatives,!bootstrap,~builddocs, ~buildtests,~desktop,~dietlibc,~emacs, ~gcj,~!gd,~gdbm,~!gnat,~gnome,~gtk,~ipv6, ~kde,~krb,~ldap,~!netpbm,~nptl,pam,~pcre, ~perl,~!pie,~python,~qt,~readline,~!sasl, ~!selinux,~!slang,ssl,~tcl,tcpwrappers, ~tk,~!xfce is: x86(~3dnow,~3dnowext, ~cmov,~i486,~i586,~i686,~mmx,~mmxext, ~sse) buildLabel localhost@local:trunk buildPath /usr/src/conary/builds contact None dbPath /var/lib/conarydb debugRecipeExceptions False dumpStackOnError True excludeTroves flavor ~X,~!alternatives,!bootstrap,~builddocs, ~buildtests,~desktop,~dietlibc,~emacs, ~gcj,~!gd,~gdbm,~!gnat,~gnome,~gtk,~ipv6, ~kde,~krb,~ldap,~!netpbm,~nptl,pam,~pcre, ~perl,~!pie,~python,~qt,~readline,~!sasl, ~!selinux,~!slang,ssl,~tcl,tcpwrappers, ~tk,~!xfce is: x86(~3dnow,~3dnowext, ~cmov,~i486,~i586,~i686,~mmx,~mmxext, ~sse) installLabelPath conary.foresightlinux.com@fl:desktop conary.specifix.com@spx:devel contrib.specifix.com@spx:devel lookaside /var/cache/conary name None root / sourceSearchDir . tmpDir /var/tmp/ useDir /etc/conary/use [root@localhost capnkirby]# conary --version 0.50.2 Ken VanDine wrote: >OK, we are getting somewhere. I need a little more info. Send me the >output of these commands: > >conary config >conary --version > >Also, what version of Foresight did you install, 0.4? > >Thanks, >--Ken > >On Sun, 2005-03-06 at 20:46 -0500, capnkirby@netscape.net wrote: >> You are right that the space is a copy and paste error, here are the q ueries you requested: >> >> [root@localhost capnkirby]# conary rq xorg-x11 >> xorg-x11 6.8.2-1-1 >> [root@localhost capnkirby]# conary rq gaim >> gaim 1.1.4-1-1 >> [root@localhost capnkirby]# conary rq gnome-session >> gnome-session 2.8.0-2-1 >> [root@localhost capnkirby]# conary rq gxmessage >> error: No versions with labels "conary.foresightlinux.com@fl:desktop conary.specifix.com@spx:devel contrib.specifix.com@spx:devel" for "gxmessage" were found in the repository. >> >> >> Capn >> >> Ken VanDine wrote: >> >> >I have no idea... that is wierd. I am assuming the space in >> >conary.specifix.com@spx:devel is a product of copy and paste. For what >> >it's worth, you have the newest version.... however it should still find >> >the version in the repository. Can you try some other random queries >> >and email the results? Try these: >> > >> >conary rq xorg-x11 >> >conary rq gaim >> >conary rq gnome-session >> >conary rq gxmessage >> > >> >Two of those will come from the specifix repos, one is a shadow in the >> >foresight repo and one is a package that only lives in the foresight >> >repo. Please send the output of all of those, should help debugging. >> > >> >Thanks, >> >--Ken >> > >> >On Sun, 2005-03-06 at 20:04 -0500, capnkirby@netscape.net wrote: >> >> Here you are: >> >> >> >> [root@localhost capnkirby]# conary q beagle >> >> beagle 0.0.7-1-1 >> >> >> >> [root@localhost capnkirby]# conary rq beagle >> >> error: No versions with labels "conary.foresightlinux.com@fl:desktop conary.spec ifix.com@spx:devel contrib.specifix.com@spx:devel" for "beagle" were found in th e repository. >> >> >> >> >> >> >> >> >> >> Ken VanDine wrote: >> >> >> >> >Welcome! >> >> > >> >> >Can you please send the output of this: >> >> > >> >> >conary q beagle >> >> >conary rq beagle >> >> > >> >> >Thanks, >> >> >--Ken >> >> > >> >> >On Sun, 2005-03-06 at 17:44 -0500, capnkirby@netscape.net wrote: >> >> >> Hello all, >> >> >> New to Foresight, and am liking what I see, however when starting up Conary GUI I am getting the following error: >> >> >> >> >> >> Operation failed: >> >> >> >> >> >> Traceback (most recent call last): >> >> >> File "/usr/share/conary-gui/conaryinterface.py", line 82, in run >> >> >> retval = self.doOperation() >> >> >> File "/usr/share/conary-gui/conaryinterface.py", line 208, in doOperation >> >> >> repoVersions = versionList[pkg] >> >> >> KeyError: 'GConf' >> >> >> >> >> >> I am also not able to update via command line either as it is saying: >> >> >> >> >> >> beagle 0.0.7-1-1 /conary.foresightlinux.com@fl:desktop >> >> >> warning: Could not write extended traceback: 'Branch' object has no attribute 'isAfter' >> >> >> Traceback (most recent call last): >> >> >> File "/usr/bin/yuck", line 282, in ? >> >> >> sys.exit(main(sys.argv)) >> >> >> File "/usr/bin/yuck", line 234, in main >> >> >> updatecmd.doUpdate(cfg, [ "%s=%s[%s]" %(pkg, v.asString(), f) ]) >> >> >> AttributeError: 'NoneType' object has no attribute 'asString' >> >> >> > /usr/bin/yuck(234)main() >> >> >> -> updatecmd.doUpdate(cfg, [ "%s=%s[%s]" %(pkg, v.asString(), f) ]) >> >> >> (Epdb) >> >> >> >> >> >> Any suggestions? >> >> >> >> >> >> Thanks, >> >> >> Capn >> >> >> >> >> >> __________________________________________________________________ >> >> >> Switch to Netscape Internet Service. >> >> >> As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register >> >> >> >> >> >> Netscape. Just the Net You Need. >> >> >> >> >> >> New! Netscape Toolbar for Internet Explorer >> >> >> Search from anywhere on the Web and block those annoying pop-ups. >> >> >> Download now at http://channels.netscape.com/ns/search/install.jsp >> >> >> _______________________________________________ >> >> >> Desktop-distro mailing list >> >> >> Desktop-distro@bizrace.com >> >> >> http://lists.bizrace.com/mailman/listinfo/desktop-distro >> >> >> >> >> > >> >> >_______________________________________________ >> >> >Desktop-distro mailing list >> >> >Desktop-distro@bizrace.com >> >> >http://lists.bizrace.com/mailman/listinfo/desktop-distro >> >> > >> >> >> >> __________________________________________________________________ >> >> Switch to Netscape Internet Service. >> >> As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register >> >> >> >> Netscape. Just the Net You Need. >> >> >> >> New! Netscape Toolbar for Internet Explorer >> >> Search from anywhere on the Web and block those annoying pop-ups. >> >> Download now at http://channels.netscape.com/ns/search/install.jsp >> >> _______________________________________________ >> >> Desktop-distro mailing list >> >> Desktop-distro@bizrace.com >> >> http://lists.bizrace.com/mailman/listinfo/desktop-distro >> >> >> > >> >_______________________________________________ >> >Desktop-distro mailing list >> >Desktop-distro@bizrace.com >> >http://lists.bizrace.com/mailman/listinfo/desktop-distro >> > >> >> __________________________________________________________________ >> Switch to Netscape Internet Service. >> As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register >> >> Netscape. Just the Net You Need. >> >> New! Netscape Toolbar for Internet Explorer >> Search from anywhere on the Web and block those annoying pop-ups. >> Download now at http://channels.netscape.com/ns/search/install.jsp >> _______________________________________________ >> Desktop-distro mailing list >> Desktop-distro@bizrace.com >> http://lists.bizrace.com/mailman/listinfo/desktop-distro >> > >_______________________________________________ >Desktop-distro mailing list >Desktop-distro@bizrace.com >http://lists.bizrace.com/mailman/listinfo/desktop-distro > __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp _______________________________________________ Desktop-distro mailing list Desktop-distro@bizrace.com http://lists.bizrace.com/mailman/listinfo/desktop-distro --=-l8SNoek6UlhBzKCWovpa-- From pedro@neuroomante.com Fri Mar 25 09:30:01 2005 Received: from flute.neuroomante.com (109.Red-80-33-144.pooles.rima-tde.net [80.33.144.109]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j2PETZQx015257 for ; Fri, 25 Mar 2005 09:30:01 -0500 Received: from localhost (localhost [::ffff:127.0.0.1]) (IDENT: pedro) by flute.neuroomante.com with esmtp; Fri, 25 Mar 2005 14:28:48 +0000 id 00000F0A.42442020.0000012C From: Pedro Gracia To: conary-list@lists.specifix.com Date: Fri, 25 Mar 2005 14:28:47 +0000 Message-Id: <1111760927.32622.1.camel@flute> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution 2.0.4 X-Mailman-Approved-At: Fri, 25 Mar 2005 09:40:41 -0500 Subject: Proposal: screenshot or preview metadata for packages with GUI or eye candy X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2005 14:30:01 -0000 Like conary and conary-gui have the same parent (specifix) could be a good thing for an user to see a preview image of the aplication before he performs the installation. It could be a string with a reference to a image (png, jpg, etc.) in the package. I don't know yet how work conary list of package and the metadata that is stored locally, but this image could be download on the fly (if the user has internet) or it could stay in hard disk... This screenshot or preview metadata only will be used by packages with GUI and it could be used by conary-gui. I don't know a distro with this feature. Is it a silly proposal? Cheers, Pedro From pedro@neuroomante.com Fri Mar 25 10:22:56 2005 Received: from flute.neuroomante.com (109.Red-80-33-144.pooles.rima-tde.net [80.33.144.109]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j2PFMtQv015442 for ; Fri, 25 Mar 2005 10:22:55 -0500 Received: from localhost (localhost [::ffff:127.0.0.1]) (IDENT: pedro) by flute.neuroomante.com with esmtp; Fri, 25 Mar 2005 15:21:41 +0000 id 00000F0A.42442C85.00000836 From: Pedro Gracia To: conary-list@lists.specifix.com In-Reply-To: <1111760927.32622.1.camel@flute> References: <1111760927.32622.1.camel@flute> Content-Type: text/plain; charset=ISO-8859-15 Organization: Neuroomante S.L. Date: Fri, 25 Mar 2005 15:21:40 +0000 Message-Id: <1111764100.32622.3.camel@flute> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 8bit Subject: Re: Proposal: screenshot or preview metadata for packages with GUI or eye candy X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2005 15:22:56 -0000 I missed this: gnomefiles have a link with screenshots already! El vie, 25-03-2005 a las 14:28 +0000, Pedro Gracia escribió: > Like conary and conary-gui have the same parent (specifix) could be a > good thing for an user to see a preview image of the aplication before > he performs the installation. > > It could be a string with a reference to a image (png, jpg, etc.) in the > package. I don't know yet how work conary list of package and the > metadata that is stored locally, but this image could be download on the > fly (if the user has internet) or it could stay in hard disk... > > This screenshot or preview metadata only will be used by packages with > GUI and it could be used by conary-gui. I don't know a distro with this > feature. > > Is it a silly proposal? > > Cheers, > > Pedro From johnsonm@specifix.com Sun Mar 27 14:08:53 2005 Received: from bluesmobile.specifixinc.com (w098.z064220152.sjc-ca.dsl.cnc.net [64.220.152.98]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j2RJ8qQv003307 for ; Sun, 27 Mar 2005 14:08:52 -0500 Received: from lambchop.rdu.specifix.com (lambchop.rdu.specifix.com [172.16.58.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 45C94169BB for ; Sun, 27 Mar 2005 11:08:39 -0800 (PST) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j2RJ8cfb019379 for ; Sun, 27 Mar 2005 14:08:38 -0500 Received: (from johnsonm@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j2RJ8bGf019377 for conary-list@lists.specifix.com; Sun, 27 Mar 2005 14:08:37 -0500 Date: Sun, 27 Mar 2005 14:08:37 -0500 From: "Michael K. Johnson" To: Conary Discussion Message-ID: <20050327190837.GA19297@lambchop.rdu.specifix.com> References: <1111760927.32622.1.camel@flute> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1111760927.32622.1.camel@flute> User-Agent: Mutt/1.4.1i Subject: Re: Proposal: screenshot or preview metadata for packages with GUI or eye candy X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2005 19:08:53 -0000 On Fri, Mar 25, 2005 at 02:28:47PM +0000, Pedro Gracia wrote: > It could be a string with a reference to a image (png, jpg, etc.) in the > package. I don't know yet how work conary list of package and the > metadata that is stored locally, but this image could be download on the > fly (if the user has internet) or it could stay in hard disk... I'd suggest that since we already have freshmeat links for most projects, linking there, where there are screenshots stored for any project that wants, is best -- the tool could potentially grab them that way. Whether that's a good idea is another question -- I'd think that telling the browser to look at the FM project would probably be more productive. From johnsonm@specifix.com Mon May 16 17:48:49 2005 Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by lists.specifix.com (8.12.10/8.12.10) with ESMTP id j4GLmmEa009738; Mon, 16 May 2005 17:48:49 -0400 Received: from lambchop.rdu.specifix.com (rdu-nat.rpath.com [24.172.59.42]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j4GLmELv026695; Mon, 16 May 2005 17:48:14 -0400 (EDT) Received: from lambchop.rdu.specifix.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.specifix.com (8.12.10/8.12.10) with ESMTP id j4GLj4bg015985; Mon, 16 May 2005 17:45:04 -0400 Received: (from johnsonm@localhost) by lambchop.rdu.specifix.com (8.12.10/8.12.10/Submit) id j4GLj47f015984; Mon, 16 May 2005 17:45:04 -0400 Date: Mon, 16 May 2005 17:45:04 -0400 From: "Michael K. Johnson" To: distro-list@lists.rpath.com, conary-list@lists.rpath.com Message-ID: <20050516214503.GA15957@lambchop.rdu.specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Subject: Lists transitioning domain soon X-BeenThere: conary-list@lists.specifix.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Conary Discussion List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 21:48:49 -0000 These lists, plus the commits lists (conary-commits, conary-gui-commits, conary-repository-commits, contrib-commits, and distro-commits) will be transitioning to the rpath.com domain soon. Please update your sorting filters for all these lists to understand lists.rpath.com as well as lists.specifix.com so that you are ready for the transition! Thanks From tansuwa@gmail.com Sat May 28 13:11:44 2005 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by lists.rpath.com (8.12.10/8.12.10) with ESMTP id j4SHBi1e019214 for ; Sat, 28 May 2005 13:11:44 -0400 Received: by wproxy.gmail.com with SMTP id 36so3001340wra for ; Sat, 28 May 2005 10:11:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=e+Db5cEqFFQp21MG6V2xqd/7g1ozxR3Pvj6jAAN04QkD0HIUtSkKiFA7O9ill7FPLUC+VGGxTouiH21XwvFLOXWJGUfTXl62F8zt2Id1jKi5+47zsC1qqYY/3ICZ48EBasTFziMmWJSXFz30FFevj2If9lcUpjN68Wi/AKomHkk= Received: by 10.54.8.41 with SMTP id 41mr3567260wrh; Sat, 28 May 2005 10:11:07 -0700 (PDT) Received: by 10.54.128.1 with HTTP; Sat, 28 May 2005 10:11:07 -0700 (PDT) Message-ID: Date: Sun, 29 May 2005 01:11:07 +0800 From: Suwanto Tan To: conary-list@lists.rpath.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6124_13676336.1117300267031" Subject: How can I use Conary from the start when I build Linux From Scratch (LFS+BLFS)? X-BeenThere: conary-list@lists.rpath.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: conary-list@lists.rpath.com, Suwanto Tan List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 17:11:44 -0000 ------=_Part_6124_13676336.1117300267031 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear Members, Linux From Scratch/Beyond Linux From Scratch does not have any package=20 management. Can I use Conary as the package manager? Or specificaly, how do I start to use Conary as package manager? Maybe, I= =20 need to start with setting up CVS/SVN and populating it with source codes o= f=20 kernels, binutils, glibc, gcc, etc? I am sorry if this has been described in the manua somewhere. But I have=20 read the documentation on the Conary FrontPage but it explains about the=20 conary but not on how to use it for a linux distro package management. Someone has experience? Or someone from Foresight Linux can share a little= =20 bit on the process? Regards, Suwanto ------=_Part_6124_13676336.1117300267031 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear Members,

Linux From Scratch/Beyond Linux From Scratch does not have any package mana= gement. Can I use Conary as the package manager?

Or specificaly, how do I start to use Conary as package manager? Maybe, I need to start with setting up CVS/SVN and populating it with source codes of kernels, binutils, glibc, gcc, etc?

I am sorry if this has been described in the manua somewhere. But I have read the documentation on the Conary FrontPage but it explains about the conary but not on how to use it for a linux distro package management.

Someone has experience? Or someone from Foresight Linux can share a little = bit on the process?

Regards,
Suwanto
------=_Part_6124_13676336.1117300267031-- From tansuwa@gmail.com Mon May 30 23:09:11 2005 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by lists.rpath.com (8.12.10/8.12.10) with ESMTP id j4V39B1e003416 for ; Mon, 30 May 2005 23:09:11 -0400 Received: by wproxy.gmail.com with SMTP id 36so3938128wra for ; Mon, 30 May 2005 20:08:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=RPbxEnPbw3dV8hs+UV0cRwtLjPsa3qQg5qeFYz7z4q/7//QVcBgQEyVrGY6BICCUKmSiiW0dJlw6LvfruKSSFZF7j1QK+IZa17GRy+PjLHc7X/SzjUX2GKC4yqBirnAM4iBMa8Y5yadBRdNbAVJ/jwcaadgmaIH3i/b4ZG3vTlk= Received: by 10.54.8.41 with SMTP id 41mr6114222wrh; Mon, 30 May 2005 20:08:33 -0700 (PDT) Received: by 10.54.128.1 with HTTP; Mon, 30 May 2005 20:08:32 -0700 (PDT) Message-ID: Date: Tue, 31 May 2005 11:08:33 +0800 From: Suwanto Tan To: conary-list@lists.rpath.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.rpath.com id j4V39B1e003416 Subject: Is the source tarballs linked in the recipe stored in Conary repo? X-BeenThere: conary-list@lists.rpath.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: conary-list@lists.rpath.com, Suwanto Tan List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 03:09:11 -0000 Hi, I saw that the conary recipe only stores the URL of the source tarballs. If I make a local patch, i can put the patch on local (current) directory and put the patch together with the source tarballs in the recipe, can't I? Do I need to put this patch in the conary repo? How can put anything in conary repo? The documentation at conary frontpage explains well about the concept but I think it lacks details such as exact commands to be used or examples and/or tutorials. Where can I find those details? If there isn't any. I would like to know how to track the source in conary repo. Do I need to untar the source tarballs and upload them into the repo? Thanks. Suwanto From tansuwa@gmail.com Mon May 30 23:13:17 2005 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by lists.rpath.com (8.12.10/8.12.10) with ESMTP id j4V3DG1e003440 for ; Mon, 30 May 2005 23:13:16 -0400 Received: by wproxy.gmail.com with SMTP id 36so3939550wra for ; Mon, 30 May 2005 20:12:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=GTJ5kZFfjZK7+PeXLlD90js4WyXdQhrhICTqYLzGQF9cKYWe5L3C4DBg1USh+0gEGQzVR298tHt/CttkwGVXuRCrHS0DEL1SvmBXoiAIVDWRQUaueZGNKaEwSQtUiQnXAHUijVKvc41TCcytry6pyQ5rTerL9shGvqJSuUVkcSI= Received: by 10.54.53.44 with SMTP id b44mr3798947wra; Mon, 30 May 2005 20:12:38 -0700 (PDT) Received: by 10.54.128.1 with HTTP; Mon, 30 May 2005 20:12:38 -0700 (PDT) Message-ID: Date: Tue, 31 May 2005 11:12:38 +0800 From: Suwanto Tan To: conary-list@lists.rpath.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.rpath.com id j4V3DG1e003440 Subject: Where can I find conary recipes and download them? X-BeenThere: conary-list@lists.rpath.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: conary-list@lists.rpath.com, Suwanto Tan List-Id: Conary Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 03:13:17 -0000 Hi, I would like to learn conary. And I would like to see how the existing recipes are written. I always like to learn through examples and through trying it out. Is it through conary GUI to download the recipe files? Or is there a ftp/http site to download them? Thanks, Suwanto From msw@rpath.com Mon May 30 23:47:46 2005 Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100] (may be forged)) by lists.rpath.com (8.12.10/8.12.10) with ESMTP id j4V3lk1e003680 for ; Mon, 30 May 2005 23:47:46 -0400 Received: from lambchop.rdu.rpath.com (rdu-nat.rpath.com [24.172.59.42]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j4V3l4Lv005391; Mon, 30 May 2005 23:47:04 -0400 (EDT) Received: from lambchop.rdu.rpath.com (localhost.localdomain [127.0.0.1]) by lambchop.rdu.rpath.com (8.12.10/8.12.10) with ESMTP id j4V3kPS1001455; Mon, 30 May 2005 23:46:25 -0400 Received: (from msw@localhost) by lambchop.rdu.rpath.com (8.12.10/8.12.10/Submit) id j4V3kPji001454; Mon, 30 May 2005 23:46:25 -0400 Date: Mon, 30 May 2005 23:46:20 -0400 From: Matt Wilson To: conary-list@lists.rpath.com, Suwanto Tan Message-ID: <20050531034620.GA1336@rpath.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Subject: Re: Is the source tarballs linked in the recipe stored in Conary repo? X-BeenThere: conary-list@lists.rpath.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: conary-list@lists.rpath.com List-Id: Conary Discussion List-Unsubscribe: ,