From bwalton at opencsw.org Sat Jan 1 02:12:49 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 31 Dec 2010 20:12:49 -0500 Subject: [csw-maintainers] addition to CSWcommon? In-Reply-To: References: <1292432556-sup-8979@pinkfloyd.chass.utoronto.ca> <1293825402-sup-4747@pinkfloyd.chass.utoronto.ca> Message-ID: <1293844296-sup-6199@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Dec 31 16:06:19 -0500 2010: > This is a good point. The only worry is that the created directory > might conflict with other existing directories. This problem is not > specific to this issue, I just would like checkpkg to give a sane > suggestion that does not result in one package creating the > directory as root:bin and another as, say, root:lp. Might this be a better thing for checkpkg to throw a warning/error about then? I'd consider this to be at least as bad as not providing the directory. I'm not positive, but I suspect the new whole-catalog file index that checkpkg is using might make this doable/easy too...? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sat Jan 1 03:39:10 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 31 Dec 2010 18:39:10 -0800 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: Message-ID: On Fri, Dec 31, 2010 at 12:26 PM, Maciej (Matchek) Blizinski wrote: > > Let's hear from other maintainers too: what markup language would you > like us to use and why? What; something I already know and will be applicable: html(a very specific, "blessed" subset) or wiki markup Why: Because it makes putting it online trivial, AND eliminates needlessly having to learn Yet Another Language. html(4) would have the additional benefit that it is "immediately" readable, both online, and in a file. Zero translations needed; what people read is directly the definitive document. "{links/lynx/elinks/emacs/xxx} specdoc.html" Just limit allowable markups to something like B,U,H(1234), HR, BLOCKQUOTE, HREF, A and we're all set. From maciej at opencsw.org Sat Jan 1 10:45:50 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 1 Jan 2011 09:45:50 +0000 Subject: [csw-maintainers] addition to CSWcommon? In-Reply-To: <1293844296-sup-6199@pinkfloyd.chass.utoronto.ca> References: <1292432556-sup-8979@pinkfloyd.chass.utoronto.ca> <1293825402-sup-4747@pinkfloyd.chass.utoronto.ca> <1293844296-sup-6199@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 1 de Janeiro de 2011 01:12, Ben Walton escreveu: > Excerpts from Maciej (Matchek) Blizinski's message of Fri Dec 31 16:06:19 -0500 2010: > >> This is a good point. ?The only worry is that the created directory >> might conflict with other existing directories. ?This problem is not >> specific to this issue, I just would like checkpkg to give a sane >> suggestion that does not result in one package creating the >> directory as root:bin and another as, say, root:lp. > > Might this be a better thing for checkpkg to throw a warning/error > about then? ?I'd consider this to be at least as bad as not providing > the directory. ?I'm not positive, but I suspect the new whole-catalog > file index that checkpkg is using might make this doable/easy too...? It would require some time to implement. Checkpkg stores complete package information in pickled form, in a single mysql table. (This effectively uses MySQL as a key-value store.) Some information is also represented in other mysql tables, but they don't contain much detail. The idea is that some operations require checking the contents of the whole catalog, and you don't want to unpickle 2500 objects on every checkpkg run. Instead, we rely on MySQL indexes. If we want to query the whole catalog for file ownership and permissions, it has to be represented in the database. I'll have to add more columns to the csw_file table. They currently are: basename = sqlobject.UnicodeCol(length=255, notNone=True) path = sqlobject.UnicodeCol(notNone=True, length=900) line = sqlobject.UnicodeCol(notNone=True, length=900) pkginst = sqlobject.ForeignKey('Pkginst', notNone=True) srv4_file = sqlobject.ForeignKey('Srv4FileStats') I'll need to add the user, group and mode. While I'm at it, I'll see if I can add the mimetype too. From pfelecan at opencsw.org Sat Jan 1 12:05:03 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jan 2011 12:05:03 +0100 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: <1293828092-sup-7991@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Fri, 31 Dec 2010 15:43:58 -0500") References: <1293828092-sup-7991@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Maciej (Matchek) Blizinski's message of Fri Dec 31 15:32:08 -0500 2010: > >> mouth when talking in private. Another issue: having public >> archives of policy discussions might be important for newcomers, who >> might want to read discussions behind policy decisions. Otherwise >> you might see the same questions raised over and over again, or you >> would have to document all of them. > > Agreed. +1 for public discussion of policy. There is no need to keep > this behind closed doors. If the 'public' cares enough about a > specific issue being discussed, it might even encourage audience > participation, which wouldn't be bad, I don't think...we often wonder > what the users are doing, so if we have a chance to hear from them > about things we're planning that will affect them, this is a good > thing! The policies has the maintainers as the sole public. If somebody is interested by these discussion s/he can subscribe. The user is a fallacious public brought up only when cornered. Why do you think that Debian, among others, has private discussion lists? >> I'd say that creating the new mailing list should happen when we >> notice concrete problems with existing discussions and agree that a >> private list would solve them. > > Also agreed. If the policy specific volume on maintainers@ becomes a > significant proportion, we could split it out at a later time. I'm worried by the noise that can drown directly or indirectly policy discussion as happened so many time in the past. -- Peter From pfelecan at opencsw.org Sat Jan 1 12:10:06 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jan 2011 12:10:06 +0100 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: <1293828566-sup-7900@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Fri, 31 Dec 2010 15:54:42 -0500") References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293828566-sup-7900@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Maciej (Matchek) Blizinski's message of Fri Dec 31 15:44:56 -0500 2010: > >> Swinging Ockham's razor, I'd think twice before I created any new >> source repositories. I'm already tempted to create new repositories >> (for gar, for checkpkg), but I've been curbing these temptations. Why do you resisted the temptation? > Well, I'd like to keep things containerized if possible. We already > have quite the mingling of different things in the primary svn repo > (gar, checkpkg, build recipes, sources for a few simple packages, > etc). IMO, each of the above should be a separate repo, but I > understand why they're not. > > The policy documentation will be a large enough entity that it > deserves it's own place to live, imo. > >> If we decide that we need a new source repository, it will probably >> be git, unless there's a specific reason to use another VCS. If you >> create a new VCS, you need to make sure that it'll be reliable, >> access-controlled, backed up and integrated with the rest of our >> infrastructure. I agree that having separate repositories for separate projects is a good thing (just look at the size of the actual gar). However, having many VCS types is a PITA. If we started with subversion why change to git? Slowly all this will became a bazaar. > We're using sourceforge for svn and relying on their backup. We could > do similar with one of github or gitorious (I use both already for a > few things). Also, with a distributed VCS, each checkout is a > backup...although there is potential to lose a few commits if a local > copy is lost before sharing the changes. Is there a reason for which we cannot host our own repositories? Especially if we use only one VCS and afferent tools. -- Peter From pfelecan at opencsw.org Sat Jan 1 12:13:21 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jan 2011 12:13:21 +0100 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Fri, 31 Dec 2010 14:53:29 -0500") References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Peter FELECAN's message of Fri Dec 31 06:20:24 -0500 2010: > >> IMO, LaTeX is less about backslashes than document format and good >> typography. Other than using macros you don't need a lot of special >> characters... > > We converted our documentation at work from texinfo to docbook as > people didn't like the idiosyncrasies of texinfo (not strictly LaTex, > of course). Emacs makes editting the xml easy as it does most of the > work and I'm sure vim offers similar functionality. > > I'd vote for docbook or asciidoc. (I won't argue that LaTex produces > nicer output though. :)) Docbook or even html as proposed by Phil is still SGML. Even with the highly configurable Emacs it's a real PITA. Consequently, my vote goes for asciidoc. -- Peter From pfelecan at opencsw.org Sat Jan 1 12:18:00 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jan 2011 12:18:00 +0100 Subject: [csw-maintainers] Package naming policy In-Reply-To: <1293823722-sup-4143@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Fri, 31 Dec 2010 14:32:15 -0500") References: <2D1CA123-FB16-40DA-9C56-8D63F7CA5C26@opencsw.org> <1D90E8CF-7212-4CD5-837A-9581F0972714@opencsw.org> <1293823722-sup-4143@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > I'd prefer to standardize on the short -dev and _dev if we can for the > reasons that you noted. Just a slight note: the -dev is not adequate as it serves as field separator in catalog component parsing. If I'm wrong please correct me. -- Peter From maciej at opencsw.org Sat Jan 1 13:43:25 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 1 Jan 2011 12:43:25 +0000 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293828092-sup-7991@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 1 de Janeiro de 2011 11:05, Peter FELECAN escreveu: > The policies has the maintainers as the sole public. If somebody is > interested by these discussion s/he can subscribe. Would it mean that once I'm subscribed, I can read all the archives? We don't have that at the moment, AFAIK. > The user is a > fallacious public brought up only when cornered. > > Why do you think that Debian, among others, has private discussion lists? > >>> I'd say that creating the new mailing list should happen when we >>> notice concrete problems with existing discussions and agree that a >>> private list would solve them. >> >> Also agreed. ?If the policy specific volume on maintainers@ becomes a >> significant proportion, we could split it out at a later time. > > I'm worried by the noise that can drown directly or indirectly policy > discussion as happened so many time in the past. When you worry about noise, do you mean noise in the policy-related thread or in other threads? If it's about other threads, using an e-mail client which supports threads solves that problem. If you worry about noise in the same thread, you're facing a social / behavioral problem, and technical means are not likely to solve it. If there's a person making distracting comments in the thread, the right response is to talk to them and make them behave better. I'm not saying that there is no place for private discussions, but I'm not convinced that it makes sense to have a private one for policy related discussions. Policy decisions affect the largest group of people: maintainers and users. It's important that all affected parties have read access to these discussions, much the same way in which the public has access to the parliament debates, both live on TV and later on in transcripts. From maciej at opencsw.org Sat Jan 1 14:23:36 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 1 Jan 2011 13:23:36 +0000 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293828566-sup-7900@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 1 de Janeiro de 2011 11:10, Peter FELECAN escreveu: > Ben Walton writes: > >> Excerpts from Maciej (Matchek) Blizinski's message of Fri Dec 31 15:44:56 -0500 2010: >> >>> Swinging Ockham's razor, I'd think twice before I created any new >>> source repositories. ?I'm already tempted to create new repositories >>> (for gar, for checkpkg), but I've been curbing these temptations. > > Why do you resisted the temptation? I want to keep things simple. Our resources are already scattered across multiple domains and technologies. I didn't want to add to the complexity. Also, creating a new repository requires coordination and consent of other maintainers, and it was easier to continue using it as is. However, I see that there's more and more reason to separate gar (the framework) from the build files. I would like to keep the framework at gar.sf.net and move the build descriptions to opencsw.sf.net. To preserve history, we need to contact SF staff and as them to duplicate the repositories, and then move directories around to achieve the right layout. >> Well, I'd like to keep things containerized if possible. ?We already >> have quite the mingling of different things in the primary svn repo >> (gar, checkpkg, build recipes, sources for a few simple packages, >> etc). ?IMO, each of the above should be a separate repo, but I >> understand why they're not. >> >> The policy documentation will be a large enough entity that it >> deserves it's own place to live, imo. I'm inclined to agree, and all other things equal, keeping each project in a separate repository is better. If we were to keep the policy in a separate repository, where would you suggest keeping it? >>> If we decide that we need a new source repository, it will probably >>> be git, unless there's a specific reason to use another VCS. ?If you >>> create a new VCS, you need to make sure that it'll be reliable, >>> access-controlled, backed up and integrated with the rest of our >>> infrastructure. > > I agree that having separate repositories for separate projects is a > good thing (just look at the size of the actual gar). > > However, having many VCS types is a PITA. If we started with subversion > why change to git? Slowly all this will became a bazaar. Don't we want to have a different type of VCS? Subversion is centralized system, and it seems we want to move towards a distributed VCS. We probably won't want to use more than one distributed VCS, though. >> We're using sourceforge for svn and relying on their backup. ?We could >> do similar with one of github or gitorious (I use both already for a >> few things). ?Also, with a distributed VCS, each checkout is a >> backup...although there is potential to lose a few commits if a local >> copy is lost before sharing the changes. > > Is there a reason for which we cannot host our own repositories? > Especially if we use only one VCS and afferent tools. We could, but it's a little bit like having own water heating tank in your apartment (which I do...). I'd much prefer to have a shared one that somebody else looks after, it's more economical. If we used a distributed VCS, we would be best off using a source code hosting service such as github or bitbucket. The only issue is access control, as each of these services has own user name space, and every committer has to set up an account separate from our buildfarm accounts. From maciej at opencsw.org Sat Jan 1 14:30:25 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 1 Jan 2011 13:30:25 +0000 Subject: [csw-maintainers] Package naming policy In-Reply-To: References: <2D1CA123-FB16-40DA-9C56-8D63F7CA5C26@opencsw.org> <1D90E8CF-7212-4CD5-837A-9581F0972714@opencsw.org> <1293823722-sup-4143@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 1 de Janeiro de 2011 11:18, Peter FELECAN escreveu: > Ben Walton writes: > >> I'd prefer to standardize on the short -dev and _dev if we can for the >> reasons that you noted. > > Just a slight note: the -dev is not adequate as it serves as field > separator in catalog component parsing. If I'm wrong please correct me. I've recently added code[1] to cope with extra dashes in checkpkg, but this is to catch errors rather than produce catalogs. I think what Ben meant is: pkgname: CSWfoo-dev catalogname: foo_dev [1] http://sourceforge.net/apps/trac/gar/changeset/11952 From pfelecan at opencsw.org Sat Jan 1 14:45:04 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jan 2011 14:45:04 +0100 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: (Maciej Blizinski's message of "Sat, 1 Jan 2011 12:43:25 +0000") References: <1293828092-sup-7991@pinkfloyd.chass.utoronto.ca> Message-ID: "Maciej (Matchek) Blizinski" writes: > No dia 1 de Janeiro de 2011 11:05, Peter FELECAN > escreveu: >> The policies has the maintainers as the sole public. If somebody is >> interested by these discussion s/he can subscribe. > > Would it mean that once I'm subscribed, I can read all the archives? > We don't have that at the moment, AFAIK. If you wish to have a public list just for archival purposes then we certainly lack a feature. If I'm not mistaken, we use mailserv which offer this exact feature. Maybe Ishan can give us the status about that? >> The user is a >> fallacious public brought up only when cornered. >> >> Why do you think that Debian, among others, has private discussion lists? >> >>>> I'd say that creating the new mailing list should happen when we >>>> notice concrete problems with existing discussions and agree that a >>>> private list would solve them. >>> >>> Also agreed. ?If the policy specific volume on maintainers@ becomes a >>> significant proportion, we could split it out at a later time. >> >> I'm worried by the noise that can drown directly or indirectly policy >> discussion as happened so many time in the past. > > When you worry about noise, do you mean noise in the policy-related > thread or in other threads? If it's about other threads, using an > e-mail client which supports threads solves that problem. If you > worry about noise in the same thread, you're facing a social / > behavioral problem, and technical means are not likely to solve it. > If there's a person making distracting comments in the thread, the > right response is to talk to them and make them behave better. Both noises are worrying for me. Having isolation serve many purposes that I evoked. Even a threads aware mail client, cannot select easily the subjects if there is no good marking. Only those interested in the subject of policies need to read and we don't pollute the other lists. Finally, we have everything about policies in one place vs. today when we have discussions on maintainers and submit lists. > I'm not saying that there is no place for private discussions, but I'm > not convinced that it makes sense to have a private one for policy > related discussions. Policy decisions affect the largest group of > people: maintainers and users. It's important that all affected > parties have read access to these discussions, much the same way in > which the public has access to the parliament debates, both live on TV > and later on in transcripts. Again: I don't see why are the users interested in policies discussion. They are only interested in the result which will be available on line and off line. The policies affect overwhelmingly the maintenance activities and very slightly the usage. Anyhow, there is a need for a private list of some kind. -- Peter From pfelecan at opencsw.org Sat Jan 1 14:52:05 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jan 2011 14:52:05 +0100 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: (Maciej Blizinski's message of "Sat, 1 Jan 2011 13:23:36 +0000") References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293828566-sup-7900@pinkfloyd.chass.utoronto.ca> Message-ID: "Maciej (Matchek) Blizinski" writes: > No dia 1 de Janeiro de 2011 11:10, Peter FELECAN > escreveu: >> Ben Walton writes: >> >>> Excerpts from Maciej (Matchek) Blizinski's message of Fri Dec 31 15:44:56 -0500 2010: >>> >>>> Swinging Ockham's razor, I'd think twice before I created any new >>>> source repositories. ?I'm already tempted to create new repositories >>>> (for gar, for checkpkg), but I've been curbing these temptations. >> >> Why do you resisted the temptation? > To preserve history, we need to contact SF staff and as them to > duplicate the repositories, and then move directories around to > achieve the right layout. This is why I think that we should host our VCS: independence. >>> Well, I'd like to keep things containerized if possible. ?We already >>> have quite the mingling of different things in the primary svn repo >>> (gar, checkpkg, build recipes, sources for a few simple packages, >>> etc). ?IMO, each of the above should be a separate repo, but I >>> understand why they're not. >>> >>> The policy documentation will be a large enough entity that it >>> deserves it's own place to live, imo. > > I'm inclined to agree, and all other things equal, keeping each > project in a separate repository is better. If we were to keep the > policy in a separate repository, where would you suggest keeping it? On a serve in the opencsw.or domain. >>>> If we decide that we need a new source repository, it will probably >>>> be git, unless there's a specific reason to use another VCS. ?If you >>>> create a new VCS, you need to make sure that it'll be reliable, >>>> access-controlled, backed up and integrated with the rest of our >>>> infrastructure. >> >> I agree that having separate repositories for separate projects is a >> good thing (just look at the size of the actual gar). >> >> However, having many VCS types is a PITA. If we started with subversion >> why change to git? Slowly all this will became a bazaar. > > Don't we want to have a different type of VCS? Subversion is > centralized system, and it seems we want to move towards a distributed > VCS. We probably won't want to use more than one distributed VCS, > though. Even though I think that subversion is a leveling choice, I don't oppose to move to a distributed VCS as long as we don't change as a new fad emerge... >>> We're using sourceforge for svn and relying on their backup. ?We could >>> do similar with one of github or gitorious (I use both already for a >>> few things). ?Also, with a distributed VCS, each checkout is a >>> backup...although there is potential to lose a few commits if a local >>> copy is lost before sharing the changes. >> >> Is there a reason for which we cannot host our own repositories? >> Especially if we use only one VCS and afferent tools. > > We could, but it's a little bit like having own water heating tank in > your apartment (which I do...). I'd much prefer to have a shared one > that somebody else looks after, it's more economical. If we used a > distributed VCS, we would be best off using a source code hosting > service such as github or bitbucket. The only issue is access > control, as each of these services has own user name space, and every > committer has to set up an account separate from our buildfarm > accounts. Personally I don't like this kind of reasoning as it reduces our capacity of intervention and independence. -- Peter From maciej at opencsw.org Sat Jan 1 14:54:23 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 1 Jan 2011 13:54:23 +0000 Subject: [csw-maintainers] addition to CSWcommon? In-Reply-To: <1293825402-sup-4747@pinkfloyd.chass.utoronto.ca> References: <1292432556-sup-8979@pinkfloyd.chass.utoronto.ca> <1293825402-sup-4747@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 31 de Dezembro de 2010 19:59, Ben Walton escreveu: > Excerpts from Maciej (Matchek) Blizinski's message of Wed Dec 29 21:52:33 -0500 2010: > > Hi Maciej, > >> The 'none' class creates the missing files automatically, and we have >> a large number of files that are missing base directories. > > I like the intent, but I'm not sure I like the result. ?Wouldn't it be > better to simply tell the maintainer to ensure the package provides > this directory instead of potentially suggesting that the package > depend on other random looking (although definitely not random) > packages that do? I was thinking about a suggestion along the lines of "ginstall -m 755 -d $(PKGROOT)/", but it's hard to suggest a directory that gar will later exclude from the package. We could try to distinguish between directories that are supposed to be common and inherited from CSWcommon and directories that a package has to provide by itself. We could add a message along those lines: diff --git a/gar/v2/lib/python/package_checks.py b/gar/v2/lib/python/package_checks.py index 9707b15..c570e7b 100644 --- a/gar/v2/lib/python/package_checks.py +++ b/gar/v2/lib/python/package_checks.py @@ -1176,6 +1176,11 @@ def CheckBaseDirs(pkg_data, error_mgr, logger, messenger): base_dir, "%s contains %s which needs a base directory: %s." % (pkgname, repr(pkgmap_entry["path"]), repr(base_dir))) + messenger.Message( + "%s contains %s which needs a base directory: %s. " + "You can either depend on a package which provides this directory, " + "or provide this directory in your package." + % (pkgname, repr(pkgmap_entry["path"]), repr(base_dir))) def CheckDanglingSymlinks(pkg_data, error_mgr, logger, messenger): I agree that suggesting a gazillion unrelated looking packages might be confusing. We could stop doing that and only report missing base directories, but... if the right choice is to add a dependency, finding the right dependency by hand is a PITA. (Unless you know tricks such as "bin/pkgdb show filename /etc/opt/csw/init.d".) From pfelecan at opencsw.org Sat Jan 1 15:00:27 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jan 2011 15:00:27 +0100 Subject: [csw-maintainers] addition to CSWcommon? In-Reply-To: (Maciej Blizinski's message of "Sat, 1 Jan 2011 13:54:23 +0000") References: <1292432556-sup-8979@pinkfloyd.chass.utoronto.ca> <1293825402-sup-4747@pinkfloyd.chass.utoronto.ca> Message-ID: "Maciej (Matchek) Blizinski" writes: > I agree that suggesting a gazillion unrelated looking packages might > be confusing. We could stop doing that and only report missing base > directories, but... if the right choice is to add a dependency, > finding the right dependency by hand is a PITA. (Unless you know > tricks such as "bin/pkgdb show filename /etc/opt/csw/init.d".) It's not a unknown trick if you give this exact information in your message helping the maintainer to find his way. -- Peter From bwalton at opencsw.org Sat Jan 1 18:23:51 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 01 Jan 2011 12:23:51 -0500 Subject: [csw-maintainers] addition to CSWcommon? In-Reply-To: References: <1292432556-sup-8979@pinkfloyd.chass.utoronto.ca> Message-ID: <1293902405-sup-3722@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Wed Dec 15 12:24:49 -0500 2010: > >This never happened before because cswclassutils have always > >provided a sample init file to /etc/opt/csw/init.d. With the latest > >flipflop regarding NFS the sample was moved to /opt/csw/etc/init.d > >in May. Thus nothing creates the /etc/opt/csw/init.d directory any > >more. What about having CSWcas-initsmf provide this empty directory as part of it's package? Anything using this directory should be providing the file with class cswinitsmf anyway, which ensures the dependency. The dependency will ensure the directory is there... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Jan 1 18:29:41 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 1 Jan 2011 17:29:41 +0000 Subject: [csw-maintainers] addition to CSWcommon? In-Reply-To: References: <1292432556-sup-8979@pinkfloyd.chass.utoronto.ca> <1293825402-sup-4747@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 1 de Janeiro de 2011 14:00, Peter FELECAN escreveu: > "Maciej (Matchek) Blizinski" writes: > >> I agree that suggesting a gazillion unrelated looking packages might >> be confusing. ?We could stop doing that and only report missing base >> directories, but... if the right choice is to add a dependency, >> finding the right dependency by hand is a PITA. ?(Unless you know >> tricks such as "bin/pkgdb show filename /etc/opt/csw/init.d".) > > It's not a unknown trick if you give this exact information in your > message helping the maintainer to find his way. I still fiddle a lot with the interface of pkgdb, and I was a bit reluctant of revealing it to the world. This is a very good suggestion, how about the following patch? >From 4b04892ea243e9731930ed9086f92f45fe3860f1 Mon Sep 17 00:00:00 2001 From: Maciej Blizinski Date: Sat, 1 Jan 2011 11:48:44 +0100 Subject: [PATCH] checkpkg: Also suggest adding base dir to the pkg There are cases where checkpkg suggests seeminly random packages as dependencies. It might be a good idea to suggest adding the base directory to the package instead. I'm still unclear about the symlinks case - whether it's always true that if a base directory of a symlink is missing, pkgadd fails. It's been the case with coreutils, but I'm not sure whether it's a rule or a coincidence. http://lists.opencsw.org/pipermail/maintainers/2010-December/013567.html --- gar/v2/lib/python/package_checks.py | 19 +++++++++++++++---- 1 files changed, 15 insertions(+), 4 deletions(-) diff --git a/gar/v2/lib/python/package_checks.py b/gar/v2/lib/python/package_checks.py index 9707b15..0d800ff 100644 --- a/gar/v2/lib/python/package_checks.py +++ b/gar/v2/lib/python/package_checks.py @@ -1172,10 +1172,21 @@ def CheckBaseDirs(pkg_data, error_mgr, logger, messenger): if not pkgmap_entry["path"]: continue if pkgmap_entry["type"] == "s" or pkgmap_entry["class"] != "none": base_dir = os.path.dirname(pkgmap_entry["path"]) - error_mgr.NeedFile( - base_dir, - "%s contains %s which needs a base directory: %s." - % (pkgname, repr(pkgmap_entry["path"]), repr(base_dir))) + error_mgr.ReportError( + "base-directory-missing", + "basedir=%s " + "file=%s " + % (base_dir, pkgmap_entry["path"])) + if pkgmap_entry["class"] != "none": + messenger.Message( + "File %s has class %s, which is handled by a script " + "which might not work when the base directory is missing. " + "%s can either depend on a package which provides %s, " + "or provide this directory itself. " + "To find packages providing this directory, execute the following: " + "gar/bin/pkgdb show filename %s" + % (repr(pkgmap_entry["path"]), repr(pkgmap_entry["class"]), + pkgname, repr(base_dir), repr(base_dir))) def CheckDanglingSymlinks(pkg_data, error_mgr, logger, messenger): -- 1.7.1 From bwalton at opencsw.org Sat Jan 1 18:33:36 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 01 Jan 2011 12:33:36 -0500 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw Message-ID: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> Hi All, Since nobody can point at the original discussion thread where this 'policy' was agreed upon, I'm opening a new discussion for it. Currently, going forward, Phil is saying that packages shipping _files_ in /var/opt/csw will be blocked from release. It should be noted that _directories_ are ok. The rationale on this is that 'even a first level tech support could create directories if required.' The current backing decision on not shipping files in /var/opt/csw is centred around our support of a shared /opt/csw. Please frame the discussion around this from the viewpoint of a shared /opt/csw as we have yet to slay that dragon. So: Who's for, who's against and why do you hold this position? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Jan 1 18:34:52 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 01 Jan 2011 12:34:52 -0500 Subject: [csw-maintainers] Package naming policy In-Reply-To: References: <2D1CA123-FB16-40DA-9C56-8D63F7CA5C26@opencsw.org> <1D90E8CF-7212-4CD5-837A-9581F0972714@opencsw.org> <1293823722-sup-4143@pinkfloyd.chass.utoronto.ca> Message-ID: <1293903247-sup-5372@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sat Jan 01 06:18:00 -0500 2011: > Just a slight note: the -dev is not adequate as it serves as field > separator in catalog component parsing. If I'm wrong please correct me. Yes, that's true. Maciej was correct in saying that I'm for CSWfoo-dev (package) and foo_dev (catalog). Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Sat Jan 1 18:50:18 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jan 2011 18:50:18 +0100 Subject: [csw-maintainers] addition to CSWcommon? In-Reply-To: (Maciej Blizinski's message of "Sat, 1 Jan 2011 17:29:41 +0000") References: <1292432556-sup-8979@pinkfloyd.chass.utoronto.ca> <1293825402-sup-4747@pinkfloyd.chass.utoronto.ca> Message-ID: "Maciej (Matchek) Blizinski" writes: > No dia 1 de Janeiro de 2011 14:00, Peter FELECAN > escreveu: >> "Maciej (Matchek) Blizinski" writes: >> >>> I agree that suggesting a gazillion unrelated looking packages might >>> be confusing. ?We could stop doing that and only report missing base >>> directories, but... if the right choice is to add a dependency, >>> finding the right dependency by hand is a PITA. ?(Unless you know >>> tricks such as "bin/pkgdb show filename /etc/opt/csw/init.d".) >> >> It's not a unknown trick if you give this exact information in your >> message helping the maintainer to find his way. > > I still fiddle a lot with the interface of pkgdb, and I was a bit > reluctant of revealing it to the world. This is a very good > suggestion, how about the following patch? Seems satisfactory to me. -- Peter From maciej at opencsw.org Sat Jan 1 18:50:47 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 1 Jan 2011 17:50:47 +0000 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? Message-ID: I'm currently working with MySQL 5.x packages. I've looked again at the mysql libraries and noticed that they are placed under /opt/csw/mysql5/lib/mysql. For example: /opt/csw/mysql5/lib/mysql/libmysqlclient.so.15 I don't quite see a reason for this library to be there. We do compile packages that depend on MySQL libraries, and these binaries have to embed the right RPATH in order to work properly. Why do we first hide these library deep under /opt/csw/mysql5 only to have trouble finding them later on? We could simply put these libraries under /opt/csw/lib: /opt/csw/lib/libmysqlclient.so.15 The sonames of these libraries are bumped up with every MySQL update: 4.0: libmysqlclient.so.14, 5.0: libmysqlclient.so.15, 5.1: libmysqlclient.so.16. There will be no issues related to coexisting multiple MySQL versions. Any thoughts on that? Bad idea? Good idea? From pfelecan at opencsw.org Sat Jan 1 18:59:01 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jan 2011 18:59:01 +0100 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Sat, 01 Jan 2011 12:33:36 -0500") References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Since nobody can point at the original discussion thread where this > 'policy' was agreed upon, I'm opening a new discussion for it. > > Currently, going forward, Phil is saying that packages shipping > _files_ in /var/opt/csw will be blocked from release. It should be > noted that _directories_ are ok. The rationale on this is that 'even > a first level tech support could create directories if required.' > > The current backing decision on not shipping files in /var/opt/csw is > centred around our support of a shared /opt/csw. Please frame the > discussion around this from the viewpoint of a shared /opt/csw as we > have yet to slay that dragon. > > So: Who's for, who's against and why do you hold this position? If we can provide directories then files are alright also. I understand the issue with a shared /opt/csw but let me ask before that: is the support of a shared /opt/csw an established policy by itself? If yes, then we need: 1. to say this explicitly in our policies with all the strings and bells needed by such an use case. 2. a standardized mechanism to propagate all the stuff created by our packages on the NFS client's /var/opt/csw. Finally, I agree that this last points should be discussed in a separate policy thread by itself and, for the moment, for the policy in discussion, I'm not yet decided. P.S. Looking at your subject line, you propose for the time being to discuss policies on this list and to mark the related threads with the [policy] tag. -- Peter From pfelecan at opencsw.org Sat Jan 1 19:01:38 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jan 2011 19:01:38 +0100 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: (Maciej Blizinski's message of "Sat, 1 Jan 2011 17:50:47 +0000") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > I'm currently working with MySQL 5.x packages. I've looked again at > the mysql libraries and noticed that they are placed under > /opt/csw/mysql5/lib/mysql. For example: > > /opt/csw/mysql5/lib/mysql/libmysqlclient.so.15 > > I don't quite see a reason for this library to be there. We do > compile packages that depend on MySQL libraries, and these binaries > have to embed the right RPATH in order to work properly. Why do we > first hide these library deep under /opt/csw/mysql5 only to have > trouble finding them later on? We could simply put these libraries > under /opt/csw/lib: > > /opt/csw/lib/libmysqlclient.so.15 > > The sonames of these libraries are bumped up with every MySQL update: > 4.0: libmysqlclient.so.14, 5.0: libmysqlclient.so.15, 5.1: > libmysqlclient.so.16. There will be no issues related to coexisting > multiple MySQL versions. Any thoughts on that? Bad idea? Good idea? Good idea as we can now easily supply versioned shared libraries in versioned packages per our previous discussions. -- Peter From phil at bolthole.com Sat Jan 1 19:03:43 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 1 Jan 2011 10:03:43 -0800 Subject: [csw-maintainers] addition to CSWcommon? In-Reply-To: <1293902405-sup-3722@pinkfloyd.chass.utoronto.ca> References: <1292432556-sup-8979@pinkfloyd.chass.utoronto.ca> <1293902405-sup-3722@pinkfloyd.chass.utoronto.ca> Message-ID: except initsmf isn't supposed to use that path in the future. still needs to be rewritten On Saturday, January 1, 2011, Ben Walton wrote: >... > > What about having CSWcas-initsmf provide this empty directory as part > of it's package? ?Anything using this directory should be providing > the file with class cswinitsmf anyway, which ensures the dependency. > The dependency will ensure the directory is there... > > Thanks > -Ben From bwalton at opencsw.org Sat Jan 1 19:07:33 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 01 Jan 2011 13:07:33 -0500 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: <1293904658-sup-248@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sat Jan 01 12:50:47 -0500 2011: > /opt/csw/mysql5/lib/mysql/libmysqlclient.so.15 > > I don't quite see a reason for this library to be there. We do I imagine it stems from wanting to have multiple versions of mysql installed originally where the things in bin/ would have conflicted. It seems that alternatives would make this no longer necessary. I think the only thing that might need a bit of work to re-integrate might be the devel packages. Things that depend on the mysql libs should also have /opt/csw/lib in the RPATH, so moving the files shouldn't break things. This may not hold for things like the ruby mysql gem (I'd need to look at what it does when it builds), or maybe the perl/python equivalents, etc. > libmysqlclient.so.16. There will be no issues related to coexisting > multiple MySQL versions. Any thoughts on that? Bad idea? Good > idea? Overall I'm for the change as long as it doesn't have potential to break a lot of things on people. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Jan 1 19:10:09 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 01 Jan 2011 13:10:09 -0500 Subject: [csw-maintainers] addition to CSWcommon? In-Reply-To: References: <1292432556-sup-8979@pinkfloyd.chass.utoronto.ca> <1293902405-sup-3722@pinkfloyd.chass.utoronto.ca> Message-ID: <1293905390-sup-8498@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Jan 01 13:03:43 -0500 2011: > except initsmf isn't supposed to use that path in the future. still > needs to be rewritten Well, until somebody invests that time, this would be a clean interim solution. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sat Jan 1 19:10:37 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 1 Jan 2011 10:10:37 -0800 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: On Saturday, January 1, 2011, Peter FELECAN wrote: > "Maciej (Matchek) Blizinski" writes: > >> I'm currently working with MySQL 5.x packages. ?I've looked again at >> the mysql libraries and noticed that they are placed under >> /opt/csw/mysql5/lib/mysql. ?For example: >> >> /opt/csw/mysql5/lib/mysql/libmysqlclient.so.15 >> >> I don't quite see a reason for this library to be there. ?We do >> compile packages that depend on MySQL libraries, and these binaries >> have to embed the right RPATH in order to work properly. ?Why do we >> first hide these library deep under /opt/csw/mysql5 only to have >> trouble finding them later on? I think for two reasons: 1. a bunch of programs using mysql, may have only a single top level --with-mysql=/path/to/prefix/here 2. I think it's more than just shared libraries: there's a bunch of utilities, and we wanted to make sure if there are multiple versions that each has the matching utils for it. If we wanted to go with a standard of "we only support ONE version of mysql in 'current' at one time, so okay to compile with --prefix=/opt/csw" then that would be different... but we've had multiple spectacular failures at this sort of thing in the past two years, so perhaps this is not a good long term strategy, particularly for something as important as mysql. From phil at bolthole.com Sat Jan 1 19:27:55 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 1 Jan 2011 10:27:55 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jan 1, 2011 at 9:59 AM, Peter FELECAN wrote: > ... > If we can provide directories then files are alright also. > I dont see how that follows. directories are almost zero-content. They can be recreated at will with zero special knowlege. Whereas files actually have unique content, so they are impossible to recreate, without special knowlege of the proper contents. >... > 1. to say this explicitly in our policies with all the strings and > ? bells needed by such an use case. > > 2. a standardized mechanism to propagate all the stuff created by our > ? packages on the NFS client's /var/opt/csw. I think these are excellent ideas. To some degree, we do have 'use cases' for #1 documented, but they are a bit more geared towards user perspective, and I presume you mean more from a maintainer perspective. From maciej at opencsw.org Sat Jan 1 19:30:03 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 1 Jan 2011 18:30:03 +0000 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: No dia 1 de Janeiro de 2011 18:10, Philip Brown escreveu: > On Saturday, January 1, 2011, Peter FELECAN wrote: >> "Maciej (Matchek) Blizinski" writes: >> >>> I'm currently working with MySQL 5.x packages. ?I've looked again at >>> the mysql libraries and noticed that they are placed under >>> /opt/csw/mysql5/lib/mysql. ?For example: >>> >>> /opt/csw/mysql5/lib/mysql/libmysqlclient.so.15 >>> >>> I don't quite see a reason for this library to be there. ?We do >>> compile packages that depend on MySQL libraries, and these binaries >>> have to embed the right RPATH in order to work properly. ?Why do we >>> first hide these library deep under /opt/csw/mysql5 only to have >>> trouble finding them later on? > > I think for two reasons: > > 1. a bunch of programs using mysql, may have only a single top level > ?--with-mysql=/path/to/prefix/here --with-mysql is just a shortcut to a bundle of -I, -L and -R, isn't it? If binaries have /opt/csw/lib in RPATH, shared libraries will be found. We can look for these binaries. We can also provide symlinks in the legacy CSWmysql5rt, leading from the custom prefix to /opt/csw/lib. > 2. I think it's more than just shared libraries: there's a bunch of > utilities, and we wanted to make sure if there are multiple versions > that each has the matching utils for it. I'm not sure I follow. This is just shared libraries. > If we wanted to go with a standard of "we only support ONE version of > mysql in 'current' at one time, so okay to compile with > --prefix=/opt/csw" > then that would be different... but we've had multiple spectacular > failures at this sort of thing in the past two years, so perhaps this > is not a good long term strategy, particularly for something as > important as mysql. My proposal supports multiple versions of MySQL installed at one time, doesn't it? From pfelecan at opencsw.org Sat Jan 1 19:40:58 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jan 2011 19:40:58 +0100 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: (Philip Brown's message of "Sat, 1 Jan 2011 10:27:55 -0800") References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Sat, Jan 1, 2011 at 9:59 AM, Peter FELECAN wrote: >> ... >> If we can provide directories then files are alright also. >> > > I dont see how that follows. > directories are almost zero-content. They can be recreated at will > with zero special knowlege. > Whereas files actually have unique content, so they are impossible to > recreate, without special knowlege of the proper contents. For me creating directories is as complex or simple as copying files. It depends on the context. >>... >> 1. to say this explicitly in our policies with all the strings and >> ? bells needed by such an use case. >> >> 2. a standardized mechanism to propagate all the stuff created by our >> ? packages on the NFS client's /var/opt/csw. > > I think these are excellent ideas. > > To some degree, we do have 'use cases' for #1 documented, but they are > a bit more geared towards user perspective, and I presume you mean > more from a maintainer perspective. Right on point. In the policies we need a maintainer perspective to obtain an usage result. -- Peter From phil at bolthole.com Sat Jan 1 19:42:56 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 1 Jan 2011 10:42:56 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jan 1, 2011 at 9:33 AM, Ben Walton wrote: >... > Currently, going forward, Phil is saying that packages shipping > _files_ in /var/opt/csw will be blocked from release. ?It should be > noted that _directories_ are ok. ?The rationale on this is that 'even > a first level tech support could create directories if required.' > > The current backing decision on not shipping files in /var/opt/csw is > centred around our support of a shared /opt/csw. ?Please frame the > discussion around this from the viewpoint of a shared /opt/csw as we > have yet to slay that dragon. > > So: Who's for, who's against and why do you hold this position? So, to give more details, and coming from the standpoint of, "yes, we do support an nfs-shared, or otherwise replicated /opt/csw as much as possible" --- Consider a machine that is sitting somewhere, with just "/opt/csw". Perhaps think of it as a fresh install, where an admin has duplicated by some means, a new OS, and /opt/csw. The original master may be offline. Or in another country. Or the new machine may be off the net. Or in extreme, Large Organization cases, "run by a different IT group". So "just get it from the master" is not a good way to treat our users in this situation. We should give them an "easy to use" experience, starting from what they have in /opt/csw For *most* of our packages, no further work will be required; they will just work. For programs that normally are machine local, they will want setups and configs in machine-local places such as /etc/opt/csw and /var/opt/csw Ideally, admins of such boxes would be able to set up the machine-local configs in one of the following ways: 1. look in /opt/csw/share/[progname] for docs on configuring the software 2. look in /opt/csw/[progprefix] for docs/utils on configuring the software 3. run some kind of /opt/csw/(?)/bin/prog-first-setup utility to do the setup. Most of our "requires local setup" packages, are *already compliant* with this sort of thing. Things such as apache, have documentation in /opt/csw/(*)/share/doc. Mysql has things like /opt/csw/mysql5/share/mysql/my-small.cnf So this is not some kind of 'big change', but mostly just a formalization of what we already do in most cases. And the cases where we dont already do this.. there are relatively easy tweaks to adjust to this. It probably didnt take Jake very long to put together that little postinstall snippet he posted to the list for clamav, for example. From phil at bolthole.com Sat Jan 1 19:52:57 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 1 Jan 2011 10:52:57 -0800 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: On Sat, Jan 1, 2011 at 10:30 AM, Maciej (Matchek) Blizinski wrote: > >... > My proposal supports multiple versions of MySQL installed at one time, > doesn't it? maybe you could flush out a specific example of that. I didnt see that in what you've written so far. From pfelecan at opencsw.org Sat Jan 1 20:04:35 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jan 2011 20:04:35 +0100 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: (Philip Brown's message of "Sat, 1 Jan 2011 10:42:56 -0800") References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Sat, Jan 1, 2011 at 9:33 AM, Ben Walton wrote: >>... >> Currently, going forward, Phil is saying that packages shipping >> _files_ in /var/opt/csw will be blocked from release. ?It should be >> noted that _directories_ are ok. ?The rationale on this is that 'even >> a first level tech support could create directories if required.' >> >> The current backing decision on not shipping files in /var/opt/csw is >> centred around our support of a shared /opt/csw. ?Please frame the >> discussion around this from the viewpoint of a shared /opt/csw as we >> have yet to slay that dragon. >> >> So: Who's for, who's against and why do you hold this position? > > So, to give more details, and coming from the standpoint of, > "yes, we do support an nfs-shared, or otherwise replicated /opt/csw as > much as possible" --- Alright. Can you open a new policy thread for this specific issue: "support of a NFS shared /opt/csw" and formalize the policy as you see it, from the maintainer standpoint so that we can discuss it specifically? Thus, after stating the policy on that subject we can continue on the current thread. -- Peter From maciej at opencsw.org Sat Jan 1 20:06:57 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 1 Jan 2011 19:06:57 +0000 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: No dia 1 de Janeiro de 2011 18:52, Philip Brown escreveu: > On Sat, Jan 1, 2011 at 10:30 AM, Maciej (Matchek) Blizinski > wrote: >> >>... >> My proposal supports multiple versions of MySQL installed at one time, >> doesn't it? > > > maybe you could flush out a specific example of that. I didnt see that > in what you've written so far. I did: "The sonames of these libraries are bumped up with every MySQL update: 4.0: libmysqlclient.so.14, 5.0: libmysqlclient.so.15, 5.1: libmysqlclient.so.16." In a verbose way: Binaries that link to MySQL 4 libraries: NEEDED libmysqlclient.so.14 library found in /opt/csw/lib Binaries that link to MySQL 5.0 libraries: NEEDED libmysqlclient.so.15 library found in /opt/csw/lib Binaries that link to MySQL 5.1 libraries: NEEDED libmysqlclient.so.16 library found in /opt/csw/lib Does it make more sense now? From phil at bolthole.com Sat Jan 1 20:17:53 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 1 Jan 2011 11:17:53 -0800 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: On Sat, Jan 1, 2011 at 11:06 AM, Maciej (Matchek) Blizinski wrote: > No dia 1 de Janeiro de 2011 18:52, Philip Brown escreveu: >> On Sat, Jan 1, 2011 at 10:30 AM, Maciej (Matchek) Blizinski >> wrote: >>> >>>... >>> My proposal supports multiple versions of MySQL installed at one time, >>> doesn't it? >> >> >> maybe you could flush out a specific example of that. I didnt see that >> in what you've written so far. > > I did: "The sonames of these libraries are bumped up with every MySQL update: > 4.0: libmysqlclient.so.14, 5.0: libmysqlclient.so.15, 5.1: > libmysqlclient.so.16." > > In a verbose way: > > Binaries that link to MySQL 4 libraries: > NEEDED libmysqlclient.so.14 > library found in /opt/csw/lib > > Binaries that link to MySQL 5.0 libraries: > NEEDED libmysqlclient.so.15 > library found in /opt/csw/lib > > Binaries that link to MySQL 5.1 libraries: > NEEDED libmysqlclient.so.16 > library found in /opt/csw/lib > > Does it make more sense now? > no. you're too focused on shared libraries. youve only mentioned binaries as they related to shared libraries. you havent mentioned small details like where these multiple-version binaries will actually LIVE? :-) Your initial writeup seemed to imply that binaries would live in /opt/csw/bin But for multiple versions, thats not so good! Are you proposing the following: /opt/csw/lib/ libmysql.so.50 libmysql.so.51 /opt/csw/mysql5/lib libmysql.so.50 ->(lib/libmysql.so.50) libmysql.so -> (lib/libmysql.so.50) /opt/csw/mysql/(bin,include) -- As they are now ? As a minor niggling point, it might be "safer" to have the 'real' libraries in /opt/csw/mysqlprefix, and only have symlinks in /opt/csw/lib. That way, someone who wants to manually copy over mysql5X, can tar up /opt/csw/mysql5X and have all actual files, rather than having to go back later when he realizes, "oops I missed the actual libraries". This does have some drawbacks for maintainers though. While it serves the users better, it might mean that overly'intelligent' configuration things such as libtool, may follow the symlinks to the "real" location and add in explicit RPATHs to there. which would mean the maintainer may want to trim that out. I still think it would be better to have the real, in the prefix dir though. From maciej at opencsw.org Sun Jan 2 02:18:27 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 2 Jan 2011 01:18:27 +0000 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: No dia 1 de Janeiro de 2011 19:17, Philip Brown escreveu: > On Sat, Jan 1, 2011 at 11:06 AM, Maciej (Matchek) Blizinski > wrote: >> No dia 1 de Janeiro de 2011 18:52, Philip Brown escreveu: >>> On Sat, Jan 1, 2011 at 10:30 AM, Maciej (Matchek) Blizinski >>> wrote: >>>> >>>>... >>>> My proposal supports multiple versions of MySQL installed at one time, >>>> doesn't it? >>> >>> >>> maybe you could flush out a specific example of that. I didnt see that >>> in what you've written so far. >> >> I did: "The sonames of these libraries are bumped up with every MySQL update: >> 4.0: libmysqlclient.so.14, 5.0: libmysqlclient.so.15, 5.1: >> libmysqlclient.so.16." >> >> In a verbose way: >> >> Binaries that link to MySQL 4 libraries: >> NEEDED libmysqlclient.so.14 >> library found in /opt/csw/lib >> >> Binaries that link to MySQL 5.0 libraries: >> NEEDED libmysqlclient.so.15 >> library found in /opt/csw/lib >> >> Binaries that link to MySQL 5.1 libraries: >> NEEDED libmysqlclient.so.16 >> library found in /opt/csw/lib >> >> Does it make more sense now? >> > > no. you're too focused on shared libraries. youve only mentioned > binaries as they related to shared libraries. > you havent mentioned small details like where these multiple-version > binaries will actually LIVE? :-) > > Your initial writeup seemed to imply that binaries would live in /opt/csw/bin No, it didn't. If I wanted to suggest anything about binaries, I would write "binaries would be kept under..." and I'd specify the location. > But for multiple versions, thats not so good! > Are you proposing the following: > > > /opt/csw/lib/ ?libmysql.so.50 > ? ? ? ? ? ? ? ? ? libmysql.so.51 > > /opt/csw/mysql5/lib ?libmysql.so.50 ->(lib/libmysql.so.50) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?libmysql.so ? ? ?-> (lib/libmysql.so.50) > > /opt/csw/mysql/(bin,include) ?-- As they are now > > ? Yes. This only concerns the shared libraries, everything else stays as is. > As a minor niggling point, it might be "safer" to have the 'real' > libraries in /opt/csw/mysqlprefix, and only have symlinks in > /opt/csw/lib. > > That way, someone who wants to manually copy over mysql5X, can tar up > /opt/csw/mysql5X and have all actual files, rather than having to go > back later when he realizes, "oops I missed the actual libraries". Are you serious? Is that a supported use case? I thought that the whole idea of software packaging that you don't manually copy installed programs. > This does have some drawbacks for maintainers though. > While it serves the users better, it might mean that > overly'intelligent' configuration things such as libtool, may follow > the symlinks to the "real" location and add in explicit RPATHs to > there. which would mean the maintainer may want to trim that out. > > I still think it would be better to have the real, in the prefix dir though. The manual copy argument is slightly ridiculous. My idea is to keep the data files, just like in any other package, under /opt/csw/lib, and to provide symlinks from other locations for compatibility purposes. From phil at bolthole.com Sun Jan 2 02:52:46 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 1 Jan 2011 17:52:46 -0800 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: >Are you serious? ?Is that a supported use case? well, there's "supported" , and then there's "users do odd things sometimes" :-) there are also some side benefits, such as, a 'du' on the mysql dir will give accurate results for an admin who wants a quick check on that sort of thing. there's probably other small benefits like that I haven't thought about long enough to come up with. it seems more consistent to me also, that if we have gone to the trouble to subprefix mysql binaries, then *all* 'binary' type objects, including libraries, would go under there also. this seems to me to be fairly standard behavior, across a wide variety of software , and even platforms. From bwalton at opencsw.org Sun Jan 2 04:15:05 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 01 Jan 2011 22:15:05 -0500 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293828566-sup-7900@pinkfloyd.chass.utoronto.ca> Message-ID: <1293937858-sup-5193@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sat Jan 01 08:52:05 -0500 2011: > This is why I think that we should host our VCS: independence. IMO, if we move to hosting our own source repository (which isn't a bad thing), the tool _must_ be a distributed one as each cloned copy acts as a backup. Working offline is also an incredible benefit. (I wasn't intending to open up a VCS discussion here, I was merely pointing out a feature I thought might be good for this use case.) > Even though I think that subversion is a leveling choice, I don't > oppose to move to a distributed VCS as long as we don't change as a > new fad emerge... A project such as the policy source would be a good test bed for any potential change in VCS. It's small, new and will allow people to get a feel for a new tool. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Jan 2 04:16:28 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 01 Jan 2011 22:16:28 -0500 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> Message-ID: <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sat Jan 01 06:13:21 -0500 2011: > Docbook or even html as proposed by Phil is still SGML. Even with > the highly configurable Emacs it's a real PITA. Consequently, my > vote goes for asciidoc. The source of asciidoc is certainly more human readable too (it looks less like markup), so I'm ok with that. +1 for asciidoc. Anyone else? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Jan 2 04:28:04 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 01 Jan 2011 22:28:04 -0500 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293828092-sup-7991@pinkfloyd.chass.utoronto.ca> Message-ID: <1293938269-sup-1419@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sat Jan 01 06:05:03 -0500 2011: Hi Peter, > The policies has the maintainers as the sole public. If somebody is > interested by these discussion s/he can subscribe. The user is a > fallacious public brought up only when cornered. Well, as the policy that we set for packaging can have impact on the users and how those packages will interact with their systems, I think they might have an interest. Granted, most won't. I'm not wholly against a private list for this, but I'm perfectly comfortable having these decisions made in the open as well. Maciej's point about not having a URL that can be referenced or an archive that can be skimmed is also valid here. > Why do you think that Debian, among others, has private discussion > lists? Maybe they had problems with a 'peanut gallery' early on? > I'm worried by the noise that can drown directly or indirectly > policy discussion as happened so many time in the past. For my mail reading habits, it won't make a difference and I think it will still be susceptible to the same noise levels as we've seen on pkgsubmissions/maintainers for these types of things. It won't have negative impact on my mail handling though either, so if others think it's nicer, lets do it. Would anyone else prefer a separate list? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sun Jan 2 06:10:56 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 1 Jan 2011 21:10:56 -0800 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jan 1, 2011 at 7:16 PM, Ben Walton wrote: > Excerpts from Peter FELECAN's message of Sat Jan 01 06:13:21 -0500 2011: > >> Docbook or even html as proposed by Phil is still SGML. Even with >> the highly configurable Emacs it's a real PITA. Consequently, my >> vote goes for asciidoc. > > The source of asciidoc is certainly more human readable too (it looks > less like markup), so I'm ok with that. ?+1 for asciidoc. ?Anyone > else? I'm not familiar with asciidoc. Rather than having to take peoples word for [how language xyz looks], how about we put up some sample pages, with a medium (or possibly even high) complexity "sample document", in (abbreviated)HTML, asciidoc, and whatever else people would like to propose? Lets have people actually LOOK AT what they are deciding about, before they make decisions. Both the 'working code', and how the resulting output looks. From pfelecan at opencsw.org Sun Jan 2 09:30:54 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 02 Jan 2011 09:30:54 +0100 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: (Philip Brown's message of "Sat, 1 Jan 2011 17:52:46 -0800") References: Message-ID: Philip Brown writes: >>Are you serious? ?Is that a supported use case? > > well, there's "supported" , and then there's "users do odd things sometimes" :-) Everything is possible but we are not discussing about the totality of the possibles. As we use a packaging system we should stick to what it's possible with that. The other usages are not of our concern and admins or users can easily adapt if everything is orthogonal. As for the binaries, they can be very easily managed with alternatives as Ben has suggested. Don't forget that having chosen an alternative doesn't preclude to use a older or different version in the same time. -- Peter From maciej at opencsw.org Sun Jan 2 11:06:57 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 2 Jan 2011 10:06:57 +0000 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: No dia 2 de Janeiro de 2011 01:52, Philip Brown escreveu: >>Are you serious? ?Is that a supported use case? > > well, there's "supported" , and then there's "users do odd things sometimes" :-) > > there are also some side benefits, such as, a 'du' on the mysql dir > will give accurate results for an admin who wants a quick check on > that sort of thing. ?there's probably other small benefits like that I > haven't thought about long enough to come up with. That's the problem: once you're committed to one solution over another, you have a tendency to keep on finding as many "reasons" for it as you like. I'm sure that if you thought for a minute, you would come up with an equal number of arguments for the opposite solution. From bwalton at opencsw.org Sun Jan 2 15:36:37 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 02 Jan 2011 09:36:37 -0500 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: <1293978692-sup-5934@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sat Jan 01 20:18:27 -0500 2011: > No, it didn't. If I wanted to suggest anything about binaries, I > would write "binaries would be kept under..." and I'd specify the > location. Ok, then I rescind my +1 if only the libraries are to be moved. I also though you meant doing away with the whole mysql{4,5} prefixes and using alternatives with some form of binary suffix setup. What I'd like to see in the multiple mysql arena is: 1. Use the normal --prefix=/opt/csw at configure time. 2. Use a version based suffix on binaries (4, 5, 51). (Hopefully this is supported by the autoconf for the packages.) 3. Have mysql4 provide alternatives at priority 1, 5 -> 2, 5.1 -> 3, etc. If we're only moving the libraries, I don't see much point. It's doable, as you say, but what real value does it provide if we still drag around the rest of the version specific directory structure? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Jan 2 15:45:23 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 02 Jan 2011 09:45:23 -0500 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> Message-ID: <1293979248-sup-9284@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sun Jan 02 00:10:56 -0500 2011: > I'm not familiar with asciidoc. I've never used it either, but a quick look at the documentation for it shows it to be very easy to use: http://www.methods.co.nz/asciidoc/#_overview_and_examples > Rather than having to take peoples word for [how language xyz > looks], how about we put up some sample pages, with a medium (or > possibly even high) complexity "sample document", in > (abbreviated)HTML, asciidoc, and whatever else people would like to > propose? I'll assume that people can already understand the html. Suffice it to say that even a stripped down docbook will be far more verbose than the stripped down html version...although it offers more flexibility in output formats. > Both the 'working code', and how the resulting output looks. This is supplied above for asciidoc without additional work on our part. If people want to champion another format, lets see the similar links. This should give a more complete view than any 'sample' document we might put together. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Jan 2 15:54:12 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 02 Jan 2011 09:54:12 -0500 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> Message-ID: <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sat Jan 01 12:59:01 -0500 2011: Hi Peter, > I understand the issue with a shared /opt/csw but let me ask before > that: is the support of a shared /opt/csw an established policy by > itself? If yes, then we need: Well, much as I don't personally like it, we had this discussion in the spring/summer, I believe. The resulting document is here: http://wiki.opencsw.org/shared-opt-csw-setup This is the only place I've found that has any mention of handling packaged files in /var/opt/csw (the single line in the table). For the purpose of this discussion, lets focus only on whether or not files can be delivered in /var/opt/csw as part of the larger shared /opt/csw handling. This will solidify the current shared /opt/csw policy in the end. That policy can then be digested as a whole. > 2. a standardized mechanism to propagate all the stuff created by > our packages on the NFS client's /var/opt/csw. I think this is important. A postinstall script works for the package at install time, but really doesn't benefit the admins who want to replicate this to an NFS client. > P.S. Looking at your subject line, you propose for the time being to > discuss policies on this list and to mark the related threads > with the [policy] tag. Yes, it makes it stand out on the current list until we've finalized the other discussion. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Jan 2 16:08:24 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 02 Jan 2011 10:08:24 -0500 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> Message-ID: <1293980234-sup-3073@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Jan 01 13:42:56 -0500 2011: > For programs that normally are machine local, they will want setups > and configs in machine-local places such as /etc/opt/csw and > /var/opt/csw Let's not drag /etc/ into this. > 1. look in /opt/csw/share/[progname] for docs on configuring the > software We're talking about run-time data here, not config. > 2. look in /opt/csw/[progprefix] for docs/utils on configuring the > software Ditto. > 3. run some kind of /opt/csw/(?)/bin/prog-first-setup utility to do > the setup. This point is the only one that applies to the files in /var/opt/csw discussion. It also requires either a) an flexible generalized tool or b) specific support from each package to create and deliver such a script. I don't see the first option as very practical as it would be a collection of corner cases. The second option could be accomplished by creating the postinstall script as something like /opt/csw/bin/csw-first-$prog (not a good name, but works for example). The postinstall script could then be something that does nothing more than chroot to pkg_install_root to run csw-first-$prog.[1] I'm not sure yet if I find this to be worth the effort. If the files are delivered normally via the package (no special handling), an admin of a shared /opt/csw site could just as easily rsync the (already namespaced) /var/opt/csw to newly minted boxes too. Thanks -Ben [1] If something like this happens, I think it's important to have all scripts use the same prefix in a manner similar to the rest of the solaris admin tools. (be*, lu*, etc) -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sun Jan 2 16:46:59 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 2 Jan 2011 15:46:59 +0000 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: <1293978692-sup-5934@pinkfloyd.chass.utoronto.ca> References: <1293978692-sup-5934@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 2 de Janeiro de 2011 14:36, Ben Walton escreveu: > Excerpts from Maciej (Matchek) Blizinski's message of Sat Jan 01 20:18:27 -0500 2011: > >> No, it didn't. ?If I wanted to suggest anything about binaries, I >> would write "binaries would be kept under..." and I'd specify the >> location. > > Ok, then I rescind my +1 if only the libraries are to be moved. ?I > also though you meant doing away with the whole mysql{4,5} prefixes > and using alternatives with some form of binary suffix setup. > > What I'd like to see in the multiple mysql arena is: > > 1. Use the normal --prefix=/opt/csw at configure time. > 2. Use a version based suffix on binaries (4, 5, 51). ?(Hopefully this > ? is supported by the autoconf for the packages.) > 3. Have mysql4 provide alternatives at priority 1, 5 -> 2, 5.1 -> 3, > ? etc. I agree that it's a good idea and I would like the mysql packages to be packaged that way. In this proposal, I would like to decouple the packaging from shared libraries from the rest of mysql packages. I would like the mysql shared library packages to stop being special and different from all other shared library packages. > If we're only moving the libraries, I don't see much point. ?It's > doable, as you say, but what real value does it provide if we still > drag around the rest of the version specific directory structure? It's the divide and conquer idea - it's easier to tackle one problem at a time. I would like to deal with shared libraries first, and when this bit is done, continue with --prefix=/opt/csw. From bwalton at opencsw.org Sun Jan 2 17:16:51 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 02 Jan 2011 11:16:51 -0500 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> Message-ID: <1293984962-sup-4544@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Jan 01 13:27:55 -0500 2011: > directories are almost zero-content. They can be recreated at will > with zero special knowlege. > Whereas files actually have unique content, so they are impossible to > recreate, without special knowlege of the proper contents. I don't think this matters for the discussion at hand. The package either works or doesn't work. The ease of the remediation isn't the key factor. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Jan 2 18:07:15 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 02 Jan 2011 12:07:15 -0500 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: <1293978692-sup-5934@pinkfloyd.chass.utoronto.ca> Message-ID: <1293987891-sup-2364@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sun Jan 02 10:46:59 -0500 2011: > I agree that it's a good idea and I would like the mysql packages to > be packaged that way. In this proposal, I would like to decouple > the packaging from shared libraries from the rest of mysql packages. > I would like the mysql shared library packages to stop being special > and different from all other shared library packages. If this is a short term step as part of a larger plan to consolidate the entire package back under the 'normal' prefix, that's good. Don't you think it's potentially more inconvenient (to you and the users) to do this piecemeal though? > It's the divide and conquer idea - it's easier to tackle one problem > at a time. I would like to deal with shared libraries first, and > when this bit is done, continue with --prefix=/opt/csw. Ok. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Sun Jan 2 18:32:44 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 2 Jan 2011 18:32:44 +0100 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: <1293987891-sup-2364@pinkfloyd.chass.utoronto.ca> References: <1293978692-sup-5934@pinkfloyd.chass.utoronto.ca> <1293987891-sup-2364@pinkfloyd.chass.utoronto.ca> Message-ID: do you envision a simple and easy to upgrade package by everyone, or we end up with a "php-style package" nobody is able to maintain any more? On Sun, Jan 2, 2011 at 18:07, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Sun Jan 02 10:46:59 -0500 2011: > >> I agree that it's a good idea and I would like the mysql packages to >> be packaged that way. ?In this proposal, I would like to decouple >> the packaging from shared libraries from the rest of mysql packages. >> I would like the mysql shared library packages to stop being special >> and different from all other shared library packages. > > If this is a short term step as part of a larger plan to consolidate > the entire package back under the 'normal' prefix, that's good. ?Don't > you think it's potentially more inconvenient (to you and the users) to > do this piecemeal though? > >> It's the divide and conquer idea - it's easier to tackle one problem >> at a time. ?I would like to deal with shared libraries first, and >> when this bit is done, continue with --prefix=/opt/csw. > > Ok. > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From rupert at opencsw.org Sun Jan 2 19:00:05 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 2 Jan 2011 19:00:05 +0100 Subject: [csw-maintainers] gar problem on "gmake clean platforms" ? only the sparc package ends up in "pkgs" Message-ID: when doing the new version of the mercurial package, everything seemes fine. only the sparc, but not i386 package ends up in the pkgs directory: rupert at current9s:~/mgar/pkg/mercurial/trunk $ ls -l ~/pkgs/02.Jan.2011/ total 1305 -rw-r--r-- 1 rupert csw 1326766 Jan 2 11:46 mercurial-1.7.3,REV=2011.01.02-SunOS5.9-sparc-CSW.pkg.gz build9s$ gmake clean platforms ... gmake: Leaving directory `/home/rupert/mgar/pkg/mercurial/trunk' Connection to current9x closed. The following packages have been built during this invocation: * Platform solaris9-sparc (built on this host) CSWmercurial /home/rupert/pkgs/02.Jan.2011/mercurial-1.7.3,REV=2011.01.02-SunOS5.9-sparc-CSW.pkg.gz * Platform solaris9-i386 (built on host 'current9x') CSWmercurial /home/rupert/pkgs/02.Jan.2011/mercurial-1.7.3,REV=2011.01.02-SunOS5.9-i386-CSW.pkg.gz From rupert at opencsw.org Sun Jan 2 19:47:49 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 2 Jan 2011 19:47:49 +0100 Subject: [csw-maintainers] gar problem on "gmake clean platforms" ? only the sparc package ends up in "pkgs" In-Reply-To: References: Message-ID: i then logged into current9x and did a "gmake clean package". it got an error from checkpackage: surplus dependency on cswclassutils. then i deleted the "work directory, and did a "gmake clean package" on current9s, and current9x. no error any more. strange. rupert. On Sun, Jan 2, 2011 at 19:00, rupert THURNER wrote: > when doing the new version of the mercurial package, everything seemes > fine. only the sparc, but not i386 package ends up in the pkgs > directory: > > rupert at current9s:~/mgar/pkg/mercurial/trunk > $ ls -l ~/pkgs/02.Jan.2011/ > total 1305 > -rw-r--r-- 1 rupert csw 1326766 Jan ?2 11:46 > mercurial-1.7.3,REV=2011.01.02-SunOS5.9-sparc-CSW.pkg.gz > > > build9s$ gmake clean platforms > ... > gmake: Leaving directory `/home/rupert/mgar/pkg/mercurial/trunk' > Connection to current9x closed. > > The following packages have been built during this invocation: > > * Platform solaris9-sparc (built on this host) > ?CSWmercurial > /home/rupert/pkgs/02.Jan.2011/mercurial-1.7.3,REV=2011.01.02-SunOS5.9-sparc-CSW.pkg.gz > > * Platform solaris9-i386 (built on host 'current9x') > ?CSWmercurial > /home/rupert/pkgs/02.Jan.2011/mercurial-1.7.3,REV=2011.01.02-SunOS5.9-i386-CSW.pkg.gz > From ja at opencsw.org Sun Jan 2 21:47:27 2011 From: ja at opencsw.org (Juergen Arndt) Date: Sun, 2 Jan 2011 21:47:27 +0100 Subject: [csw-maintainers] Rework of rrdtool In-Reply-To: References: Message-ID: Hi , On 27.12.2010, at 23:36, Dagobert Michelsen wrote: > I just finished a complete reword of rrdtool including an update to 1.4.4 > and splitting the package according to the new library rules among specific > packages for the language bindings. Updated packages are available from > experimental at > http://buildfarm.opencsw.org/experimental.html#rrdtool > > J?rgen: As your packages are the primary users of rrdtool it would be great > if you could test them and update the dependencies after release. I built the munin packages today with the new dependencies and in a first test they work properly with your new packages on a fresh Solaris installation. I still have to fix some issues with the /var/opt/csw thing, then I will put them into experimental too. Should be done in the next two days. Regards Juergen -- Juergen Arndt From phil at bolthole.com Sun Jan 2 21:55:15 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 2 Jan 2011 12:55:15 -0800 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: On Sun, Jan 2, 2011 at 2:06 AM, Maciej (Matchek) Blizinski wrote: > No dia 2 de Janeiro de 2011 01:52, Philip Brown escreveu: >>>Are you serious? ?Is that a supported use case? >> >> well, there's "supported" , and then there's "users do odd things sometimes" :-) >> >> there are also some side benefits, such as, a 'du' on the mysql dir >> will give accurate results for an admin who wants a quick check on >> that sort of thing. ?there's probably other small benefits like that I >> haven't thought about long enough to come up with. > > That's the problem: once you're committed to one solution over > another, you have a tendency to keep on finding as many "reasons" for > it as you like. ?I'm sure that if you thought for a minute, you would > come up with an equal number of arguments for the opposite solution. > well, how about _you_ think for a minute and see if you can actually match your claims of "sure"ness then? Your timer starts now. go! 60... 59... 58... :) Come on now, what you wrote is completely out of order. Either come up with reasons, or let it go. you cant have a valid argument with your statements above. And putting the word "reasons" in quotes, is playing semantic games, instead of discussing the issue rationally. either they are valid reasons, or they are not. Putting "" around them doesnt make them any more, or less, valid. Deal with the reasons on their merits, please? Let's have a factual comparison of arguments for each way. From phil at bolthole.com Mon Jan 3 01:29:54 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 2 Jan 2011 16:29:54 -0800 Subject: [csw-maintainers] volunteer(s) needed to test new class action script Message-ID: For those who watch the src announce list, you may already know, that I'm working on a new class action script: cswcptemplates by default, it will copy files in /opt/csw/etc/templates/PKGname/file.cfg to /etc/opt/csw/file.cfg It will ALSO copy files from /opt/csw/etc/templates/PKGname/random/path/here to /random/path/here Although I should probably put safety checks to make sure that /random/path is at least under /etc/opt/csw or /var/opt/csw I would like to know if anyone is willing to help me test this beastie. From phil at bolthole.com Mon Jan 3 01:36:00 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 2 Jan 2011 16:36:00 -0800 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: <1293979248-sup-9284@pinkfloyd.chass.utoronto.ca> References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> <1293979248-sup-9284@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jan 2, 2011 at 6:45 AM, Ben Walton wrote: > >>[Phil wrote] >> [we should have samples of ]Both the 'working code', and how the resulting output looks. >> [for the same sample document] > > This is supplied above for asciidoc without additional work on our > part. ?If people want to champion another format, lets see the similar > links. ?This should give a more complete view than any 'sample' > document we might put together. > This is not being very "democratic" of you. Funny how the new mechanisms, seem to already be just like the old mechanisms :-} This sounds as though you as an individual have already chosen the format that we are going to use, and anyone else needs to do extra work to steer things otherwise. Funny how the new mechanisms, seem to already be just like the old mechanisms :-} I thought you said we were going to "vote" on this in some fashion? We should have our maintainers be fully informed voters. The only way for everyone to be "fully informed", is to have an apples to apples comparison. Furthermore, it should be an example specifically tailored to *our* needs, not just some generic asciidoc example. We should vote on what best meets *our* needs, not what is best to some generic asciidoc user. Perhaps this is the job of the new secretary, to set this up? I think this is Maciej? From bwalton at opencsw.org Mon Jan 3 01:52:07 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 02 Jan 2011 19:52:07 -0500 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> <1293979248-sup-9284@pinkfloyd.chass.utoronto.ca> Message-ID: <1294015617-sup-1020@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sun Jan 02 19:36:00 -0500 2011: > > This is supplied above for asciidoc without additional work on our > > part. ?If people want to champion another format, lets see the similar > > links. ?This should give a more complete view than any 'sample' > > document we might put together. > > This is not being very "democratic" of you. Funny how the new > mechanisms, seem to already be just like the old mechanisms :-} > This sounds as though you as an individual have already chosen the > format that we are going to use, and anyone else needs to do extra > work to steer things otherwise. Really? I'm not declaring anything, I'm simply noting my choice while providing you 'sample' work as requested. If you'd prefer another format (other than the html that you've already expressed html as your choice), please let us know. > I thought you said we were going to "vote" on this in some fashion? I'm happy to have a vote on this issue in a day or two (many people will just be waking up from the holiday slumber) if nobody puts forward another option. So far, we've got: 1. asciidoc 2. docbook 3. latex/tex 4. minimalist html > The only way for everyone to be "fully informed", is to have an apples > to apples comparison. Well, you've called for this side-by-side, which I'm not convinced is actually worthwhile, so please don't burden Maciej with this busy work. Rather, go ahead and put together the sample knockups yourself. The above four formats would suffice for now unless you'd like to extend the list? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jan 3 02:23:25 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 02 Jan 2011 20:23:25 -0500 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: References: Message-ID: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sun Jan 02 19:29:54 -0500 2011: > It will ALSO copy files from > > > /opt/csw/etc/templates/PKGname/random/path/here > > to > > /random/path/here I'm not sure I like this mode. What about a package that wants all of it's config files as a sub-directory of /etc/opt/csw? (eg: exim, apache, etc) How about changing this so that it's not a 'cased' action as the current script is written but rather an rsync-like action (with handling for existing files as a block on the copy)? I think that would be more generally useful...although given that you added the feature, I imagine you've got thoughts on where it would be used as is? If you release a test package CSWcas-cptemplates (or whatever) and then a subsequent package the uses it, I can test it on a box for you. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jan 3 02:25:42 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 02 Jan 2011 20:25:42 -0500 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> Message-ID: <1294017905-sup-8529@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Jan 02 20:23:25 -0500 2011: > Excerpts from Philip Brown's message of Sun Jan 02 19:29:54 -0500 2011: > > > It will ALSO copy files from > > > > > > /opt/csw/etc/templates/PKGname/random/path/here > > > > to > > > > /random/path/here > > How about changing this so that it's not a 'cased' action as the > current script is written but rather an rsync-like action (with > handling for existing files as a block on the copy)? I think that > would be more generally useful...although given that you added the > feature, I imagine you've got thoughts on where it would be used as > is? Never mind, this would be handled via an longer nested path as /random/path/here. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Mon Jan 3 11:17:53 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 3 Jan 2011 11:17:53 +0100 Subject: [csw-maintainers] Rework of rrdtool In-Reply-To: References: Message-ID: Hi J?rgen, Am 02.01.2011 um 21:47 schrieb Juergen Arndt: > On 27.12.2010, at 23:36, Dagobert Michelsen wrote: > >> I just finished a complete reword of rrdtool including an update to 1.4.4 >> and splitting the package according to the new library rules among specific >> packages for the language bindings. Updated packages are available from >> experimental at >> http://buildfarm.opencsw.org/experimental.html#rrdtool >> >> J?rgen: As your packages are the primary users of rrdtool it would be great >> if you could test them and update the dependencies after release. > > I built the munin packages today with the new dependencies and in a first test they work properly with your new packages on a fresh Solaris installation. I still have to fix some issues with the /var/opt/csw thing, then I will put them into experimental too. Should be done in the next two days. Cool! Please let me know if you find any issues. Best regards -- Dago PS: Happy new year, btw! :-) From maciej at opencsw.org Mon Jan 3 13:12:39 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 3 Jan 2011 12:12:39 +0000 Subject: [csw-maintainers] gar problem on "gmake clean platforms" ? only the sparc package ends up in "pkgs" In-Reply-To: References: Message-ID: No dia 2 de Janeiro de 2011 18:00, rupert THURNER escreveu: > when doing the new version of the mercurial package, everything seemes > fine. only the sparc, but not i386 package ends up in the pkgs > directory: > > rupert at current9s:~/mgar/pkg/mercurial/trunk > $ ls -l ~/pkgs/02.Jan.2011/ > total 1305 > -rw-r--r-- 1 rupert csw 1326766 Jan ?2 11:46 > mercurial-1.7.3,REV=2011.01.02-SunOS5.9-sparc-CSW.pkg.gz > > > build9s$ gmake clean platforms I think that what you meant to do, was 'gmake replatforms', which does 'gmake clean' for every platform. If you were on current9s and did a 'gmake clean', you only removed the working files for sparc 5.9, and i386 5.9 files stayed. From dam at opencsw.org Mon Jan 3 14:05:27 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 3 Jan 2011 14:05:27 +0100 Subject: [csw-maintainers] gar problem on "gmake clean platforms" ? only the sparc package ends up in "pkgs" In-Reply-To: References: Message-ID: Hi, Am 03.01.2011 um 13:12 schrieb Maciej (Matchek) Blizinski: > No dia 2 de Janeiro de 2011 18:00, rupert THURNER escreveu: >> when doing the new version of the mercurial package, everything seemes >> fine. only the sparc, but not i386 package ends up in the pkgs >> directory: >> >> rupert at current9s:~/mgar/pkg/mercurial/trunk >> $ ls -l ~/pkgs/02.Jan.2011/ >> total 1305 >> -rw-r--r-- 1 rupert csw 1326766 Jan 2 11:46 >> mercurial-1.7.3,REV=2011.01.02-SunOS5.9-sparc-CSW.pkg.gz >> >> >> build9s$ gmake clean platforms > > I think that what you meant to do, was 'gmake replatforms', which does > 'gmake clean' for every platform. Sort of, it does "gmake spotless". A normal clean only cleans the current platform whereas spotless removes work as a whole. Best regards -- Dago From phil at bolthole.com Mon Jan 3 17:47:02 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 3 Jan 2011 08:47:02 -0800 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jan 2, 2011 at 5:23 PM, Ben Walton wrote: >... > How about changing this so that it's not a 'cased' action as the > current script is written but rather an rsync-like action (with > handling for existing files as a block on the copy)? I dont see the difference. > If you release a test package CSWcas-cptemplates (or whatever) and > then a subsequent package the uses it, I can test it on a box for you. > I wanted to... its in svn. Trouble is, the "automatic" package builder thingie for cswclassutils, wont automatically build it. Perhaps you or Maciej could fix that, and then test the resulting package. From phil at bolthole.com Mon Jan 3 17:53:13 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 3 Jan 2011 08:53:13 -0800 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: <1294015617-sup-1020@pinkfloyd.chass.utoronto.ca> References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> <1293979248-sup-9284@pinkfloyd.chass.utoronto.ca> <1294015617-sup-1020@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jan 2, 2011 at 4:52 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Sun Jan 02 19:36:00 -0500 2011: > > I'm happy to have a vote on this issue in a day or two (many people > will just be waking up from the holiday slumber) if nobody puts > forward another option. ?So far, we've got: > > 1. asciidoc > 2. docbook > 3. latex/tex > 4. minimalist html > >> The only way for everyone to be "fully informed", is to have an apples >> to apples comparison. > > Well, you've called for this side-by-side, which I'm not convinced is > actually worthwhile, so please don't burden Maciej with this busy > work. ?Rather, go ahead and put together the sample knockups yourself. > The above four formats would suffice for now unless you'd like to > extend the list? This would not be fair. I have no interest in any of the other 3 formats; why should I work on those? Nor would I do a good job of them if I were, since I have no experience using them. The fair thing to do, is have the person "championing" each format, be responsible, for putting together the sample for "their" format. I'll be happy to put together the minimalist html version. There is the remaining issue first, of "what document layout shall we use as the example?" I think this should be the responsibility of "The Secretary", or possibly our web admin(s). But I would be willing to do that additional work if they are not. It will just take longer if I do it. From bwalton at opencsw.org Mon Jan 3 18:41:25 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 03 Jan 2011 12:41:25 -0500 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> Message-ID: <1294076418-sup-4156@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jan 03 11:47:02 -0500 2011: > On Sun, Jan 2, 2011 at 5:23 PM, Ben Walton wrote: > >... > > How about changing this so that it's not a 'cased' action as the > > current script is written but rather an rsync-like action (with > > handling for existing files as a block on the copy)? > > I dont see the difference. Yes, ignore that (as my followup suggested). > > If you release a test package CSWcas-cptemplates (or whatever) and > > then a subsequent package the uses it, I can test it on a box for you. > > > > > I wanted to... its in svn. Trouble is, the "automatic" package builder > thingie for cswclassutils, wont automatically build it. > Perhaps you or Maciej could fix that, and then test the resulting > package. Well, it built just fine for me (no changes required). A test package for just this CAS is in the experimental/cas_cptemplates repo. When you have a test package that uses this template, let me know. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Jan 3 20:24:32 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 3 Jan 2011 11:24:32 -0800 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: <1294076418-sup-4156@pinkfloyd.chass.utoronto.ca> References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> <1294076418-sup-4156@pinkfloyd.chass.utoronto.ca> Message-ID: I ideally need the package to have a directory in the pkginfo, along with the i and r scripts. How do I do that? (specifically, /opt/csw/etc/templates ) From bwalton at opencsw.org Mon Jan 3 20:29:03 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 03 Jan 2011 14:29:03 -0500 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> <1294076418-sup-4156@pinkfloyd.chass.utoronto.ca> Message-ID: <1294082852-sup-2496@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jan 03 14:24:32 -0500 2011: > I ideally need the package to have a directory in the pkginfo, along > with the i and r scripts. > How do I do that? Create the directory as part of the install-custom target in the makefile. ($(DESTDIR) is what you'd expect.). Then, add a line similar to the existing PKGFILES_ lines for -cptemplates. Once those changes are made, commit then and run: gmake spotless; gmake package HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Jan 3 21:10:06 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 3 Jan 2011 12:10:06 -0800 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: <1294082852-sup-2496@pinkfloyd.chass.utoronto.ca> References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> <1294076418-sup-4156@pinkfloyd.chass.utoronto.ca> <1294082852-sup-2496@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/3/11, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Jan 03 14:24:32 -0500 2011: > >> I ideally need the package to have a directory in the pkginfo, along >> with the i and r scripts. >> How do I do that? > > Create the directory as part of the install-custom target in the > makefile. ($(DESTDIR) is what you'd expect.). Then, add a line > similar to the existing PKGFILES_ lines for -cptemplates. > > Once those changes are made, commit then and run: > > gmake spotless; gmake package > thanks. is there a shortcut for "clean up JUST the sub-package I care about" ? would be nice if there were. but even the above, did not work for me (even without me trying to add the special install target. At this oint, I have not touched the Makefile). and that is after I did a svn update for gar. btw, I committed bugfixes for the scripts. I think its pretty much ready for you to pick whatever package you have that currently may use cpsampleconf or something, and migrate it. quilt, I guess, would be simplest? So if you would, please rebuild/repackage new version(since I cant) and test with quilt? Side note for the curious: CAS scripts written like cswcptemplates, will cleanly *RE*run, for pkgadd. if pkgadd/script run failed the first time, (or perhaps some idiot wiped out /etc/opt/csw) but you have the regular 'class none' files installed... running pkgadd again, will just run the CAS, and it will work as desired. Or do nothing, if the right stuff is already there. The benefits of paranoid programming :) From phil at bolthole.com Tue Jan 4 01:11:26 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 3 Jan 2011 16:11:26 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/2/11, Ben Walton wrote: > Excerpts from Peter FELECAN's message of Sat Jan 01 12:59:01 -0500 2011: > >> 2. a standardized mechanism to propagate all the stuff created by >> our packages on the NFS client's /var/opt/csw. > > I think this is important. A postinstall script works for the package > at install time, but really doesn't benefit the admins who want to > replicate this to an NFS client. > Just to appropriately "cross link" email threads.... good news... my new cswcptemplates class, exactly addresses this need. So if it works as intended, delivering stub files into var/opt, will be as easy as declaring the file as: f cswcptemplates /opt/csw/etc/templates/CSWblah/var/opt/csw/blahfile.db Add as many template files in as you wish, this way. (and adding cswcptemplates to the CLASS line, of course) during pkgadd, class will copy the above file to /var/opt/csw/blahfile.db, if and only if that file does not already exist. AAAND... for admins who deploy via NFS or whatever, they can just run the script manually, with the small additional hassle of specifying the PKG name on the command line. eg: PKG=CSWblah i.cswcptemplates and it will "do the right thing". Hrrm... Although to make it maximally easy for them, (and avoid having to locally install CSWcas-cptemplates on each box) will have to supply the script in BOTH /usr/sadm/install/scripts, and somewhere in /opt/csw. Need a new dir for copies of class action scripts like this. /opt/csw/etc/cswclasses/ ? or /opt/csw/sbin/cswclasses/? or....? From bwalton at opencsw.org Tue Jan 4 02:19:56 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 03 Jan 2011 20:19:56 -0500 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> <1294076418-sup-4156@pinkfloyd.chass.utoronto.ca> <1294082852-sup-2496@pinkfloyd.chass.utoronto.ca> Message-ID: <1294103762-sup-7633@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jan 03 15:10:06 -0500 2011: > is there a shortcut for > "clean up JUST the sub-package I care about" ? gmake package-CSWcas-cptemplates > would be nice if there were. As this is a new CAS, it's not important that cswclassutils depends on it, so there is no need to update that package for this (or ever again, really). > quilt, I guess, would be simplest? To rebuild quilt with this support requires adding support for this new CAS to GAR. I'm willing to make this effort after this things are tested and working, but not before. I can test/validate something you throw together, but I'm not investing much more of my time than that right now. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Jan 4 02:39:55 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 3 Jan 2011 17:39:55 -0800 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: <1294103762-sup-7633@pinkfloyd.chass.utoronto.ca> References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> <1294076418-sup-4156@pinkfloyd.chass.utoronto.ca> <1294082852-sup-2496@pinkfloyd.chass.utoronto.ca> <1294103762-sup-7633@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/3/11, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Jan 03 15:10:06 -0500 2011: > >> is there a shortcut for >> "clean up JUST the sub-package I care about" ? > > gmake package-CSWcas-cptemplates aha.. thanks. and I had forgotten that it dumps the output in ~/staging. so thats all right then. >> quilt, I guess, would be simplest? > > To rebuild quilt with this support requires adding support for this > new CAS to GAR. I'm willing to make this effort after this things are > tested and working, but not before. I can test/validate something you > throw together, but I'm not investing much more of my time than that > right now. Err.. whether the package is perfect right now or not, it WILL eventually be released. So seems like now is a good time to do that. I've already made a local test package that uses cptemplates, and "it works for me", so now is the time for other people to test cptemplates . My updated package now in http://buildfarm.opencsw.org/experimental/phil/cas_cptemplates-1.42,REV=2011.01.04-SunOS5.9-all-CSW.pkg.gz (becuase I dont have perms to write to cas_cptemplates dir) From bwalton at opencsw.org Tue Jan 4 02:45:35 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 03 Jan 2011 20:45:35 -0500 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> <1294076418-sup-4156@pinkfloyd.chass.utoronto.ca> <1294082852-sup-2496@pinkfloyd.chass.utoronto.ca> <1294103762-sup-7633@pinkfloyd.chass.utoronto.ca> Message-ID: <1294105478-sup-5640@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jan 03 20:39:55 -0500 2011: > Err.. whether the package is perfect right now or not, it WILL > eventually be released. So seems like now is a good time to do that. Feel free! :) This isn't high priority for me as I'm trying to get back into both apache2 and exim after the holiday hiatus. > I've already made a local test package that uses cptemplates, and > "it works for me", so now is the time for other people to test > cptemplates . Why not share that test package then? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Jan 4 02:48:56 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 3 Jan 2011 17:48:56 -0800 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: <1294105478-sup-5640@pinkfloyd.chass.utoronto.ca> References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> <1294076418-sup-4156@pinkfloyd.chass.utoronto.ca> <1294082852-sup-2496@pinkfloyd.chass.utoronto.ca> <1294103762-sup-7633@pinkfloyd.chass.utoronto.ca> <1294105478-sup-5640@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/3/11, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Jan 03 20:39:55 -0500 2011: > >> Err.. whether the package is perfect right now or not, it WILL >> eventually be released. So seems like now is a good time to do that. > > Feel free! :) This isn't high priority for me as I'm trying to get > back into both apache2 and exim after the holiday hiatus. > >> I've already made a local test package that uses cptemplates, and >> "it works for me", so now is the time for other people to test >> cptemplates . > > Why not share that test package then? err... whats the point of sharing a test package? it's already been tested. The point here is to see whether it works with **other peoples** packages? it's a completely artificial "test package", whose sole content is f cswcptemplates /opt/csw/etc/templates/testpkg/fakefilehere=fakefilehere If no-one else is going to test it, I guess I may as well just release the new CAS. From bwalton at opencsw.org Tue Jan 4 02:51:12 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 03 Jan 2011 20:51:12 -0500 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> <1294076418-sup-4156@pinkfloyd.chass.utoronto.ca> <1294082852-sup-2496@pinkfloyd.chass.utoronto.ca> <1294103762-sup-7633@pinkfloyd.chass.utoronto.ca> <1294105478-sup-5640@pinkfloyd.chass.utoronto.ca> Message-ID: <1294105853-sup-9835@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jan 03 20:48:56 -0500 2011: > If no-one else is going to test it, I guess I may as well just release > the new CAS. ...or, you could do the work to update quilt and test it? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Jan 4 02:53:27 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 3 Jan 2011 17:53:27 -0800 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: <1294105853-sup-9835@pinkfloyd.chass.utoronto.ca> References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> <1294076418-sup-4156@pinkfloyd.chass.utoronto.ca> <1294082852-sup-2496@pinkfloyd.chass.utoronto.ca> <1294103762-sup-7633@pinkfloyd.chass.utoronto.ca> <1294105478-sup-5640@pinkfloyd.chass.utoronto.ca> <1294105853-sup-9835@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/3/11, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Jan 03 20:48:56 -0500 2011: > >> If no-one else is going to test it, I guess I may as well just release >> the new CAS. > > ...or, you could do the work to update quilt and test it? I already have too many packages. Last thing I need is to take over someone else's packages. Sounds like you have too many packages as well. Anyone else want to volunteer to take over quilt? :-) From bwalton at opencsw.org Tue Jan 4 03:00:16 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 03 Jan 2011 21:00:16 -0500 Subject: [csw-maintainers] volunteer(s) needed to test new class action script In-Reply-To: References: <1294017539-sup-4985@pinkfloyd.chass.utoronto.ca> <1294076418-sup-4156@pinkfloyd.chass.utoronto.ca> <1294082852-sup-2496@pinkfloyd.chass.utoronto.ca> <1294103762-sup-7633@pinkfloyd.chass.utoronto.ca> <1294105478-sup-5640@pinkfloyd.chass.utoronto.ca> <1294105853-sup-9835@pinkfloyd.chass.utoronto.ca> Message-ID: <1294106386-sup-727@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jan 03 20:53:27 -0500 2011: > Sounds like you have too many packages as well. > Anyone else want to volunteer to take over quilt? :-) I only took this one one to meet a dependency update for gnulinks. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From okiddle at yahoo.co.uk Tue Jan 4 18:42:11 2011 From: okiddle at yahoo.co.uk (Oliver Kiddle) Date: Tue, 04 Jan 2011 18:42:11 +0100 Subject: [csw-maintainers] gar problem building zsh Message-ID: <19917.1294162931@thecus> I get the following error building zsh in gar: /bin/sh: syntax error at line 3: `;' unexpected This is coming from this line in gar.lib.mk: ( for i in $(filter %/$*,$(URLS)); do \ URLS does not contain anything matching %/CSWzsh.gspec so the for loop is being passed an empty list. Any idea what broke this and how to fix it. I'd like to update zsh to 4.3.11. Oliver From bwalton at opencsw.org Tue Jan 4 19:52:13 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 04 Jan 2011 13:52:13 -0500 Subject: [csw-maintainers] gar problem building zsh In-Reply-To: <19917.1294162931@thecus> References: <19917.1294162931@thecus> Message-ID: <1294167038-sup-582@pinkfloyd.chass.utoronto.ca> Excerpts from Oliver Kiddle's message of Tue Jan 04 12:42:11 -0500 2011: Hi Oliver, > I get the following error building zsh in gar: > /bin/sh: syntax error at line 3: `;' unexpected I see that this recipe still has a call to 'admfiles'[1] in it. I think this was broken a while back...Try replacing: DISTFILES += $(call admfiles,CSWzsh,postinstall postremove) with: DISTFILES += CSWzsh.postinstall CSWzsh.postremove Let me know if that doesn't work. Thanks -Ben [1] We should likely either remove this function or turn it into an $(error). -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Tue Jan 4 20:21:50 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 04 Jan 2011 20:21:50 +0100 Subject: [csw-maintainers] [ITP] gdb 7.2 Message-ID: As nobody answered positively to my question "is somebody working on gdb?" of December 20th, I declare the intent to package the new version of gdb and consequently take over the package maintenanceship (the current maintainer is retired). Remark that I'm using the [ITP] tag in the subject line to emphasize this kind of action. -- Peter From phil at bolthole.com Tue Jan 4 20:40:50 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 4 Jan 2011 11:40:50 -0800 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: References: Message-ID: On 1/4/11, Peter FELECAN wrote: > As nobody answered positively to my question "is somebody working on > gdb?" of December 20th, I declare the intent to package the new version > of gdb and consequently take over the package maintenanceship (the > current maintainer is retired). > > Remark that I'm using the [ITP] tag in the subject line to emphasize > this kind of action. Note to others: This is of course "how debian does it". But this sort of thing has not worked very well for us in the past. (because some people post "intent", but then never complete the job. This is not directed at Peter: I'm specifically meaning different people) For a package where the maintainer is already marked "retired", any maintainer can create a package?and submit it. Once it passes release manager checks, they then automatically become the new maintainer of that package. There is no prerequisite to post "intent" in this case. Results matter more than "intent" :) From ihsan at opencsw.org Tue Jan 4 21:29:43 2011 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Tue, 04 Jan 2011 21:29:43 +0100 Subject: [csw-maintainers] Wintercamp 2010/2011? In-Reply-To: References: <20101207162737.GB30288@sebastiankayser.de> <23E107A9-D5DE-44EB-A7FE-B54E8AFDA937@opencsw.org> <20101207211455.GE30288@sebastiankayser.de> <1EA6BB8D-C7B6-4C7B-A4E1-7D4CFA5036EF@opencsw.org> <20101223122148.GC4011@sebastiankayser.de> Message-ID: <4D238337.8040604@opencsw.org> Am 23.12.2010 13:38, schrieb Maciej (Matchek) Blizinski: >> Any further would-like-to-attendees please submit your availability on >> the Doodle poll. Current poll status suggests the weekend of 19/20th >> February. Are the dates still good for all those who voted (in >> particular for you, Maciej, as our host)? If not, please update your >> availability. > > Yes, these dates are good. Also fine for me. So, is it then Luxembourg? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Tue Jan 4 22:50:19 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 4 Jan 2011 21:50:19 +0000 Subject: [csw-maintainers] Intents to package Message-ID: No dia 4 de Janeiro de 2011 19:40, Philip Brown escreveu: > Note to others: > This is of course "how debian does it". But this sort of thing has not > worked very well for us in the past. > (because some people post "intent", but then never complete the job. > This is not directed at Peter: I'm specifically meaning different > people) > > For a package where the maintainer is already marked "retired", any > maintainer can create a package?and submit it. Once it passes release > manager checks, they then automatically become the new maintainer of > that package. > There is no prerequisite to post "intent" in this case. Results matter > more than "intent" :) I beg to differ. What did not work for us in the past (and present) is a very late inspection of a package in which all the decisions have been already made and all the work has been done. Imagine a situation in which there are 2 ways of making a package, and you have to make the design decision first, and then do a lot of work. If you want to change your design decision later on, you basically have to go back to the start. The time to discuss that design is before you do the work, not after. It is incredible frustrating to have spent a lot of time on a package which is later rejected. There are significant negative psychological effects of this scenario. You might not observe them directly, because symptoms are that the frustrated maintainer becomes quiet... and disappears. There will be very little or no warning signals. If you want to refresh your memory, you can always check the list of inactive maintainers and think about reasons why they might have stopped contributing. It's not about the reasons for which packages are rejected; it's about the time feedback is given. From phil at bolthole.com Tue Jan 4 23:22:05 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 4 Jan 2011 14:22:05 -0800 Subject: [csw-maintainers] Intents to package In-Reply-To: References: Message-ID: On 1/4/11, Maciej (Matchek) Blizinski wrote: >>... >> There is no prerequisite to post "intent" in this case. Results matter >> more than "intent" :) > > I beg to differ. What did not work for us in the past (and present) is a > very late inspection of a package in which all the decisions have been > already made and all the work has been done. Imagine a situation in > which there are 2 ways of making a package, and you have to make the > design decision first, and then do a lot of work. If you want to > change your design decision later on, you basically have to go back to > the start. The time to discuss that design is before you do the work, > not after. Certainly. But that has nothing to do with announcing "intend to package". If that sort of problem comes up, it seems straightforward to make a targetted email, "I'm looking at packaging X, but run into problem Y. How would people suggest I solve problem Y"? the subject should be more about "problem Y". the fact that it is contained in "package X" is only peripheral information. From bwalton at opencsw.org Wed Jan 5 04:19:53 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 04 Jan 2011 22:19:53 -0500 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> Message-ID: <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jan 03 19:11:26 -0500 2011: > Just to appropriately "cross link" email threads.... Ok, lets! I inadvertently found the original[1] conversation while looking for other old threads tonight. The thread in February was a few messages and then it got picked up again later on[2]. The only mention of the /var/opt stuff was by James, early on. It was never actually discussed beyond the initial mention. Therefore, it was not generally agreed as policy at that time.[3] > So if it works as intended, delivering stub files into var/opt, will > be as easy as > declaring the file as: > > f cswcptemplates /opt/csw/etc/templates/CSWblah/var/opt/csw/blahfile.db > Add as many template files in as you wish, this way. Ok, this at least makes it a somewhat reasonable approach. I propose that we throw this to a vote. This will give us a final decision. Before I craft the vote though, does anyone else have thoughts on this issue? Rought vote details: - The vote will be open to active members. - The vote will run for $x days. (I'm thinking 3 as a value for x.) - The outcome of the vote will affect package gating/release criteria going forward. - ballotbin.com worked well enough (it's not perfect) so unless someone has a better tool, we can use that again. - The vote will be on whether or not files and directories may be delivered directly (in the prototype) by a package to /var/opt/csw/... Thanks -Ben [1] http://lists.opencsw.org/pipermail/maintainers/2010-February/011201.html [2] My mail client (sup) nicely threads the whole thing, which is hard to do with the online browser: http://i.imgur.com/8IQeX.png [3] Unless it was discussed again at some other point? -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Jan 5 10:25:55 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 5 Jan 2011 10:25:55 +0100 Subject: [csw-maintainers] gar problem building zsh In-Reply-To: <1294167038-sup-582@pinkfloyd.chass.utoronto.ca> References: <19917.1294162931@thecus> <1294167038-sup-582@pinkfloyd.chass.utoronto.ca> Message-ID: <1B444B96-C589-49DE-9743-76C032206A22@opencsw.org> Hi, Am 04.01.2011 um 19:52 schrieb Ben Walton: > Excerpts from Oliver Kiddle's message of Tue Jan 04 12:42:11 -0500 2011: >> I get the following error building zsh in gar: >> /bin/sh: syntax error at line 3: `;' unexpected > > I see that this recipe still has a call to 'admfiles'[1] in it. I think > this was broken a while back...Try replacing: > > DISTFILES += $(call admfiles,CSWzsh,postinstall postremove) > > with: > > DISTFILES += CSWzsh.postinstall CSWzsh.postremove Oliver: You are trying to modify /etc/shells in your postinstall/postremove. It would be even better to use the "build" CAS from bash: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/bash/trunk/Makefile ...and even better would be to add the shell-modification as CAS in OpenCSW-style and just pass the line with the shell to be added/removed. > Let me know if that doesn't work. > > Thanks > -Ben > > [1] We should likely either remove this function or turn it into an > $(error). We can safely remove explicit gspec-support from GAR. Best regards -- Dago From dam at opencsw.org Wed Jan 5 10:27:49 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 5 Jan 2011 10:27:49 +0100 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: References: Message-ID: Hi Peter, Am 04.01.2011 um 20:21 schrieb Peter FELECAN: > As nobody answered positively to my question "is somebody working on > gdb?" of December 20th, I declare the intent to package the new version > of gdb and consequently take over the package maintenanceship (the > current maintainer is retired). Sure, please go ahead. I tried to make an gdb 6.8, but it crashed quite often. Additionally, it may be advisable to use the (non-trivial!) patches from OpenSolaris for gdb, which are also listed in the gdb description in GAR: http://cvs.opensolaris.org/source/xref/sfw/usr/src/cmd/gdb/ Best regards -- Dago From pfelecan at opencsw.org Wed Jan 5 10:53:14 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 05 Jan 2011 10:53:14 +0100 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: (Dagobert Michelsen's message of "Wed, 5 Jan 2011 10:27:49 +0100") References: Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 04.01.2011 um 20:21 schrieb Peter FELECAN: >> As nobody answered positively to my question "is somebody working on >> gdb?" of December 20th, I declare the intent to package the new version >> of gdb and consequently take over the package maintenanceship (the >> current maintainer is retired). > > Sure, please go ahead. I tried to make an gdb 6.8, but it crashed quite > often. Additionally, it may be advisable to use the (non-trivial!) patches > from OpenSolaris for gdb, which are also listed in the gdb description > in GAR: > http://cvs.opensolaris.org/source/xref/sfw/usr/src/cmd/gdb/ Thank you Dag. As I'm packaging 7.2 I will be very careful in applying and/or adapting theses patches. The Intent/Interest declaration is useful exactly for this kind of stuff. Anyway, before declaring I made sure that I can deliver something. -- Peter From phil at bolthole.com Wed Jan 5 18:13:58 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 5 Jan 2011 09:13:58 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/4/11, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Jan 03 19:11:26 -0500 2011: > >> Just to appropriately "cross link" email threads.... > > Ok, lets! > > I inadvertently found the original[1] conversation while looking for > other old threads tonight. The thread in February was a few messages > and then it got picked up again later on[2]. The only mention of the > /var/opt stuff was by James, early on. It was never actually > discussed beyond the initial mention. Therefore, it was not generally > agreed as policy at that time.[3] what you wrote above, can be summarized as, "I found an old thread that mentioned /var/opt, but there was no agreement about it at that time". That is not the same thing as "there was never any agreement by people to disallow it". Both the summer camp writeup you have referenced on it, and the more general policy of "we suport shared /opt/csw ", encompass agreements that it should not be allowed. We have THREE board members, but we've only publically heard from one on this issue. I'd like to see our other two members write something about the above two agreements, relating to this issue. Particularly the claim of ambiguity about /var/opt/ in http://wiki.opencsw.org/shared-opt-csw-setup I would say it is completely clear, and you are misreading it. There's a difference between "ambiguity" and misreading. directory writable Allowable use /var/opt/csw Yes Allowable for run-time-only data. Do not deliver files in package here That seems completely non-ambiguous. The meaning of "run-time" is non-ambiguous. The meaning of "Do not deliver files in package here" is completely clear in terms of disallowing files in the prototype under /var/opt/csw. The only ambiguity is whether it allows indirect "delivery" via tactics such as postinstall or class action scripts. From rupert at opencsw.org Wed Jan 5 20:55:59 2011 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 5 Jan 2011 20:55:59 +0100 Subject: [csw-maintainers] gar problem on "gmake clean platforms" ? only the sparc package ends up in "pkgs" In-Reply-To: References: Message-ID: On Mon, Jan 3, 2011 at 14:05, Dagobert Michelsen wrote: > Hi, > > Am 03.01.2011 um 13:12 schrieb Maciej (Matchek) Blizinski: >> No dia 2 de Janeiro de 2011 18:00, rupert THURNER escreveu: >>> when doing the new version of the mercurial package, everything seemes >>> fine. only the sparc, but not i386 package ends up in the pkgs >>> directory: >>> >>> rupert at current9s:~/mgar/pkg/mercurial/trunk >>> $ ls -l ~/pkgs/02.Jan.2011/ >>> total 1305 >>> -rw-r--r-- 1 rupert csw 1326766 Jan ?2 11:46 >>> mercurial-1.7.3,REV=2011.01.02-SunOS5.9-sparc-CSW.pkg.gz >>> >>> >>> build9s$ gmake clean platforms >> >> I think that what you meant to do, was 'gmake replatforms', which does >> 'gmake clean' for every platform. > > Sort of, it does "gmake spotless". A normal clean only cleans the > current platform whereas spotless removes work as a whole. does it make sense to have a "gmake platform"? less targets would be less documentation and less errors to make :) rupert. From dam at opencsw.org Wed Jan 5 20:58:10 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 5 Jan 2011 20:58:10 +0100 Subject: [csw-maintainers] gar problem on "gmake clean platforms" ? only the sparc package ends up in "pkgs" In-Reply-To: References: Message-ID: <8AF08672-AF6F-466D-A166-6785775E109A@opencsw.org> Hi Rupret, Am 05.01.2011 um 20:55 schrieb rupert THURNER: > On Mon, Jan 3, 2011 at 14:05, Dagobert Michelsen wrote: >> Hi, >> >> Am 03.01.2011 um 13:12 schrieb Maciej (Matchek) Blizinski: >>> No dia 2 de Janeiro de 2011 18:00, rupert THURNER escreveu: >>>> when doing the new version of the mercurial package, everything seemes >>>> fine. only the sparc, but not i386 package ends up in the pkgs >>>> directory: >>>> >>>> rupert at current9s:~/mgar/pkg/mercurial/trunk >>>> $ ls -l ~/pkgs/02.Jan.2011/ >>>> total 1305 >>>> -rw-r--r-- 1 rupert csw 1326766 Jan 2 11:46 >>>> mercurial-1.7.3,REV=2011.01.02-SunOS5.9-sparc-CSW.pkg.gz >>>> >>>> >>>> build9s$ gmake clean platforms >>> >>> I think that what you meant to do, was 'gmake replatforms', which does >>> 'gmake clean' for every platform. >> >> Sort of, it does "gmake spotless". A normal clean only cleans the >> current platform whereas spotless removes work as a whole. > > does it make sense to have a "gmake platform"? less targets would be > less documentation and less errors to make :) Just prepend the usual "re-" :-) gmake replatforms It does a "gmake spotless && gmake platforms". Best regards -- Dago From bwalton at opencsw.org Thu Jan 6 02:30:24 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 05 Jan 2011 20:30:24 -0500 Subject: [csw-maintainers] [csw-pkgsubmissions] patching made simpler? In-Reply-To: References: Message-ID: <1294276587-sup-9714@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Wed Jan 05 14:12:46 -0500 2011: Hi Rupert, I'm sorry this wasn't easier for you. > * try to build, not all patches applied > * throw away the old patches, check in First, a recommendation: Never throw away patch/script/foo files from an existing build until you've got a working replacement. I've kicked myself a few times for doing this. :) In a situation like this, I'd see if I could get the patches to apply manually using patch or other methods. > * "gmake extract" to get the source back > * edit the files again like it should be Although it may not complain, makepatch would prefer to be called after `gmake patch` to ensure all existing patches are applied. I forget whether I enforced this with a constraint or not...If not, I don't recall a the reason why I didn't. > * "gmake makepatch" > * "gmake package", failed as there is a new file which would need > patching as well. > * "gmake clean", "gmake extract" again > * edit the file > * "gmake makepatch" again Did you see your first patch applied in this process at all? If not, you're working on a pre-patched set of files. > then i forgot to delete a line in a file which is already patched, and > i thought about repeating above procedure again: > 1. gmake extract > applied patch 001 > 2. gmake makepatch > tried to apply patch 001 again > which failed. This is likely due to creating a patch against the unpatched tree above. If so, I should look at making sure makepatch cannot run unless the patch target has already been called. You could, potentially still have problems though... > then i gave up for the moment ... but this cannot be it, isn't it? > should we switch to the whole source from subversion to git and it > would be neater? then patches could be rebased instead of applied > newly. I wouldn't object[1], but others may disagree. It's also a huge undertaking. I know that many others are also using git quite a bit lately too. The first major portion of this transition would require separating GAR (the tool) from the build recipes. Git simply doesn't handle (nicely) the idea of an external like subversion does. This would be the final impetus to separate the two, most likely using Sebastian's excellent mgar! I know that Maciej has been having both success and frustration using the git-svn bridge as of late... Thanks -Ben [1] It would actually make my day! -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Thu Jan 6 09:34:33 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 06 Jan 2011 09:34:33 +0100 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: (Philip Brown's message of "Wed, 5 Jan 2011 09:13:58 -0800") References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On 1/4/11, Ben Walton wrote: >> Excerpts from Philip Brown's message of Mon Jan 03 19:11:26 -0500 2011: >> >>> Just to appropriately "cross link" email threads.... >> >> Ok, lets! >> >> I inadvertently found the original[1] conversation while looking for >> other old threads tonight. The thread in February was a few messages >> and then it got picked up again later on[2]. The only mention of the >> /var/opt stuff was by James, early on. It was never actually >> discussed beyond the initial mention. Therefore, it was not generally >> agreed as policy at that time.[3] > > what you wrote above, can be summarized as, "I found an old thread > that mentioned /var/opt, but there was no agreement about it at that > time". > That is not the same thing as "there was never any agreement by people > to disallow it". > > Both the summer camp writeup you have referenced on it, and the more > general policy of "we suport shared /opt/csw ", encompass agreements > that it should not be allowed. > > We have THREE board members, but we've only publically heard from one > on this issue. > I'd like to see our other two members write something about the above > two agreements, relating to this issue. We discussed all this on the submit mailing list (look for the "newpkgs clamav, libclam6, libclam6_devel" thread starting at http://lists.opencsw.org/pipermail/pkgsubmissions/2010-November/001501.html, continued at http://lists.opencsw.org/pipermail/pkgsubmissions/2010-December/001659.html since October. You had at least 5 people giving their view on this subject, among them 2 members of the current board. Why do you want specifically the opinion of the board members? The other maintainers opinion doesn't count? As for my opinion let me reiterate: - we can deliver directories and files in /var/opt/csw directly from the package prototype - optionally, a package can deliver a tool to bootstrap a NFS served client with that components if that is natural for its domain and the maintainer is willing to spend his energy - if the above mentioned tool doesn't exist the package can declare itself non compatible with the NFS mounted /opt/csw It would be nice if the board organize a vote on this issue and we close the discussion with a decision. -- Peter From pfelecan at opencsw.org Thu Jan 6 17:15:42 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 06 Jan 2011 17:15:42 +0100 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: (Peter FELECAN's message of "Tue, 04 Jan 2011 20:21:50 +0100") References: Message-ID: For those curious, here is a strange domino game that I discovered testing the new gdb package. It's quite long but I wrote this in the spirit of sharing and documenting a typical issue involved when creating packages. Enjoy. When debugging a trivial program: #include int main(int argc, char* argv) { printf("simple test\n"); exit(0); } compiled as follows: gcc -ggdb3 tgdb.c -o tgdb gdb tgdb an internal error is encountered: GNU gdb (GDB) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-pc-solaris2.10". For bug reporting instructions, please see: ... Reading symbols from /karmamaya/tmp/tgdb...done. (gdb) b main Breakpoint 1 at 0x80506e0: file tgdb.c, line 5. (gdb) r Starting program: /karmamaya/tmp/tgdb [New LWP 2] [LWP 2 exited] thread.c:598: internal-error: is_thread_state: Assertion `tp' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y thread.c:598: internal-error: is_thread_state: Assertion `tp' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) y simple test Abort (core dumped) The stack trace as given by dbx is: For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading gdb core file header read successfully Reading ld.so.1 Reading libintl.so.8.0.2 Reading libdl.so.1 Reading libncurses.so.5.7 Reading libz.so.1.2.5 Reading libsocket.so.1 Reading libnsl.so.1 Reading libm.so.2 Reading libiconv.so.2.5.0 Reading libresolv.so.2 Reading librt.so.1 Reading libpthread.so.1 Reading libpython2.6.so.1.0 Reading libexpat.so.1.5.2 Reading libc.so.1 Reading libsec.so.1 Reading libaio.so.1 Reading libmd.so.1 Reading libm.so.1 Reading libavl.so.1 Reading libc_db.so.1 t at 1 (l at 1) program terminated by signal ABRT (Abort) 0xfea19315: __lwp_kill+0x0015: jae __lwp_kill+0x23 [ 0xfea19323, .+0xe ] Current function is set_internal_problem_cmd 1229 { (dbx) where current thread: t at 1 [1] __lwp_kill(0x1, 0x6), at 0xfea19315 [2] _thr_kill(0x1, 0x6), at 0xfea14188 [3] raise(0x6), at 0xfe9c1d73 [4] abort(0x4, 0x8047590, 0x80475b8, 0x80989c0, 0x7fffffff, 0x7fffffff), at 0xfe9a1bbd =>[5] set_internal_problem_cmd(args = 0x1 "", from_tty = 6), line 1229 in "utils.c" [6] internal_vproblem(problem = (nil), file = 0x80475b8 "\xd8u^D^H\x94\x8a^I^HV^B", line = 598, fmt = 0x832b865 "%s: Assertion `%s' failed.", ap = 0x804760c "\xeeY+^Hb\xb82^H^B"), line 1176 in "utils.c" [7] internal_verror(file = (nil), line = 598, fmt = 0x832b865 "%s: Assertion `%s' failed.", ap = 0x804760c "\xeeY+^Hb\xb82^H^B"), line 1191 in "utils.c" [8] wrap_here(indent = (nil)), line 2302 in "utils.c" [9] is_stopped(ptid = RECORD), line 605 in "thread.c" [10] is_exited(ptid = RECORD), line 611 in "thread.c" [11] switch_to_thread(ptid = RECORD), line 899 in "thread.c" [12] startup_inferior(ntraps = 134510296), line 471 in "fork-child.c" [13] procfs_create_inferior(ops = 0x83dbf18, exec_file = 0x83d9648 "/karmamaya/tmp/tgdb", allargs = 0x8502410 "", env = 0x84f45b8, from_tty = 1), line 4714 in "procfs.c" [14] target_create_inferior(exec_file = (nil), args = 0x8047808 "Hx^D^H\xdc\xec^T^HH\x96=^H^P$P^H\xb8EO^H^A", env = 0x84f45b8, from_tty = 0), line 486 in "target.c" [15] run_command_1(args = (nil), from_tty = 0, tbreak_at_main = 0), line 565 in "infcmd.c" [16] execute_command(p = 0x83c7cb9 "", from_tty = 134510712), line 422 in "top.c" [17] command_handler(command = 0x8047898 "\xc8x^D^H\x9a~^V^H^T"), line 498 in "event-top.c" [18] command_line_handler(rl = 0x8502380 "r"), line 702 in "event-top.c" [19] rl_callback_read_char(), line 205 in "callback.c" [20] rl_callback_read_char_wrapper(client_data = (nil)), line 178 in "event-top.c" [21] handle_file_event(data = UNION), line 817 in "event-loop.c" [22] process_event(), line 399 in "event-loop.c" [23] gdb_do_one_event(data = (nil)), line 464 in "event-loop.c" [24] catch_errors(func = 0x8167244 = &gdb_do_one_event(void *data), func_args = (nil), errstring = 0x8320fd0 "", mask = 6), line 518 in "exceptions.c" [25] tui_command_loop(data = (nil)), line 171 in "tui-interp.c" [26] current_interp_command_loop(), line 291 in "interps.c" [27] captured_command_loop(data = (nil)), line 227 in "main.c" [28] catch_errors(func = 0x808f4e0 = &`gdb`main.c`captured_command_loop(void *data), func_args = (nil), errstring = 0x8318b53 "", mask = 6), line 518 in "exceptions.c" [29] captured_main(data = (nil)), line 910 in "main.c" [30] catch_errors(func = 0x808f518 = &`gdb`main.c`captured_main(register void *data), func_args = 0x8047b80, errstring = 0x8318b53 "", mask = 6), line 518 in "exceptions.c" [31] gdb_main(args = (nil)), line 919 in "main.c" [32] main(argc = 0, argv = (nil)), line 34 in "gdb.c" (dbx) quit After analysis of the source it appears that when a SHELL environment variable is found its content is used to execute gdb's inferior process and it waits on the first significant event. In our case, the content of SHELL is /opt/csw/bin/bash and as we can see the process tree of gdb is ptree $(pgrep gdb) ... 2725 /karmamaya/tmp/gdb-7.2/gdb/gdb /karmamaya/tmp/tgdb 2726 /opt/csw/bin/bash -c exec /karmamaya/tmp/tgdb and its process flags are: pflags 2726 : /opt/csw/bin/bash -c exec /karmamaya/tmp/tgdb data model = _ILP32 flags = RLC|MSACCT|MSFORK flttrace = 0xfffffbff sigtrace = 0x67c5deff 0x0000fff6 HUP|INT|QUIT|ILL|TRAP|ABRT|EMT|FPE|BUS|SEGV|SYS|PIPE|TERM|USR1|USR2|PWR|STOP|TSTP|CONT|TTIN|TTOU|XCPU|XFSZ|FREEZE|THAW|LOST|XRES|JVM1|JVM2|RTMIN|RTMIN+1|RTMIN+2|RTMIN+3|RTMAX-3|RTMAX-2|RTMAX-1|RTMAX entryset = 0x00000001 0x00000000 0x00000000 0x00000000 0x80000000 0x00000000 0x00000000 0x00000000 exitset = 0x00000400 0x04000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x00000000 0x00000000 /1: flags = STOPPED|ISTOP|ASLEEP lwp_wait(0x2,0x8047a8c) why = PR_REQUESTED /2: flags = STOPPED|ISTOP lwp_exit() why = PR_SYSENTRY what = lwp_exit sigmask = 0xffbffeff,0x0000ffff The first significant event is the entry in a system call, lwp_exit, and gdb's thread management removes the thread from the active list; however, and here is a logic fault, gdb tries to switch to the first thread of the inferior process to continue its execution which is to execute the debugged process; unfortunately the thread candidate toward which to change the context is the already dead thread, consequently its identifier is no more in the active thread list which triggers the assertion which aborts the program. It appears that this behavior is manifested only when we use an Open CSW bash and with the SUN provided version everything works correctly. Trussing a simple bash session (start and immediate exit): truss -u a.out -u ld:: -u :: -o bash-truss /opt/csw/bin/bash we observe the following sequence: lwp_create(0x080478A0, LWP_SUSPENDED, 0x08047AC4) = 2 /2: lwp_create() (returning as new lwp ...) = 0 /1: schedctl() = 0xFEFF4000 /1: lwp_continue(2) = 0 /2: setustack(0xFEAD0260) /2: schedctl() = 0xFEFF4010 /2: lwp_sigmask(SIG_SETMASK, 0xFFBFFEFF, 0x0000FFF7) = 0xFFBFFEFF [0x0000FFFF] /2: lwp_exit() /1: lwp_wait(2, 0x08047AF8) = 0 Setting a breakpoint in the thread creation: stop in __lwp_create reveals that the ephemeral thread is created when bash sets its text domain in bindtextdomain() from libintl from the ggettext package. After the dull exploration of of the corresponding sources we discover that, in order to test the library's behavior with regard to multi-threading, a singleton test is made in gettext-runtime/intl/lock.h: #if USE_POSIX_THREADS /* Use the POSIX threads library. */ # if PTHREAD_IN_USE_DETECTION_HARD /* The function to be executed by a dummy thread. */ static void * dummy_thread_func (void *arg) { return arg; } int glthread_in_use (void) { static int tested; static int result; /* 1: linked with -lpthread, 0: only with libc */ if (!tested) { pthread_t thread; if (pthread_create (&thread, NULL, dummy_thread_func, NULL) != 0) /* Thread creation failed. */ result = 0; else { /* Thread creation works. */ void *retval; if (pthread_join (thread, &retval) != 0) abort (); result = 1; } tested = 1; } return result; } # endif PTHREAD_IN_USE_DETECTION_HARD is defined in the configure script where we find this comment: # On Solaris and HP-UX, most pthread functions exist also in libc. # Therefore pthread_in_use() needs to actually try to create a # thread: pthread_create from libc will fail, whereas # pthread_create will actually create a thread. After verification it appears that libc prior to Solaris 10 contains the POSIX threads symbols but their definition are not operational which means that if the binary is not linked with libpthread the threading operations doesn't work and exactly this situation is tested in glthread_in_use() which is an astute but invasive, in our case, hack. Unfortunately, our support for Solaris 9 and the building of ggettext being done on that operating environment, makes that we face a delicate decision of how to make gdb operational when using an inferior shell which was linked with the libintl supplied by our ggettext. How to avoid this situation? There are the solution that I explored: 1. correct gdb's logic difficult to implement and the required tests are extensive 2. document the issue and recommend that when using gdb with a non Open CSW shell must be used the least costly and gives the opportunity to somebody else to test the other shells that we deliver 3. enforce programmatically that no Open CSW shell is used with gdb not very elegant but avoids surprises for the uninformed user; minimal programming effort: replace any Open CSW shell with /sbin/sh. 4. use the SUN provided libintl when linking our shells this is an elegant solution but doesn't fall in my perimeter of action and needs strong coordination with many maintainers, some which are maybe retired which forces me to take the responsibility for packages for which I'm less interested. 5. find another robust test for libpthread linkage in libintl Quite difficult and involves a lot a fudgin arround with symbols and other esoteric incantations (this is a complex and sensitive package). Finally I'm choosing 3 and, of course, 2... -- Peter From maciej at opencsw.org Thu Jan 6 21:07:21 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 6 Jan 2011 20:07:21 +0000 Subject: [csw-maintainers] addition to CSWcommon? In-Reply-To: References: <1292432556-sup-8979@pinkfloyd.chass.utoronto.ca> <1293825402-sup-4747@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 1 de Janeiro de 2011 17:29, Maciej (Matchek) Blizinski escreveu: > No dia 1 de Janeiro de 2011 14:00, Peter FELECAN > escreveu: >> "Maciej (Matchek) Blizinski" writes: >> >>> I agree that suggesting a gazillion unrelated looking packages might >>> be confusing. ?We could stop doing that and only report missing base >>> directories, but... if the right choice is to add a dependency, >>> finding the right dependency by hand is a PITA. ?(Unless you know >>> tricks such as "bin/pkgdb show filename /etc/opt/csw/init.d".) >> >> It's not a unknown trick if you give this exact information in your >> message helping the maintainer to find his way. > > I still fiddle a lot with the interface of pkgdb, and I was a bit > reluctant of revealing it to the world. ?This is a very good > suggestion, how about the following patch? (...) Turns out, it's not that easy. The patch I suggested does not work. We have to solve the general case of "CSWfoo needs path /opt/csw/bar". What checkpkg currently does, is that it explains the issue, and if the directory is already present in other packages, it suggests declaring a dependency one one of them; providing a full list and letting the maintainer choose which one. The code that handles it is generic, which means it works for all file types and doesn't care about the type of the needed file. The interface to the database is that you call GetPkgByPath("/opt/csw/lib/foo") and receive a list of packages: frozenset(["CSWfoo", "CSWbar", ...]). You can call it with /opt/csw/bin/python and it'll suggest CSWpython; in the future, you'll be able to call /opt/csw/bin/python3.1 and it'll suggest the dependency on CSWpython31. It's got a great potential. Making it smarter however will require changing the database interface; for example, each package name will need to be accompanied by some file metadata, e.g. file type such as 'f', 'd', or 's'. To make checkpkg output more useful, we can try to apply some heuristics, for example if one of the packages returned is CSWcommon, we can suggest just CSWcommon and not any other packages. From maciej at opencsw.org Fri Jan 7 00:57:10 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 6 Jan 2011 23:57:10 +0000 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> <1293979248-sup-9284@pinkfloyd.chass.utoronto.ca> <1294015617-sup-1020@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 3 de Janeiro de 2011 16:53, Philip Brown escreveu: > This would not be fair. I have no interest in any of the other 3 > formats; why should I work on those? Nor would I do a good job of them > if I were, since I have no experience using them. > The fair thing to do, is have the person "championing" each format, be > responsible, for putting together the sample for "their" format. > I'll be happy to put together the minimalist html version. > > There is the remaining issue first, of "what document layout shall we > use as the example?" I picked this wiki page: http://wiki.opencsw.org/shared-opt-csw-setup > I think this should be the responsibility of "The Secretary", or > possibly our web admin(s). But I would be willing to do that > additional work if they are not. It will just take longer if I do it. I've prepared a sample asciidoc-based package. http://buildfarm.opencsw.org/experimental/maciej/opencsw_policy-0.1,REV=2011.01.03-SunOS5.9-all-CSW.pkg.gz An example asciidoc-generated HTML is available on-line here: http://buildfarm.opencsw.org/~maciej/policy/ Is anyone up for creating examples of other markups? Maciej From phil at bolthole.com Fri Jan 7 01:07:24 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 6 Jan 2011 16:07:24 -0800 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: References: Message-ID: wow. some great detailed debug work there Peter. Thanks for writing that up. The results are a bit disturbing, and have a wider ramification. they suggest we may need to be more cautious in using gnu libintl across all our packages going forward. yikes. From maciej at opencsw.org Fri Jan 7 01:16:44 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 7 Jan 2011 00:16:44 +0000 Subject: [csw-maintainers] Intents to package In-Reply-To: References: Message-ID: No dia 4 de Janeiro de 2011 22:22, Philip Brown escreveu: > Certainly. But that has nothing to do with announcing "intend to package". > If that sort of problem comes up, it seems straightforward to make a > targetted email, > "I'm looking at packaging X, but run into problem Y. How would people > suggest I solve problem Y"? > > the subject should be more about "problem Y". the fact that it is > contained in "package X" is only peripheral information. This works as long as you know in advance what the problem is. In practice you often don't. For example, I would have never guessed that there would be a problem around files vs symlinks in /opt/csw/lib (in the mysql libraries thread[1]). I would have only hit it when trying to submit my package. Thanks to the ITP thread I was able to know about the issue in advance. You can say that it's a general issue with shared libraries, but we wouldn't come across it if we didn't consider the specific case of a package compiled in a custom prefix. [1] http://lists.opencsw.org/pipermail/maintainers/2011-January/013609.html From phil at bolthole.com Fri Jan 7 01:25:27 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 6 Jan 2011 16:25:27 -0800 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> <1293979248-sup-9284@pinkfloyd.chass.utoronto.ca> <1294015617-sup-1020@pinkfloyd.chass.utoronto.ca> Message-ID: thanks Maciej. I have to say the output of the asciidoc looks good. where can we see the raw? I'll try to put together the minimal HTML in a day or two From phil at bolthole.com Fri Jan 7 01:36:09 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 6 Jan 2011 16:36:09 -0800 Subject: [csw-maintainers] Intents to package In-Reply-To: References: Message-ID: On Thursday, January 6, 2011, Maciej (Matchek) Blizinski wrote: >> > This works as long as you know in advance what the problem is. ?In > practice you often don't. ?For example, I would have never guessed > that there would be a problem around files vs symlinks in /opt/csw/lib > (in the mysql libraries thread[1]). ?I would have only hit it when > trying to submit my package. ?Thanks to the ITP thread I was able to > know about the issue in advance. > > You can say that it's a general issue with shared libraries, but we > wouldn't come across it if we didn't consider the specific case of a > package compiled in a custom prefix. certainly for bigger packages it is useful to mention it and ask for any gotchas. I shouldn't say "never announce". I also wanted to avoid giving maintainers the impression that from now on they "have to announce". that might discourage people from experimenting with a new package, if they aren't initially sure they want to take it on. From maciej at opencsw.org Fri Jan 7 01:41:10 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 7 Jan 2011 00:41:10 +0000 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: No dia 2 de Janeiro de 2011 20:55, Philip Brown escreveu: > On Sun, Jan 2, 2011 at 2:06 AM, Maciej (Matchek) Blizinski > wrote: >> No dia 2 de Janeiro de 2011 01:52, Philip Brown escreveu: >>>>Are you serious? ?Is that a supported use case? >>> >>> well, there's "supported" , and then there's "users do odd things sometimes" :-) >>> >>> there are also some side benefits, such as, a 'du' on the mysql dir >>> will give accurate results for an admin who wants a quick check on >>> that sort of thing. ?there's probably other small benefits like that I >>> haven't thought about long enough to come up with. >> >> That's the problem: once you're committed to one solution over >> another, you have a tendency to keep on finding as many "reasons" for >> it as you like. ?I'm sure that if you thought for a minute, you would >> come up with an equal number of arguments for the opposite solution. >> > > well, how about _you_ think for a minute and see if you can actually > match your claims of "sure"ness then? > Your timer starts now. go! > > 60... > 59... > 58... > > :) > > Come on now, what you wrote is completely out of order. > Either come up with reasons, or let it go. you cant have a valid > argument with your statements above. > And putting the word "reasons" in quotes, is playing semantic games, > instead of discussing the issue rationally. I think it's silly. I can come up with a number of reasons for files in /opt/csw/lib, no problem, but that's not the point. The point is that you, Phil Brown, do not discuss issues rationally, and this discussion is one of many examples. You can always come up with logically true statements pointing in any direction. The number of variables in play is immense, and you can keep on adding new ones as you go along. You can always come up with a user doing something plausible, in which your solution would seem better. Ultimately, the actual reasons with which you come up with do not matter that much - what matters is that you send an e-mail that includes something having the appearance of an argument. Whoever gets tired first, loses. Coming up with new bogus arguments is easy. Coming up with new good arguments is hard, because you have to think them through, and throw away all the bad ones yourself. Therefore, the person who looks for good arguments, get's tired quicker, and the person making bad arguments wins. This kind of e-mail exchange is not a rational discussion. It's an endurance contest. From maciej at opencsw.org Fri Jan 7 02:12:48 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 7 Jan 2011 01:12:48 +0000 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: No dia 2 de Janeiro de 2011 20:55, Philip Brown escreveu: > Deal with the reasons on their merits, please? Let's have a factual > comparison of arguments for each way. Let's start with what shared libraries are and what they are for. Long story short, they are providing functionality to binaries. We have a standard place to keep them: /opt/csw/lib, with optional subdirectories for additional architectures, if necessary. When compiling new software, we're using the standard flags: -L/opt/csw/lib -R/opt/csw/lib which link against libraries in /opt/csw/lib and set the RPATH to look there. In principle, we could put shared libraries anywhere, but we wanted to make our lives easier and chose to have a standard place for them. There are some shared objects which are not public shared libraries; for example Kerberos ships libraries against which Kerberos binaries link, but other binaries don't. Therefore, we need to distinguish between private and public shared libraries. What should be the criteria for public shared libraries placement? If we chose to have a standard place, we should stick to it. Public shared libraries should be put under /opt/csw/lib, because only then they will be found during linking, without tweaking any environment variables and/or linker flags. Shared libraries have the status of a common resource, and once put into place, they serve many binaries and many packages. The original software that put them in place doesn't matter that much, because once any other package starts to link against them, they have to stay in place until the dependent binary goes away. The original package that provided them might even go away, but shared libraries have to stay. Taking all that into account, the packaging of shared libraries should be mainly driven by thinking about how these shared libraries are used by other packages and how well they integrate with the rest of CSW ecosystem. For example, a shared library under a custom prefix is not necessarily a good idea, because all programs that need to link against it, have to have a nonstandard RPATH, and the linking phase has to use nonstandard linker flags. For the sake of other maintainers, and us ourselves, we should place public shared libraries under /opt/csw/lib, and nowhere else. You can say that it's enough to place a symlink from /opt/csw/lib to another place that contains the binary file and programs will work - fine, but do we do that in other packages? We don't, we place the actual files directly under /opt/csw/lib. It's true that MySQL executables are under /opt/csw/mysql5, but it's an exception rather than a rule. If it was possible to keep these binaries directly under /opt/csw/bin, they would be kept there. MySQL binaries under /opt/csw/mysql/bin do not have their own shared libraries; they use a common resource, even though the common resource happens to be build from the same source tar file. Packages providing the MySQL shared libraries should be created according to the general rules of packaging shared libraries, and the rules is that you put them under /opt/csw/lib. Does it sound like a good reason? From maciej at opencsw.org Fri Jan 7 02:33:30 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 7 Jan 2011 01:33:30 +0000 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> <1293979248-sup-9284@pinkfloyd.chass.utoronto.ca> <1294015617-sup-1020@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 7 de Janeiro de 2011 00:25, Philip Brown escreveu: > thanks Maciej. > I have to say the output of the asciidoc looks good. where can we see the raw? You can view it on-line here: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/opencsw-policy/trunk/files/ It's also present in the package. I think it's a good idea to include both .txt sources and .html output inside the package. > I'll try to put together the minimal HTML ?in a day or two Cool. Is anyone else up for making a LaTeX or a DocBook example? From bwalton at opencsw.org Fri Jan 7 02:43:22 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 06 Jan 2011 20:43:22 -0500 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> <1293979248-sup-9284@pinkfloyd.chass.utoronto.ca> <1294015617-sup-1020@pinkfloyd.chass.utoronto.ca> Message-ID: <1294364296-sup-1456@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Thu Jan 06 20:33:30 -0500 2011: Hi Maciej, > Cool. Is anyone else up for making a LaTeX or a DocBook example? Thanks for the asciidoc. I wonder if Docbook is a good choice at all? Especially given that docbook can be derived from asciidoc? Does anyone else care enough about a specific format to enter a sample? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Jan 7 02:49:04 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 06 Jan 2011 20:49:04 -0500 Subject: [csw-maintainers] Intents to package In-Reply-To: References: Message-ID: <1294364723-sup-6215@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Jan 06 19:36:09 -0500 2011: > certainly for bigger packages it is useful to mention it and ask for > any gotchas. I shouldn't say "never announce". How about 'announce if you feel like it.' It doesn't hurt and can result in good discussion. We're not large enough to require ITP where the benefit is that you don't have multiple people doing the same work. The upside of an ITP for us is the ensuing discussion (if any). > I also wanted to avoid giving maintainers the impression that from > now on they "have to announce". that might discourage people from > experimenting with a new package, if they aren't initially sure they > want to take it on. Agreed. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Jan 7 04:16:13 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 6 Jan 2011 19:16:13 -0800 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> <1293979248-sup-9284@pinkfloyd.chass.utoronto.ca> <1294015617-sup-1020@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Jan 6, 2011 at 5:33 PM, Maciej (Matchek) Blizinski wrote: > No dia 7 de Janeiro de 2011 00:25, Philip Brown escreveu: >> thanks Maciej. >> I have to say the output of the asciidoc looks good. where can we see the raw? > > You can view it on-line here: > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/opencsw-policy/trunk/files/ > Could we standardize on one place to put this stuff, for purposes of our specific comparison for members please? Or at least one place for references. Maybe you could make one wiki page, with individual, direct links to "here's the reference" "here's the XYZ output" "here's the XYZ src" "here's the ABC output"... ? From phil at bolthole.com Fri Jan 7 04:53:45 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 6 Jan 2011 19:53:45 -0800 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: On Thu, Jan 6, 2011 at 5:12 PM, Maciej (Matchek) Blizinski wrote: > No dia 2 de Janeiro de 2011 20:55, Philip Brown escreveu: >> > You can say that it's enough to place a symlink from /opt/csw/lib to > another place that contains the binary file and programs will work - > fine, and that is indeed my position > do we do that in other packages? ?We don't, we place the > actual files directly under /opt/csw/lib. and that's not really any kind of deliberate decision or policy, but merely a convenient side effect of --prefix=/opt/csw for MOST packages. however, for packages where prefix != /opt/csw, we dont always do that. (in fact, I think we RARELY do that) > It's true that MySQL > executables are under /opt/csw/mysql5, but it's an exception rather > than a rule. Yes, this is exactly my point. programs with their own sub-prefix are special. Perhaps we should make a specific variation on our standards, for programs with sub-prefixes. Something like, "if shared libs are generated under $PREFIX != /opt/csw, it is recommended to create a symlink in /opt/csw/lib, pointing to the appropriate library" I will also point out, that our berkeleydb packages also keep their shared libs under their own subprefix, rather than keeping the actual .so files in /opt/csw/lib > MySQL binaries under /opt/csw/mysql/bin do not have their own shared > libraries; ahh.. actually, many of them use libmysqlclient. Perhaps you did a check "ldd /opt/csw/mysql/bin/*", but forgot they are using isaexec? but if on other hand you check like this... bender$ ldd /opt/csw/mysql5/bin/sparcv8/mysql|grep mysql libmysqlclient.so.15 => /opt/csw/mysql5/lib/sparcv8/mysql/libmysqlclient.so.15 Perhaps you meant they do not use "private" shared libraries? From pfelecan at opencsw.org Fri Jan 7 09:23:59 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 07 Jan 2011 09:23:59 +0100 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: (Philip Brown's message of "Thu, 6 Jan 2011 16:07:24 -0800") References: Message-ID: Philip Brown writes: > wow. some great detailed debug work there Peter. Thanks for writing that up. > The results are a bit disturbing, and have a wider ramification. they > suggest we may need to be more cautious in using gnu libintl across > all our packages going forward. yikes. I think that we can use libintl without much worry; the kludgy way that they use to alleviate a SUN libc issue will fade away when the support for Solaris 9 is terminated. Anyway, caution is always a good stance. -- Peter From pfelecan at opencsw.org Fri Jan 7 09:29:22 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 07 Jan 2011 09:29:22 +0100 Subject: [csw-maintainers] addition to CSWcommon? In-Reply-To: (Maciej Blizinski's message of "Thu, 6 Jan 2011 20:07:21 +0000") References: <1292432556-sup-8979@pinkfloyd.chass.utoronto.ca> <1293825402-sup-4747@pinkfloyd.chass.utoronto.ca> Message-ID: "Maciej (Matchek) Blizinski" writes: > No dia 1 de Janeiro de 2011 17:29, Maciej (Matchek) Blizinski > escreveu: >> No dia 1 de Janeiro de 2011 14:00, Peter FELECAN >> escreveu: >>> "Maciej (Matchek) Blizinski" writes: >>> >>>> I agree that suggesting a gazillion unrelated looking packages might >>>> be confusing. ?We could stop doing that and only report missing base >>>> directories, but... if the right choice is to add a dependency, >>>> finding the right dependency by hand is a PITA. ?(Unless you know >>>> tricks such as "bin/pkgdb show filename /etc/opt/csw/init.d".) >>> >>> It's not a unknown trick if you give this exact information in your >>> message helping the maintainer to find his way. >> >> I still fiddle a lot with the interface of pkgdb, and I was a bit >> reluctant of revealing it to the world. ?This is a very good >> suggestion, how about the following patch? (...) > Making it smarter however will require changing the database > interface; for example, each package name will need to be accompanied > by some file metadata, e.g. file type such as 'f', 'd', or 's'. I think that now is the time to put all the relevant information in the database. BTW, when dealing with package content having no information about their type is an evident gap. > To make checkpkg output more useful, we can try to apply some > heuristics, for example if one of the packages returned is CSWcommon, > we can suggest just CSWcommon and not any other packages. Hail to the heuristics! -- Peter From pfelecan at opencsw.org Fri Jan 7 09:43:41 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 07 Jan 2011 09:43:41 +0100 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: (Maciej Blizinski's message of "Thu, 6 Jan 2011 23:57:10 +0000") References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> <1293979248-sup-9284@pinkfloyd.chass.utoronto.ca> <1294015617-sup-1020@pinkfloyd.chass.utoronto.ca> Message-ID: "Maciej (Matchek) Blizinski" writes: > I picked this wiki page: > http://wiki.opencsw.org/shared-opt-csw-setup > >> I think this should be the responsibility of "The Secretary", or >> possibly our web admin(s). But I would be willing to do that >> additional work if they are not. It will just take longer if I do it. > An example asciidoc-generated HTML is available on-line here: > > http://buildfarm.opencsw.org/~maciej/policy/ Nice, I've looked to the source which is in fact in the package as shared-csw-opt.txt, am I right?, and everything seems simple. What I don't like is that in the table, the first column, which is an auto-incremented counter, is given explicitly; is there something like automatic enumertations? > Is anyone up for creating examples of other markups? Frankly, I will not spend my time on creating a full LaTeX based version as for what we need asciidoc is enough. Nothing precludes that for more sophisticated documents I'll use my dear old and quite perfect TeX macros. -- Peter From pfelecan at opencsw.org Fri Jan 7 13:47:44 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 07 Jan 2011 13:47:44 +0100 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: (Dagobert Michelsen's message of "Wed, 5 Jan 2011 10:27:49 +0100") References: Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 04.01.2011 um 20:21 schrieb Peter FELECAN: >> As nobody answered positively to my question "is somebody working on >> gdb?" of December 20th, I declare the intent to package the new version >> of gdb and consequently take over the package maintenanceship (the >> current maintainer is retired). > > Sure, please go ahead. I tried to make an gdb 6.8, but it crashed quite > often. Additionally, it may be advisable to use the (non-trivial!) patches > from OpenSolaris for gdb, which are also listed in the gdb description > in GAR: > http://cvs.opensolaris.org/source/xref/sfw/usr/src/cmd/gdb/ The OpenSolaris patches are made for 6.8; I explored the opportunity to apply them on the 7.2 base and here are the conclusions: - gdb.solib-svr4.patch succeeds but refers to old variable names and the SPARC part is already implemented; consequently I cherry pick by hand and adapt to the new upstream source - gdb.fork-child.c.patch succeeds but need to be extended to an additional test toward /opt/csw/bin/isaexec which will be another patch and, finally a patch for replacing any /opt/csw rooted shell by /sbin/sh alleviating the issue with libintl dynamic POSIX thread detection - gdb.auxv.c.patch this is already implemented in a more elegant way by upstream; anyhow, the patch fails as is. Finally, I applied 2 minor patches to alleviate configuration issues related with our compilation chain. -- Peter From bwalton at opencsw.org Fri Jan 7 14:42:57 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 07 Jan 2011 08:42:57 -0500 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: References: Message-ID: <1294407750-sup-7734@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Fri Jan 07 03:23:59 -0500 2011: > I think that we can use libintl without much worry; the kludgy way > that they use to alleviate a SUN libc issue will fade away when the > support for Solaris 9 is terminated. Anyway, caution is always a > good stance. I have a mostly up-to-date build description for ggettext ready to go, but I stalled it while waiting for the arbitration results. It needs a bit of testing yet too. I think this package would benefit from being built separately on sol9 and sol10 so that this issue only affects sol9. I'll try to get back to this, but if someone else wants to pick it up, most of the work is done already. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Jan 7 15:51:10 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 7 Jan 2011 06:51:10 -0800 Subject: [csw-maintainers] ITP: opencsw-policy In-Reply-To: References: <1293824639-sup-9744@pinkfloyd.chass.utoronto.ca> <1293938145-sup-390@pinkfloyd.chass.utoronto.ca> <1293979248-sup-9284@pinkfloyd.chass.utoronto.ca> <1294015617-sup-1020@pinkfloyd.chass.utoronto.ca> Message-ID: Another related thought: if we're standardizing on doc format... it would be nice to standardize across the board. Is it possible to have a wiki that uses asciidoc? Or to go the other way, is there some command-line tool to generate (text, web) from a file in some wiki language? From william at wbonnet.net Fri Jan 7 17:27:17 2011 From: william at wbonnet.net (William Bonnet) Date: Fri, 7 Jan 2011 17:27:17 +0100 Subject: [csw-maintainers] [RFE] Add version to gmake pkglist output Message-ID: <6C8F1E54-F0DE-4E1C-9B3F-5D3F0E55475C@wbonnet.net> Hi all, I would to suggest this evolution to the output of the pkglist gar target. Add a fourth column with version information Current output is : [wbonnet at current9s:~/gar/pkg/cpan/Object-Accessor/trunk]$ gmake pkglist /home/wbonnet/gar/pkg/cpan/Object-Accessor/trunk pm_objaccessor CSWpmobjaccessor It would become [wbonnet at current9s:~/gar/pkg/cpan/Object-Accessor/trunk]$ gmake pkglist /home/wbonnet/gar/pkg/cpan/Object-Accessor/trunk pm_objaccessor CSWpmobjaccessor 0.36 Any thoughts ? cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From william at wbonnet.net Sat Jan 8 02:41:07 2011 From: william at wbonnet.net (William Bonnet) Date: Sat, 08 Jan 2011 02:41:07 +0100 Subject: [csw-maintainers] CPAN package using GAR v1 Message-ID: <4D27C0B3.1060908@wbonnet.net> Hi There are a lot of CPAN packages in GAR which are still using GAR V1. I am wondering about doing a mass update of these package to switch them to Gar V2. Without any other modification at the same time. Only switch to V2, and only for packages under cpan. Does some mind about this ? Cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From pfelecan at opencsw.org Sat Jan 8 10:43:30 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 08 Jan 2011 10:43:30 +0100 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: <1294407750-sup-7734@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Fri, 07 Jan 2011 08:42:57 -0500") References: <1294407750-sup-7734@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Peter FELECAN's message of Fri Jan 07 03:23:59 -0500 2011: > >> I think that we can use libintl without much worry; the kludgy way >> that they use to alleviate a SUN libc issue will fade away when the >> support for Solaris 9 is terminated. Anyway, caution is always a >> good stance. > > I have a mostly up-to-date build description for ggettext ready to go, > but I stalled it while waiting for the arbitration results. It needs > a bit of testing yet too. > > I think this package would benefit from being built separately on sol9 > and sol10 so that this issue only affects sol9. I'll try to get back > to this, but if someone else wants to pick it up, most of the work is > done already. I don't think that is necessary to have separate packages. In the code that I cited in my detailed mail, you can add a run-time detection of the release of Solaris on which it actually runs and act accordingly. I can provide an easy patch , preferably for 0.18.1. If we validate this, we can submit the patch upstream. -- Peter From bonivart at opencsw.org Sat Jan 8 11:58:19 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 8 Jan 2011 11:58:19 +0100 Subject: [csw-maintainers] CPAN package using GAR v1 In-Reply-To: <4D27C0B3.1060908@wbonnet.net> References: <4D27C0B3.1060908@wbonnet.net> Message-ID: On Sat, Jan 8, 2011 at 2:41 AM, William Bonnet wrote: > Hi > > There are a lot of CPAN packages in GAR which are still using GAR V1. I am > wondering about doing a mass update of these package to switch them to Gar > V2. Without any other modification at the same time. Only switch to V2, and > only for packages under cpan. > > Does some mind about this ? Not at all, I'm assuming all of them are from retired maintainers so just to list them would be a good start. We have a list at http://wiki.opencsw.org/project-perl with modules needing an update. If you could produce a list of GAR V1 packages I'm interested in adding them to that list for a complete update as well. /peter From dam at opencsw.org Sat Jan 8 13:20:18 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 8 Jan 2011 13:20:18 +0100 Subject: [csw-maintainers] CPAN package using GAR v1 In-Reply-To: References: <4D27C0B3.1060908@wbonnet.net> Message-ID: Hi, Am 08.01.2011 um 11:58 schrieb Peter Bonivart: > On Sat, Jan 8, 2011 at 2:41 AM, William Bonnet wrote: >> Hi >> >> There are a lot of CPAN packages in GAR which are still using GAR V1. I am >> wondering about doing a mass update of these package to switch them to Gar >> V2. Without any other modification at the same time. Only switch to V2, and >> only for packages under cpan. >> >> Does some mind about this ? > > Not at all, I'm assuming all of them are from retired maintainers so > just to list them would be a good start. > > We have a list at http://wiki.opencsw.org/project-perl with modules > needing an update. If you could produce a list of GAR V1 packages I'm > interested in adding them to that list for a complete update as well. I have a draft for an auto-dependency-tool for Perl modules, which needs some rewriting to access Maciejs database. It should be used to updated and verify the dependency list. And we should cleanup the package names and deprecate all old ones. Best regards -- Dago From dam at opencsw.org Sat Jan 8 13:20:53 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 8 Jan 2011 13:20:53 +0100 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: References: <1294407750-sup-7734@pinkfloyd.chass.utoronto.ca> Message-ID: <881332CF-A1CC-4B28-B191-14D854265DBD@opencsw.org> Hi Peter, Am 08.01.2011 um 10:43 schrieb Peter FELECAN: > Ben Walton writes: > >> Excerpts from Peter FELECAN's message of Fri Jan 07 03:23:59 -0500 2011: >> >>> I think that we can use libintl without much worry; the kludgy way >>> that they use to alleviate a SUN libc issue will fade away when the >>> support for Solaris 9 is terminated. Anyway, caution is always a >>> good stance. >> >> I have a mostly up-to-date build description for ggettext ready to go, >> but I stalled it while waiting for the arbitration results. It needs >> a bit of testing yet too. >> >> I think this package would benefit from being built separately on sol9 >> and sol10 so that this issue only affects sol9. I'll try to get back >> to this, but if someone else wants to pick it up, most of the work is >> done already. > > I don't think that is necessary to have separate packages. In the code > that I cited in my detailed mail, you can add a run-time detection of > the release of Solaris on which it actually runs and act accordingly. I > can provide an easy patch , preferably for 0.18.1. If we validate this, > we can submit the patch upstream. That would be excellent!! Best regards -- Dago From pfelecan at opencsw.org Sat Jan 8 14:06:55 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 08 Jan 2011 14:06:55 +0100 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: <881332CF-A1CC-4B28-B191-14D854265DBD@opencsw.org> (Dagobert Michelsen's message of "Sat, 8 Jan 2011 13:20:53 +0100") References: <1294407750-sup-7734@pinkfloyd.chass.utoronto.ca> <881332CF-A1CC-4B28-B191-14D854265DBD@opencsw.org> Message-ID: Dagobert Michelsen writes: > Am 08.01.2011 um 10:43 schrieb Peter FELECAN: >> Ben Walton writes: >>> Excerpts from Peter FELECAN's message of Fri Jan 07 03:23:59 -0500 2011: >>> >>>> I think that we can use libintl without much worry; the kludgy way >>>> that they use to alleviate a SUN libc issue will fade away when the >>>> support for Solaris 9 is terminated. Anyway, caution is always a >>>> good stance. >>> >>> I have a mostly up-to-date build description for ggettext ready to go, >>> but I stalled it while waiting for the arbitration results. It needs >>> a bit of testing yet too. >>> >>> I think this package would benefit from being built separately on sol9 >>> and sol10 so that this issue only affects sol9. I'll try to get back >>> to this, but if someone else wants to pick it up, most of the work is >>> done already. >> >> I don't think that is necessary to have separate packages. In the code >> that I cited in my detailed mail, you can add a run-time detection of >> the release of Solaris on which it actually runs and act accordingly. I >> can provide an easy patch , preferably for 0.18.1. If we validate this, >> we can submit the patch upstream. > > That would be excellent!! Note that I'll publicly provide the patch only on request from the person who intent to package a new gettext set based on 0.18.1 or greater. -- Peter From maciej at opencsw.org Sat Jan 8 16:24:18 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 8 Jan 2011 15:24:18 +0000 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: No dia 7 de Janeiro de 2011 03:53, Philip Brown escreveu: > On Thu, Jan 6, 2011 at 5:12 PM, Maciej (Matchek) Blizinski > wrote: >> No dia 2 de Janeiro de 2011 20:55, Philip Brown escreveu: >>> >> You can say that it's enough to place a symlink from /opt/csw/lib to >> another place that contains the binary file and programs will work - >> fine, > > and that is indeed my position > >> do we do that in other packages? ?We don't, we place the >> actual files directly under /opt/csw/lib. > > and that's not really any kind of deliberate decision or policy, but > merely a convenient side effect of > ?--prefix=/opt/csw > for MOST packages. Deploying a vital component of the csw ecosystem based on a side effect doesn't sound like a good idea. Just like you don't change things in packages just because checkpkg said so, you don't plan your layout just because the install script happened to put them there. Quite often the result of install script's work will be aligned with what we won't, but this is a convenience rather than a good way to create packages. Ultimately, files end up at the locations of our deliberate choice. If we haven't made a decision regarding shared libraries, let's take a look at this issue now. > however, for packages where prefix != /opt/csw, we dont always do that. > (in fact, I think we RARELY do that) > > > >> It's true that MySQL >> executables are under /opt/csw/mysql5, but it's an exception rather >> than a rule. > > Yes, this is exactly my point. programs with their own sub-prefix are > special. Perhaps we should make a specific variation on our standards, > for programs with sub-prefixes. > Something like, "if shared libs are generated under $PREFIX != > /opt/csw, it is recommended > ?to create a symlink in /opt/csw/lib, pointing to the appropriate library" Why are you thinking in terms of "shared libs are generated under"? Isn't it better to think of shared libraries as a shared resource, without obscuring the logic with prefixes? > I will also point out, that our berkeleydb packages also keep their > shared libs under their own subprefix, rather than keeping the actual > .so files in /opt/csw/lib My personal opinion is that this is a suboptimal layout. Just that we used to do something doesn't mean that it's the right thing to do. >> MySQL binaries under /opt/csw/mysql/bin do not have their own shared >> libraries; > > > ahh.. actually, many of them use libmysqlclient. > > Perhaps you did a check "ldd /opt/csw/mysql/bin/*", but forgot they > are using isaexec? > > but if on other hand you check like this... > > bender$ ldd /opt/csw/mysql5/bin/sparcv8/mysql|grep mysql > ? ? ? ?libmysqlclient.so.15 => > /opt/csw/mysql5/lib/sparcv8/mysql/libmysqlclient.so.15 > > > Perhaps you meant they do not use "private" shared libraries? Yes. What I meant is that they use libmysqlient, and that libmysqlclient is not a private, MySQL's own thing, but rather a public, common resource. It's indeed used by MySQL executables, but not only. There are other executables that also use them. The fact that some users of a common resource are special, doesn't mean that the resource should be. From phil at bolthole.com Sat Jan 8 17:38:06 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 8 Jan 2011 08:38:06 -0800 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: On Sat, Jan 8, 2011 at 7:24 AM, Maciej (Matchek) Blizinski wrote: > No dia 7 de Janeiro de 2011 03:53, Philip Brown escreveu: > >> and that's not really any kind of deliberate decision or policy, but >> merely a convenient side effect of >> ?--prefix=/opt/csw >> for MOST packages. > > Deploying a vital component of the csw ecosystem based on a side > effect doesn't sound like a good idea. ... >>?If we haven't made a decision regarding shared > libraries, let's take a look at this issue now. I agree, now seems like a good time to examine this >>> It's true that MySQL >>> executables are under /opt/csw/mysql5, but it's an exception rather >>> than a rule. >> >> Yes, this is exactly my point. programs with their own sub-prefix are >> special. Perhaps we should make a specific variation on our standards, >> for programs with sub-prefixes. >> Something like, "if shared libs are generated under $PREFIX != >> /opt/csw, it is recommended >> ?to create a symlink in /opt/csw/lib, pointing to the appropriate library" > > Why are you thinking in terms of "shared libs are generated under"? By that I mean [naturally generated there by the program's config/installer, if we do nothing but specify --prefix=/opt/csw/subprefix] > Isn't it better to think of shared libraries as a shared resource, > without obscuring the logic with prefixes? I think this is an area where we have two "valid" ways of proceeding -- valid in the sense of "can be considered a consistent methodology" at least -- and so this issue becomes a little more flavored by "taste" vs purely technical. Certainly, it is "consistent" to declare "all 'public' linkable shared libraries must be in /opt/csw/lib directly". But it's not particularly beneficial, beyond a trivial goal of robotic consistency. and it blocks other goals. Such as, consistency of prefix. Some types of consistency are mutually exclusive. For example, the consistency of, "If a program, or program suite, has been sub-prefixed, then all (non-dynamic) files for it should live under that subprefix". This is a reasonably expected, even presumed consistency by a user. We're going to have to break one set of consistency rules, one way or another. So proceeding merely on "must keep things consistent" is inadequate. It seems to make more sense to determine this issue based on potential benefits/goals. more lower down. >> I will also point out, that our berkeleydb packages also keep their >> shared libs under their own subprefix, rather than keeping the actual >> .so files in /opt/csw/lib > > My personal opinion is that this is a suboptimal layout. ?Just that we > used to do something doesn't mean that it's the right thing to do. well, I agree to the extent that I think it may make life easier to have "something" in /opt/csw/lib for them. We just differ in that I think the "something" should be a symlink :) Maciej, it sounds like you are mixing goal objective, with implementation. Isnt your real goal, "to have standardized linking, -R/opt/csw/lib whereever possible"? Why not just say "okay symlinks meet that goal", without insisting it also be done by your preferred methodology? >> Perhaps you meant they do not use "private" shared libraries? > > Yes. > > What I meant is that they use libmysqlient, and that libmysqlclient is > not a private, MySQL's own thing, but rather a public, common > resource. ?It's indeed used by MySQL executables, but not only. ?There > are other executables that also use them. > > The fact that some users of a common resource are special, doesn't > mean that the resource should be. okay, back to listing potential target "goals" for library policy. Someone, perhaps you, mentioned something earlier about everyone using packages as a delivery system. What you might not consider, is that the packages can be a "one-time" delivery system only. Some people run a package update once a year, and then forget about packages. Or, have "the sysadmin group" install packages, but they themselves know *nothing about packages*. Or, the packages may have been delivered to a template system, which is then filesystem-level duplicated in a sort of production line methodology, and targets know nothing about packages. Or, /opt/csw may be shared/duplicated out by other methods, and again, the target systems know nothing about packages. In all these kinds of situations, to help our users have an "easy to use" experience, we need to make sure our deliverables make sense on purely a filesystem basis. The users probably care nothing about linking. They just want things to be consistent from *their* perspective. I would argue that from that perspective, "everything associated with /opt/csw/foo, 'lives' under /opt/csw/foo", is the most consistent. and helpful. I myself have done a quickie "hmm, wonder how much stuff is under there? du -k /some/prefix" and then been **really annoyed** when I found out later, that not everything was in there. This is real world stuff, not just random hypotheticals I'm tossing around. From bwalton at opencsw.org Sat Jan 8 18:43:53 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 08 Jan 2011 12:43:53 -0500 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: <1294508600-sup-5407@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Jan 08 11:38:06 -0500 2011: > Maciej, it sounds like you are mixing goal objective, with > implementation. Isnt your real goal, "to have standardized linking, > -R/opt/csw/lib whereever possible"? I think this is Maciej's goal, but for something (like mysql) that already lives in a separate prefix and requires -I/opt/csw/$foo/include, etc how much value is one less -R? To this end, I think that as long as the bulk of the package is delivered to a special prefix, the real libraries should live there too. A symlink from /opt/csw/lib as a convenience doesn't hurt, but I don't see much benefit to doing that either. > In all these kinds of situations, to help our users have an "easy to > use" experience, we need to make sure our deliverables make sense on > purely a filesystem basis. I disagree with this. Our job is providing packages. Our job is _not_ to make things easier to replicate with tools other than the packaging system. I think we need to focus on what the packages provide and how they behave in the rest of the package ecosystem, not on what people may choose to do at $random_site_x. While placing all of the 'special prefix' files under the special prefix does make things like this easier, it shouldn't be either the point or even a guiding principle. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Jan 8 22:54:57 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 08 Jan 2011 16:54:57 -0500 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> Message-ID: <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Thu Jan 06 03:34:33 -0500 2011: > It would be nice if the board organize a vote on this issue and we close > the discussion with a decision. I just setup the ballotbin for this. You've likely already received the email from them. The vote is open to any member listed here http://wiki.opencsw.org/open-community-software-project-members that is not retired. If you haven't received the mail from ballotbin and are listed, please let me know. The vote is open from the 9th - 13th inclusive. As with the board vote, I have no indication of time zone handling for this, so I made it a 4 day window that includes weekend and weekday times. Let me know if you have any problems. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Sat Jan 8 23:57:37 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 8 Jan 2011 23:57:37 +0100 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: References: <1294407750-sup-7734@pinkfloyd.chass.utoronto.ca> <881332CF-A1CC-4B28-B191-14D854265DBD@opencsw.org> Message-ID: Hi Peter, Am 08.01.2011 um 14:06 schrieb Peter FELECAN: > Dagobert Michelsen writes: >> Am 08.01.2011 um 10:43 schrieb Peter FELECAN: >>> Ben Walton writes: >>>> Excerpts from Peter FELECAN's message of Fri Jan 07 03:23:59 -0500 2011: >>>> >>>>> I think that we can use libintl without much worry; the kludgy way >>>>> that they use to alleviate a SUN libc issue will fade away when the >>>>> support for Solaris 9 is terminated. Anyway, caution is always a >>>>> good stance. >>>> >>>> I have a mostly up-to-date build description for ggettext ready to go, >>>> but I stalled it while waiting for the arbitration results. It needs >>>> a bit of testing yet too. >>>> >>>> I think this package would benefit from being built separately on sol9 >>>> and sol10 so that this issue only affects sol9. I'll try to get back >>>> to this, but if someone else wants to pick it up, most of the work is >>>> done already. >>> >>> I don't think that is necessary to have separate packages. In the code >>> that I cited in my detailed mail, you can add a run-time detection of >>> the release of Solaris on which it actually runs and act accordingly. I >>> can provide an easy patch , preferably for 0.18.1. If we validate this, >>> we can submit the patch upstream. >> >> That would be excellent!! > > Note that I'll publicly provide the patch only on request from the > person who intent to package a new gettext set based on 0.18.1 or > greater. As Ben already did most of the work I'll of course let him the honour of submitting it :-) Of course I lend him a hand if necesssary, so you can already start patching! Best regards -- Dago From phil at bolthole.com Sun Jan 9 00:24:07 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 8 Jan 2011 15:24:07 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jan 8, 2011 at 1:54 PM, Ben Walton wrote: > Excerpts from Peter FELECAN's message of Thu Jan 06 03:34:33 -0500 2011: > >> It would be nice if the board organize a vote on this issue and we close >> the discussion with a decision. > > I just setup the ballotbin for this. ?You've likely already received > the email from them. ?The vote is open to any member listed here > http://wiki.opencsw.org/open-community-software-project-members that > is not retired. > I havent looked at the specific ballot yet, so this is only a general comment: unfairly worded ballots, can unfairly bias voting. As a general principle, it is usually a good idea to have someone from each side of an issue review the wording, before an official vote on an issue is opened. From bwalton at opencsw.org Sun Jan 9 01:03:06 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 08 Jan 2011 19:03:06 -0500 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> Message-ID: <1294531223-sup-1547@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Jan 08 18:24:07 -0500 2011: > unfairly worded ballots, can unfairly bias voting. Understood. I tried to write this in am impartial manner. > As a general principle, it is usually a good idea to have someone > from each side of an issue review the wording, before an official > vote on an issue is opened. Noted; I'll do this next time. I did run this wording past Maciej and Ihsan. In the meantime, here are the ballot options, since this isn't a secret: 1. Files and directories are allowed to be delivered to /var/opt/csw directly by the prototype of a package. 2. Directories may be delivered to /var/opt/csw by the prototype of a package, but files may not. 3. Neither files nor directories may be delivered to /var/opt/csw by the prototype of a package. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From william at wbonnet.net Sun Jan 9 03:03:29 2011 From: william at wbonnet.net (William Bonnet) Date: Sun, 09 Jan 2011 03:03:29 +0100 Subject: [csw-maintainers] CPAN package using GAR v1 In-Reply-To: References: <4D27C0B3.1060908@wbonnet.net> Message-ID: <4D291771.80601@wbonnet.net> Hi > We have a list at http://wiki.opencsw.org/project-perl with modules > needing an update. If you could produce a list of GAR V1 packages I'm > interested in adding them to that list for a complete update as well. The switch has been done. Here is attached the list of packages from v1 and there status. 63 packages need to be update. This number can have a little error since 3 packages failed the upstream test. And uwatch2 does not detect yet change of cpan maintainer. This will be fixed in a couple of days. If you are interested in auto bumping the version let me know, it is available but not yet in production. cheers W. AnyData : Package is up-to-date. Current version is 0.10 Apache-AuthPAM : Package is up-to-date. Current version is 0.01 Apache-PAR : Package is up-to-date. Current version is 0.30 Apache-Session : A new version of upstream files is available. Package can be upgraded from version 1.6 to 1.54 Apache-Template : Package is up-to-date. Current version is 0.09 Apache-Test : A new version of upstream files is available. Package can be upgraded from version 1.30 to 1.34 Archive-Extract : A new version of upstream files is available. Package can be upgraded from version 0.16 to 0.34 Archive-SelfExtract : Package is up-to-date. Current version is 1.3 Array-Compare : A new version of upstream files is available. Package can be upgraded from version 1.13 to 2.01 Array-Window : A new version of upstream files is available. Package can be upgraded from version 1.00 to 1.02 Attribute-Handlers : Package is up-to-date. Current version is 0.78 Bit-Vector : Package is up-to-date. Current version is 7.1 BSD-Resource : A new version of upstream files is available. Package can be upgraded from version 1.28 to 1.2904 C-Scan : Package is up-to-date. Current version is 0.74 Cache : Package is up-to-date. Current version is 2.04 Cache-Memcached : A new version of upstream files is available. Package can be upgraded from version 1.18 to 1.28 Carp-Clan : Package is up-to-date. Current version is 6.04 Catalyst : Package is up-to-date. Current version is 5.61 CGI.pm : A new version of upstream files is available. Package can be upgraded from version 3.27 to 3.50 CGI-Application : A new version of upstream files is available. Package can be upgraded from version 4.06 to 4.31 CGI-Application-Dispatch : A new version of upstream files is available. Package can be upgraded from version 2.10 to 2.12 CGI-Application-Plugin-LogDispatch : A new version of upstream files is available. Package can be upgraded from version 1.00 to 1.02 CGI-Builder : Package is up-to-date. Current version is 1.36 CGI-SpeedyCGI : Package is up-to-date. Current version is 2.22 CGP-CLI : Package is up-to-date. Current version is 2.7.5 Class-BlackHole : Package is up-to-date. Current version is 0.04 Class-DBI : Package is up-to-date. Current version is 3.0.3 Class-DBI-Loader : Package is up-to-date. Current version is 0.03 Class-DBI-mysql : Package is up-to-date. Current version is 1.00 Class-DBI-Pg : Package is up-to-date. Current version is 0.03 Class-DBI-SQLite : Package is up-to-date. Current version is 0.11 Class-ISA : Package is up-to-date. Current version is 0.33 Class-Loader : Package is up-to-date. Current version is 2.03 Class-Trigger : A new version of upstream files is available. Package can be upgraded from version 0.11 to 0.14 Class-WhiteHole : Package is up-to-date. Current version is 0.04 Config-IniFiles : Package is up-to-date. Current version is 2.38 Convert-ASCII-Armour : Package is up-to-date. Current version is 1.4 Convert-PEM : A new version of upstream files is available. Package can be upgraded from version 0.07 to 0.08 Crypt-DES : Package is up-to-date. Current version is 2.05 Crypt-DES_EDE3 : Package is up-to-date. Current version is 0.01 Crypt-DH : Package is up-to-date. Current version is 0.06 Crypt-DSA : Package is up-to-date. Current version is 0.14 Crypt-OpenPGP : A new version of upstream files is available. Package can be upgraded from version 1.03 to 1.06 Crypt-OpenSSL-DSA : Package is up-to-date. Current version is 0.13 Crypt-OpenSSL-PKCS12 : A new version of upstream files is available. Package can be upgraded from version 0.3 to 0.5 Crypt-OpenSSL-X509 : A new version of upstream files is available. Package can be upgraded from version 0.4 to 1.6 Crypt-Primes : Package is up-to-date. Current version is 0.50 Crypt-Random : Package is up-to-date. Current version is 1.25 Crypt-Rijndael : Package is up-to-date. Current version is 1.09 Crypt-RIPEMD160 : Package is up-to-date. Current version is 0.04 Crypt-RSA : A new version of upstream files is available. Package can be upgraded from version 1.58 to 1.99 Crypt-SSLeay : Package is up-to-date. Current version is 0.57 Crypt-Twofish : A new version of upstream files is available. Package can be upgraded from version 2.12 to 2.14 Curses : Package is up-to-date. Current version is 1.06 Curses-UI : Package is up-to-date. Current version is 0.95 Data-Buffer : Package is up-to-date. Current version is 0.04 Data-Dump : A new version of upstream files is available. Package can be upgraded from version 1.08 to 1.19 Data-Flow : A new version of upstream files is available. Package can be upgraded from version 0.09 to 1.02 Data-ShowTable : Package is up-to-date. Current version is 3.3 Data-UUID : A new version of upstream files is available. Package can be upgraded from version 1.203 to 1.217 Date-Calc : Package is up-to-date. Current version is 6.3 Date-Simple : Package is up-to-date. Current version is 3.02 DBD-AnyData : A new version of upstream files is available. Package can be upgraded from version 0.08 to 0.09 DBD-CSV : A new version of upstream files is available. Package can be upgraded from version 0.22 to 0.2002 DBD-File : Package is up-to-date. Current version is 0.35 DBD-mysql : A new version of upstream files is available. Package can be upgraded from version 3.0006 to 4.018 DBIx-ContextualFetch : Package is up-to-date. Current version is 1.03 DBIx-Password : A new version of upstream files is available. Package can be upgraded from version 1.8 to 1.9 DBIx-SearchBuilder : A new version of upstream files is available. Package can be upgraded from version 1.45 to 1.54 Devel-Cover : A new version of upstream files is available. Package can be upgraded from version 0.65 to 0.73 Devel-Cycle : A new version of upstream files is available. Package can be upgraded from version 1.07 to 1.11 Devel-LeakTrace : Package is up-to-date. Current version is 0.05 Devel-Trace : Package is up-to-date. Current version is 0.10 Digest-BubbleBabble : Package is up-to-date. Current version is 0.01 Digest-MD2 : Package is up-to-date. Current version is 2.03 Digest-Nilsimsa : Package is up-to-date. Current version is 0.06 Email-Valid : Package is up-to-date. Current version is 0.15 Env-Path : Package is up-to-date. Current version is 0.18 Event : A new version of upstream files is available. Package can be upgraded from version 1.08 to 1.13 Exception-Class : A new version of upstream files is available. Package can be upgraded from version 1.23 to 1.32 Exception-Class-DBI : A new version of upstream files is available. Package can be upgraded from version 0.95 to 1.00 ExtUtils-AutoInstall : Package is up-to-date. Current version is 0.63 ExtUtils-XSBuilder : Package is up-to-date. Current version is 0.28 File-chdir : Package is up-to-date. Current version is 0.06 File-MMagic : Package is up-to-date. Current version is 1.27 File-Modified : Package is up-to-date. Current version is 0.07 File-NFSLock : Package is up-to-date. Current version is 1.20 File-Type : Package is up-to-date. Current version is 0.22 Font-AFM : A new version of upstream files is available. Package can be upgraded from version 1.19 to 1.20 Frontier-RPC : Package is up-to-date. Current version is 0.07b4 Gnome2 : Package is up-to-date. Current version is 1.001 Gnome2-Canvas : Package is up-to-date. Current version is 1.001 Gnome2-GConf : Package is up-to-date. Current version is 1.000 Gnome2-Print : Package is up-to-date. Current version is 0.94 Gnome2-VFS : Package is up-to-date. Current version is 1.003 Gnome2-Wnck : Package is up-to-date. Current version is 0.02 Graph : A new version of upstream files is available. Package can be upgraded from version 0.81 to 0.20105 GraphViz : A new version of upstream files is available. Package can be upgraded from version 2.02 to 2.04 Gtk2-GladeXML : Package is up-to-date. Current version is 1.004 Gtk2-Ex-PodViewer : A new version of upstream files is available. Package can be upgraded from version 0.13 to 0.18 Gtk2-TrayIcon : Package is up-to-date. Current version is 0.03 HTML-CalendarMonth : A new version of upstream files is available. Package can be upgraded from version 1.18 to 1.25 HTML-Element-Extended : A new version of upstream files is available. Package can be upgraded from version 1.17 to 1.18 HTML-TokeParser-Simple : Package is up-to-date. Current version is 3.15 HTTP-Body : Package is up-to-date. Current version is 0.5 HTTP-DAV : Package is up-to-date. Current version is 0.31 I18N-LangTags : Package is up-to-date. Current version is 0.35 Ima-DBI : Package is up-to-date. Current version is 0.34 Image-Info : Package is up-to-date. Current version is 1.16 Image-Size : A new version of upstream files is available. Package can be upgraded from version 3.01 to 3.230 IO-Pager : Package is up-to-date. Current version is 0.06 IO-String : Package is up-to-date. Current version is 1.08 IO-Util : Package is up-to-date. Current version is 1.5 Jcode : A new version of upstream files is available. Package can be upgraded from version 2.06 to 2.07 libxml-perl : Package is up-to-date. Current version is 0.08 Locale-Maketext-Fuzzy : Package is up-to-date. Current version is 0.02 Mail-Box-Parser-C : Package is up-to-date. Current version is 3.006 Math-Bezier : Package is up-to-date. Current version is 0.01 Math-GMP : Package is up-to-date. Current version is 2.04 Math-Interpolate : Package is up-to-date. Current version is 1.05 Math-Pari : A new version of upstream files is available. Package can be upgraded from version 2.010709 to 2.01080604 MLDBM-Sync : Package is up-to-date. Current version is 0.30 mod_perl : A new version of upstream files is available. Package can be upgraded from version 1.31 to 2.0.4 mod_perl : Package is up-to-date. Current version is 2.0.4 Module-ScanDeps : Package is up-to-date. Current version is 0.54 Module-Versions-Report : Package is up-to-date. Current version is 1.02 Net-SSH-Perl : Package is up-to-date. Current version is 1.25 Object-MultiType : Package is up-to-date. Current version is 0.05 OOTools : Package is up-to-date. Current version is 2.21 PAR : Package is up-to-date. Current version is 0.90 PAR-Dist : Package is up-to-date. Current version is 0.07 Path-Class : A new version of upstream files is available. Package can be upgraded from version 0.17 to 0.23 Pod-POM : Package is up-to-date. Current version is 0.17 PodToHTML : Package is up-to-date. Current version is 0.05 Proc-ProcessTable : Package is up-to-date. Current version is 0.45 psh : Package is up-to-date. Current version is 1.8 Regexp-Shellish : Package is up-to-date. Current version is 0.93 RPC-XML : A new version of upstream files is available. Package can be upgraded from version 0.69 to 0.73 Schedule-Cron : A new version of upstream files is available. Package can be upgraded from version 0.97 to 1.00 sdf : Package is up-to-date. Current version is 2.001 SOAP-WSDL : A new version of upstream files is available. Package can be upgraded from version 1.20 to 2.00.10 sol-inst : Package is up-to-date. Current version is 0.90a Solaris-DeviceTree : Package is up-to-date. Current version is 0.03 Solaris-Sysconf : Package is up-to-date. Current version is 0.01 SQL-Statement : Package is up-to-date. Current version is 1.15 Statistics-Descriptive : Package is up-to-date. Current version is 2.6 String-CRC32 : Package is up-to-date. Current version is 1.4 String-ShellQuote : A new version of upstream files is available. Package can be upgraded from version 1.03 to 1.04 Sub-Override : Package is up-to-date. Current version is 0.08 SVN-Notify : A new version of upstream files is available. Package can be upgraded from version 2.64 to 2.80 SVN-Simple : A new version of upstream files is available. Package can be upgraded from version 0.27 to 0.28 Unix-Syslog : A new version of upstream files is available. Package can be upgraded from version 0.97 to 1.1 Template-Extract : Package is up-to-date. Current version is 0.40 Template-TAL : Package is up-to-date. Current version is 0.9 Template-Toolkit : Package is up-to-date. Current version is 2.22 Term-Cap : A new version of upstream files is available. Package can be upgraded from version 1.09 to 1.12 TermReadKey : Package is up-to-date. Current version is 2.30 Test-Class : A new version of upstream files is available. Package can be upgraded from version 0.11 to 0.36 Test-Differences : Package is up-to-date. Current version is 0.47 Test-Distribution : Package is up-to-date. Current version is 2.00 Test-Inline : Package is up-to-date. Current version is 0.16 Test-Manifest : A new version of upstream files is available. Package can be upgraded from version 1.17 to 1.23 Test-Memory-Cycle : Package is up-to-date. Current version is 1.04 Test-MockObject : Package is up-to-date. Current version is 1.09 Test-XML : A new version of upstream files is available. Package can be upgraded from version 0.07 to 0.08 Text-Autoformat : A new version of upstream files is available. Package can be upgraded from version 1.13 to 1.669002 Text-Diff : Package is up-to-date. Current version is 0.35 Text-Quoted : Package is up-to-date. Current version is 1.10 Text-Scraper : Package is up-to-date. Current version is 0.02 Text-Tabs+Wrap : Package is up-to-date. Current version is 2006.0711 Text-Template : A new version of upstream files is available. Package can be upgraded from version 1.44 to 1.45 Tie-DBI : Package is up-to-date. Current version is 1.02 Tie-EncryptedHash : A new version of upstream files is available. Package can be upgraded from version 1.21 to 1.24 Tie-MLDBM : Package is up-to-date. Current version is 1.04 Time-HiRes : A new version of upstream files is available. Package can be upgraded from version 1.9707 to 1.9721 Tree-Simple : A new version of upstream files is available. Package can be upgraded from version 1.16 to 1.18 Unicode-Map8 : A new version of upstream files is available. Package can be upgraded from version 0.12 to 0.13 Unicode-MapUTF8 : Package is up-to-date. Current version is 1.11 UNIVERSAL-moniker : Package is up-to-date. Current version is 0.08 UNIVERSAL-require : A new version of upstream files is available. Package can be upgraded from version 0.11 to 0.13 VCP : Package is up-to-date. Current version is 0.9.20050110 VCP-Dest-svk : Package is up-to-date. Current version is 0.29 Want : Package is up-to-date. Current version is 0.18 WWW-Mechanize : A new version of upstream files is available. Package can be upgraded from version 1.22 to 1.66 X11-Protocol : Package is up-to-date. Current version is 0.56 XML-Atom : A new version of upstream files is available. Package can be upgraded from version 0.25 to 0.37 XML-AutoWriter : Package is up-to-date. Current version is 0.39 XML-DOM : Package is up-to-date. Current version is 1.44 XML-Encoding : Package is up-to-date. Current version is 1.01 XML-GDOME : Package is up-to-date. Current version is 0.86 XML-GDOME-XSLT : Package is up-to-date. Current version is 0.75 XML-LibXML : A new version of upstream files is available. Package can be upgraded from version 1.70 to 1.62001 XML-LibXML-Common : Package is up-to-date. Current version is 0.13 XML-RegExp : Package is up-to-date. Current version is 0.03 XML-Smart : Package is up-to-date. Current version is 1.6.9 -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From phil at bolthole.com Sun Jan 9 03:47:49 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 8 Jan 2011 18:47:49 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <1294531223-sup-1547@pinkfloyd.chass.utoronto.ca> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1294531223-sup-1547@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jan 8, 2011 at 4:03 PM, Ben Walton wrote: > ... > Noted; I'll do this next time. ?I did run this wording past Maciej and > Ihsan. ?In the meantime, here are the ballot options, since this isn't > a secret: > > 1. Files and directories are allowed to be delivered to /var/opt/csw > ? directly by the prototype of a package. > > 2. Directories may be delivered to /var/opt/csw by the prototype of a > ? package, but files may not. > > 3. Neither files nor directories may be delivered to /var/opt/csw by > ? the prototype of a package. okay, the choices are neutral enough. The thing is, though, you sent the poll directly to all current maintainers. Not all maintainers may be reading this thread. Did you reference the reasoning WHY people might choose one or the other? There may be quite a few people who go vote, who havent actually read the discussion thread. Telling people "here, choose between A or B", without giving them explicit comparisons between the two, or at least references, can in itself be a a subtle, yet heavy bias. From phil at bolthole.com Sun Jan 9 05:53:26 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 8 Jan 2011 20:53:26 -0800 Subject: [csw-maintainers] musings on asciidoc Message-ID: Something interesting that I found: http://srackham.wordpress.com/blogpost-readme/ references "blogpost", a mechanism to drive wordpress "blog posts" from asciidoc. Would be interesting if we could drive our site from {some version controlled system} to wordpress directly. There is also at least one asciidoc driven, or compatible, wiki: https://github.com/github/gollum it drives "github". (so predictably, runs on top of git :) From bonivart at opencsw.org Sun Jan 9 09:36:16 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 9 Jan 2011 09:36:16 +0100 Subject: [csw-maintainers] musings on asciidoc In-Reply-To: References: Message-ID: On Sun, Jan 9, 2011 at 5:53 AM, Philip Brown wrote: > Would be interesting if we could drive our site from ?{some version > controlled system} to wordpress directly. So we would soon be back to how you ran our web site where we had to send a patch? Both Wikis and Wordpress already have version control and if the source format is not future proof enough the end result, HTML, sure is. There will never be a real problem migrating if we want/need to and until then we have easy to use documentation systems which actually stimulate use. This is just complications we don't need. /peter From maciej at opencsw.org Sun Jan 9 09:38:13 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 9 Jan 2011 08:38:13 +0000 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: No dia 8 de Janeiro de 2011 16:38, Philip Brown escreveu: >>>> It's true that MySQL >>>> executables are under /opt/csw/mysql5, but it's an exception rather >>>> than a rule. >>> >>> Yes, this is exactly my point. programs with their own sub-prefix are >>> special. Perhaps we should make a specific variation on our standards, >>> for programs with sub-prefixes. >>> Something like, "if shared libs are generated under $PREFIX != >>> /opt/csw, it is recommended >>> ?to create a symlink in /opt/csw/lib, pointing to the appropriate library" >> >> Why are you thinking in terms of "shared libs are generated under"? > > By that I mean [naturally generated there by the program's > config/installer, if we do nothing but specify > --prefix=/opt/csw/subprefix] I know what you mean, I was asking why you use the installer as a guideline. >> Isn't it better to think of shared libraries as a shared resource, >> without obscuring the logic with prefixes? > > I think this is an area where we have two "valid" ways of proceeding > -- valid in the sense of "can be considered a consistent methodology" > at least -- and so this issue becomes a little more flavored by > "taste" vs purely technical. > > Certainly, it is "consistent" to declare "all 'public' linkable shared > libraries must be in /opt/csw/lib directly". > But it's not particularly beneficial, beyond a trivial goal of robotic > consistency. and it blocks other goals. > Such as, consistency of prefix. > Some types of consistency are mutually exclusive. For example, the > consistency of, > "If a program, or program suite, has been sub-prefixed, then all > (non-dynamic) files for it should live under that subprefix". > This is a reasonably expected, even presumed consistency by a user. We have a prefix, and it is /opt/csw. Any other private prefixes, are just the easiest way of getting around installing two versions of the same software. The easiest doesn't mean the best, though. As an OpenCSW user, I perceive using /opt/csw at times, and /opt/csw/mysql5 at times, and /opt/csw/postgresql at times, as an inconsistent handling of files. It's enough hassle to integrate one prefix into your system - you need to set PATH, and think about that prefix potentially affecting shared library linking in your programs, about conflicting paths, etc. Adding even more prefixes is in my opinion counterproductive. The consistency of prefix means that OpenCSW software gets packaged under /opt/csw/{bin,lib,share,...}, and nowhere else. > We're going to have to break one set of consistency rules, one way or > another. So proceeding merely on "must keep things consistent" is > inadequate. > It seems to make more sense to determine this issue based on potential > benefits/goals. Agreed. (With 'potential' also meaning 'reasonable'.) > more lower down. > > >>> I will also point out, that our berkeleydb packages also keep their >>> shared libs under their own subprefix, rather than keeping the actual >>> .so files in /opt/csw/lib >> >> My personal opinion is that this is a suboptimal layout. ?Just that we >> used to do something doesn't mean that it's the right thing to do. > > well, I agree to the extent that I think it may make life easier to > have "something" in /opt/csw/lib for them. > We just differ in that I think the "something" should be a symlink :) > > > Maciej, it sounds like you are mixing goal objective, with implementation. > Isnt your real goal, "to have standardized linking, -R/opt/csw/lib > whereever possible"? > Why not just say "okay symlinks meet that goal", without insisting it > also be done by your preferred methodology? Standardized linking is one of the goals, and symlinks meet that goal, that's right. A bigger goal is to achieve a standard filesystem layout. The reason to insist is that our file placement policy is not "place your files wherever you like, just make symlinks at the right locations". If a library is accessible at /opt/csw/lib (via a symlink or otherwise), why multiply entities beyond necessity? >>> Perhaps you meant they do not use "private" shared libraries? >> >> Yes. >> >> What I meant is that they use libmysqlient, and that libmysqlclient is >> not a private, MySQL's own thing, but rather a public, common >> resource. ?It's indeed used by MySQL executables, but not only. ?There >> are other executables that also use them. >> >> The fact that some users of a common resource are special, doesn't >> mean that the resource should be. > > > okay, back to listing potential target "goals" for library policy. > Someone, perhaps you, mentioned something earlier about everyone using > packages as a delivery system. > What you might not consider, is that the packages can be a "one-time" > delivery system only. > Some people run a package update once a year, and then forget about packages. > Or, have "the sysadmin group" install packages, but they themselves > know *nothing about packages*. > Or, the packages may have been delivered to a template system, which > is then filesystem-level duplicated in a sort of production line > methodology, and targets know nothing about packages. > Or, /opt/csw may be shared/duplicated out by other methods, and again, > the target systems know nothing about packages. > > In all these kinds of situations, to help our users have an "easy to > use" experience, we need to make sure our deliverables make sense on > purely a filesystem basis. > The users probably care nothing about linking. They just want things > to be consistent from *their* perspective. > I would argue that from that perspective, "everything associated with > /opt/csw/foo, 'lives' under /opt/csw/foo", is the most consistent. and > helpful. This has never been and never will be the case. For example, binaries at /opt/csw/foo/bin will always need shared libraries from /opt/csw/lib. Any scripts will need interpreters from /opt/csw/bin, basically - no /opt/csw/foo can live without /opt/csw. > I myself have done a quickie "hmm, wonder how much stuff is under > there? du -k /some/prefix" ?and then been **really annoyed** when I > found out later, that not everything was in there. You must be easy to annoy... I don't know what would be your goal behind "du -k /some/prefix", but I suspect it would be hard to defend as a basis for OpenCSW filesystem policy. If there's any prefix you might be interested in measuring, it's /opt/csw. Any other /opt/csw based custom prefixes will never be self-sufficient. The following statement still stands: The fact that some users of a common resource are special, doesn't mean that the resource should be. From maciej at opencsw.org Sun Jan 9 10:08:57 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 9 Jan 2011 09:08:57 +0000 Subject: [csw-maintainers] An idea: OpenCSW on FLOSS Weekly In-Reply-To: References: Message-ID: No dia 23 de Dezembro de 2010 17:55, Philip Brown escreveu: > Somewhere in there, should be the idea that in some ways we do things > better than even IPS :) > (having a nice unified config file to control whether demons > autoconfig, for example) > > and our nice simple filebased archive. stuff like that. Yes, sounds good. There also has been a suggestion to provide a comparison to alternative package sources such as sunfreeware and blastwave. > Also, we need to officially put to rest the issue of our quality > control, in the sense of , are we in the business of making the "best > possible" packages? or just "whatever the maintainer feels like"? > recently, seems like certain people were pushing for "whatever the > maintainer feels like". > Which does not look so good for advertising. I think this topic would be best left out of the interview. If pressed, we should answer that there are discussions about quality control, and present, in an neutral manner, what are the main two competing opinions. Using the phrase "whatever the maintainer feels like" would be just as bad as using "whatever the release manager feels like". Please don't stir up any controversies on the podcast. >> We need to be prepared to answer the following questions: >> - how many users (give an estimate) >> - what kinds of users do we have (individual / corporate / institutions) > > See my prior comment. If we really are aiming for corporate, as well > as the above, then we need to *commit* to "best possible". Same comment; best possible is still a subjective term and we better avoid this avenue altogether. The audience isn't corporate, anyway. I mean, there are certainly sysadmins who work for corporations, but probably no CTOs. >> - the size of the developer community >> - how to get involved / where to find us >> - good to give some metrics such as numbers of updated packages per month / >> year > > could just check the weekly package announces for that, if they are > archived somewhers. I think they are. Does anyone have that data at hand? William? >> We would need 2 or 3 people to speak on the show. > > I'd be willing to speak, depending on the timezone and particular day > it falls on. Excellent! They record on Wednesday early afternoons Pacific time, about 12:30 PST / 21:30 CET, if I'm not mistaken. I tried to look it up on the website, and found a schedule[1] which lists FLOSS Weekly at 09:30 PST, but at the same time, I clearly remember early afternoons mentioned in a number of podcast episodes, so I'm not sure any more. In any case, hours are such that they should be reasonable for both American and European time zones. Maciej [1] http://wiki.twit.tv/wiki/Schedule From maciej at opencsw.org Sun Jan 9 10:41:01 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 9 Jan 2011 09:41:01 +0000 Subject: [csw-maintainers] An idea: OpenCSW on FLOSS Weekly In-Reply-To: References: Message-ID: Let's get things going with the podcast idea! We got an answer from Phil on the list, and I've also received responses from Dago and Ben. This gives us a nice array of perspectives. For example, Phil can talk about project's origins and packaging topics, Dago can present maintainer tools, infrastructure and collaboration with upstream developers, and Ben can discuss community building and OpenCSW's plans for the future. One of the hosts, Randal Schwartz, author of Programming Perl, will be probably also interested in talking about packaging Perl modules. Interviews are done in conference calls. I think it's a good idea to let know the show hosts who'll be covering which areas. It's of course only a guideline. The show does not have a preset agenda, or at least doesn't leave that impression; it's a conversation about a given topic or project. There is a wiki page[1] for TWiT network guests (FLOSS Weekly is part of TWiT), it's a useful read. I think that we're ready to send an e-mail to TWiT. I'll write a draft and send it to Ben for proofreading and style correction. I'll then ask Ben to send the e-mail to TWiT guys. Maciej [1] http://wiki.twit.tv/wiki/How_to_Be_a_Guest_on_the_TWiT_network From james at opencsw.org Sun Jan 9 11:02:49 2011 From: james at opencsw.org (James Lee) Date: Sun, 09 Jan 2011 10:02:49 GMT Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> Message-ID: <20110109.10024900.272587450@gyor.oxdrove.co.uk> On 06/01/11, 08:34:33, Peter FELECAN wrote regarding Re: [csw-maintainers] [policy] files/dirs in /var/opt/csw: > We discussed all this on the submit mailing list (look for the "newpkgs > clamav, libclam6, libclam6_devel" thread starting at > http://lists.opencsw.org/pipermail/pkgsubmissions/2010-November/001501.h tml, > continued at > http://lists.opencsw.org/pipermail/pkgsubmissions/2010-December/001659.h tml > since October. > You had at least 5 people giving their view on this subject, among them > 2 members of the current board. Why do you want specifically the opinion > of the board members? The other maintainers opinion doesn't count? Following these external links takes us to clamav. My opinion is clamav shouldn't be delivering the user databases at all so the question of where this package delivers them is void. I'm not asking for any change to clam (my opinion didn't count, the maintainer's opinion was clear and I now make my own clamav packages with freshclam control), just please don't use clamav as a case study for /var. James. From bonivart at opencsw.org Sun Jan 9 11:46:15 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 9 Jan 2011 11:46:15 +0100 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <20110109.10024900.272587450@gyor.oxdrove.co.uk> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <20110109.10024900.272587450@gyor.oxdrove.co.uk> Message-ID: On Sun, Jan 9, 2011 at 11:02 AM, James Lee wrote: > Following these external links takes us to clamav. ?My opinion is clamav > shouldn't be delivering the user databases at all so the question of > where this package delivers them is void. ?I'm not asking for any change > to clam (my opinion didn't count, the maintainer's opinion was clear and > I now make my own clamav packages with freshclam control), just please > don't use clamav as a case study for /var. I think it's more than two years ago so I don't remember having a strong opinion about it, it was actually me posting for guidance, not being blocked by Phil as usual. The response was mixed so the main reason for delivering the files was that the source did so and my package already did so I just kept doing it, not because I absolutely didn't want it another way. With these new complications ahead I would much rather just remove the files from the package. /peter From maciej at opencsw.org Sun Jan 9 15:06:00 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 9 Jan 2011 14:06:00 +0000 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 24 de Dezembro de 2010 13:14, Ben Walton escreveu: > Ok, but we've now veered into a different discussion. ?We were > originally discussing how to handle packages where a (variably named) > SUNW dependency existed. ?I think checkinstall is one (not necessarily > the best) way of doing that. Yes, let's go back to the original issue. What we've established so far is that we cannot reasonably depend on SUNW packages. In the case of cups, the slp package is not part of the core Solaris install, and therefore it's a library that will be likely missing during cups installs. I've built openslp with the intention to provide OpenCSW's own version of libslp. My openslp packages have been rejected on the grounds that they aren't any better than what's already in Solaris. My argument is that you cannot guarantee that the stock libslp will be there, while you can guarantee this for an OpenCSW provided library. What good is Solaris libslp if it's not there? Therefore, I argue that OpenCSW libslp is better, because it's guaranteed to be in the filesystem thanks to dependency mechanisms. I would like to ask for permission to release openslp and link cups against it, until a better solution comes along. From maciej at opencsw.org Sun Jan 9 15:09:53 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 9 Jan 2011 14:09:53 +0000 Subject: [csw-maintainers] Some new problems with manpages In-Reply-To: References: Message-ID: No dia 17 de Dezembro de 2010 07:37, Peter FELECAN escreveu: > Philip Brown writes: > >> On 12/16/10, Jeffery Small wrote: >>> >>> The old weblink to perform filename searches in the various packages is >>> gone and a quick survey of the new site did not reveal if this feature is >>> still available. >> >> if you manualy go to >> >> www.opencsw.org/search > > This was discussed many times and a request to put a visible link toward > that URI was also made. Is it possible that the web "team" do this for > the convenience of all please? William, can you take a look? From pfelecan at opencsw.org Sun Jan 9 15:19:06 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 09 Jan 2011 15:19:06 +0100 Subject: [csw-maintainers] Dependencies on SUNW packages In-Reply-To: (Maciej Blizinski's message of "Sun, 9 Jan 2011 14:06:00 +0000") References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> Message-ID: "Maciej (Matchek) Blizinski" writes: > I would like to ask for permission to release openslp and link cups > against it, until a better solution comes along. I'm for having our own openslp package. -- Peter From bonivart at opencsw.org Sun Jan 9 15:28:58 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 9 Jan 2011 15:28:58 +0100 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jan 9, 2011 at 3:06 PM, Maciej (Matchek) Blizinski wrote: > I would like to ask for permission to release openslp and link cups > against it, until a better solution comes along. +1 /peter From phil at bolthole.com Sun Jan 9 15:43:17 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 9 Jan 2011 06:43:17 -0800 Subject: [csw-maintainers] musings on asciidoc In-Reply-To: References: Message-ID: On Sun, Jan 9, 2011 at 12:36 AM, Peter Bonivart wrote: > On Sun, Jan 9, 2011 at 5:53 AM, Philip Brown wrote: >> Would be interesting if we could drive our site from ?{some version >> controlled system} to wordpress directly. > > So we would soon be back to how you ran our web site where we had to > send a patch? that was not the motivation I had. But for things such as "policy pages", where we are talking about having the pages in svn, and in a package , and driving the web contents from that, I thought it could be interesting > Both Wikis and Wordpress already have version control and if the > source format is not future proof enough the end result, HTML, sure > is I was not thinking so much about "future proof", as "consolidate on one document language" From phil at bolthole.com Sun Jan 9 15:53:15 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 9 Jan 2011 06:53:15 -0800 Subject: [csw-maintainers] An idea: OpenCSW on FLOSS Weekly In-Reply-To: References: Message-ID: On Sun, Jan 9, 2011 at 1:08 AM, Maciej (Matchek) Blizinski wrote: > No dia 23 de Dezembro de 2010 17:55, Philip Brown escreveu: >... >> See my prior comment. If we really are aiming for corporate, as well >> as the above, then we need to *commit* to "best possible". > > Same comment; best possible is still a subjective term and we better > avoid this avenue altogether. ?The audience isn't corporate, anyway. > I mean, there are certainly sysadmins who work for corporations, but > probably no CTOs. You need to keep in mind that CTOs are *always* a potential secondary audience. If there is a sysadmin who listens, that sysadmin may wish to encourage the corporation to start using our package. The obvious thing that will come up in any internal conversation they have is, "well, where did you hear about opencsw?" "Well, from this podcast, which is over [here]". And then the CTO/VP/Director may listen to the interview, or skims the transcript. Certainly it's more likely at a director level. I have a director who might quite likely listen to it. Not my SVP or CTO. But it's my Director who would be the primary decision maker for "blessing" use of opencsw, across 300 machines. From phil at bolthole.com Sun Jan 9 16:25:43 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 9 Jan 2011 07:25:43 -0800 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: On Sun, Jan 9, 2011 at 12:38 AM, Maciej (Matchek) Blizinski wrote: > No dia 8 de Janeiro de 2011 16:38, Philip Brown escreveu: >>... >> By that I mean [naturally generated there by the program's >> config/installer, if we do nothing but specify >> --prefix=/opt/csw/subprefix] > > I know what you mean, I was asking why you use the installer as a guideline. I go by the principle that if something is not constrained by our standards, it should then match up what a user of the program expects if they install it themselves. ie:"normal defaults for the program". > As an OpenCSW user, I perceive using /opt/csw at times, and > /opt/csw/mysql5 at times, and /opt/csw/postgresql at times, as an > inconsistent handling of files. ?It's enough hassle to integrate one > prefix into your system - you need to set PATH, and think about that > prefix potentially affecting shared library linking in your programs, > about conflicting paths, etc. yes it is a hassle... which is why we have symlinks :) We are probably long past time of implementing "alternatives" links for mysql and postgres, into /opt/csw/bin, at least for the client program. > Standardized linking is one of the goals, and symlinks meet that goal, > that's right. ?A bigger goal is to achieve a standard filesystem > layout. > > The reason to insist is that our file placement policy is not "place > your files wherever you like, just make symlinks at the right > locations". certainly that is not appropriate. I suppose it would be helpful to explicitly call out in this discussion, "programs should not be configured with any prefix other than /opt/csw, unless there is a compelling requirement to have a subprefix". (such as an ongoing need to support more than one version of a particular program installed at a time) >> I myself have done a quickie "hmm, wonder how much stuff is under >> there? du -k /some/prefix" ?and then been **really annoyed** when I >> found out later, that not everything was in there. > > You must be easy to annoy... ?I don't know what would be your goal > behind "du -k /some/prefix", but I suspect it would be hard to defend > as a basis for OpenCSW filesystem policy. ?If there's any prefix you > might be interested in measuring, it's /opt/csw. ?Any other /opt/csw > based custom prefixes will never be self-sufficient. its not about being self-sufficient. it was most likely about typical sysadmin methodologies in deciding what to clean up. "Hmm.. this filesystem is way too full. what can I get rid of cleanly? lets run du -k" Then when you get obvious "big directories" that you are not using, you can remove them by "appropriate" means, which may still be "pkgrm". There's probably other reasons lurking... i think I dont remember the full reasons. > > The following statement still stands: > > The fact that some users of a common resource are special, doesn't > mean that the resource should be. sorry, I dont think I fully understand what you are saying there. From bwalton at opencsw.org Sun Jan 9 16:53:07 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 09 Jan 2011 10:53:07 -0500 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> Message-ID: <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Sun Jan 09 09:28:58 -0500 2011: > +1 +1 from me too. If we can't reliably use the sun provided libraries but can deliver our own, we should. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sun Jan 9 17:14:38 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 9 Jan 2011 08:14:38 -0800 Subject: [csw-maintainers] An idea: OpenCSW on FLOSS Weekly In-Reply-To: References: Message-ID: On Sun, Jan 9, 2011 at 1:41 AM, Maciej (Matchek) Blizinski wrote: > > > [1] http://wiki.twit.tv/wiki/How_to_Be_a_Guest_on_the_TWiT_network > It's in Petaluma? !! aww, only an hour away from my old house. but unfortunately, 7 hours away from where I live now. From phil at bolthole.com Sun Jan 9 17:26:37 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 9 Jan 2011 08:26:37 -0800 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jan 9, 2011 at 7:53 AM, Ben Walton wrote: > Excerpts from Peter Bonivart's message of Sun Jan 09 09:28:58 -0500 2011: > >> +1 > > +1 from me too. ?If we can't reliably use the sun provided libraries > but can deliver our own, we should. Are you seriously looking to make this a policy? You know, "x11" is not "core/required" either. There are probably others. (not many, I admit, but still) This goes against a "day 1" method of doing things: if a Solaris library/program is "available", and it is reasonably assumed to always be up to date "enough", in the future, then we use it. yes we duplicate some sun libraries and progs, but only the ones where sun just doesnt keep their libs/progs up to date enough. if sun's slp libs are unusably out of date, I have no problem with shipping our own. But shipping our own, when we dont *need* to, is a huge change in policy and attitude for opencsw. I think it would merit a userbase poll. From pfelecan at opencsw.org Sun Jan 9 17:57:55 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 09 Jan 2011 17:57:55 +0100 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: (Philip Brown's message of "Sun, 9 Jan 2011 08:26:37 -0800") References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > if sun's slp libs are unusably out of date, I have no problem with > shipping our own. But shipping our own, when we dont *need* to, is a > huge change in policy and attitude for opencsw. I think it would > merit a userbase poll. Are you serious? An user base pool? I'm strongly against! -- Peter From phil at bolthole.com Sun Jan 9 19:25:56 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 9 Jan 2011 10:25:56 -0800 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jan 9, 2011 at 8:57 AM, Peter FELECAN wrote: > Philip Brown writes: > >> if sun's slp libs are unusably out of date, I have no problem with >> shipping our own. But shipping our own, when we dont *need* to, is a >> huge change in policy and attitude for opencsw. ? I think it would >> merit a userbase poll. > > Are you serious? An user base pool? I'm strongly against! you are strongly against listening to our users? an odd sort of attitude. From pfelecan at opencsw.org Sun Jan 9 19:46:22 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 09 Jan 2011 19:46:22 +0100 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: (Philip Brown's message of "Sun, 9 Jan 2011 10:25:56 -0800") References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Sun, Jan 9, 2011 at 8:57 AM, Peter FELECAN wrote: >> Philip Brown writes: >> >>> if sun's slp libs are unusably out of date, I have no problem with >>> shipping our own. But shipping our own, when we dont *need* to, is a >>> huge change in policy and attitude for opencsw. ? I think it would >>> merit a userbase poll. >> >> Are you serious? An user base pool? I'm strongly against! > > > you are strongly against listening to our users? > an odd sort of attitude. You're distorting things. Asking for an user base pool is always part of your strategy of last defense: playing the advocate of the nebulous user base. If an user has a strong opinion about our maintainceship the best he has to do is to propose patches and/or to become a maintainer. Of course, there is the users mailing list, the bug-tracking system that I read and if the request is reasonable an action follows. A maintenance decision is a maintainer or group of maintainers decision. -- Peter From phil at bolthole.com Sun Jan 9 21:40:34 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 9 Jan 2011 12:40:34 -0800 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jan 9, 2011 at 10:46 AM, Peter FELECAN wrote: > Philip Brown writes: > >> On Sun, Jan 9, 2011 at 8:57 AM, Peter FELECAN wrote: >>> Philip Brown writes: >>>... >> you are strongly against listening to our users? >> an odd sort of attitude. > > You're distorting things. Asking for an user base pool is always part of > your strategy of last defense: playing the advocate of the nebulous user > base. They become less "nebulous" if we actually ask them about their needs. Based on prior experience dealing with CSW user complaints, I know that some users will be unhappy if we needlessly clone sun packages. Ideally, you might accept my experience on this. But, presuming you wont, and you doubt that users would be unhappy, we should settle the issue by asking them. If on the other hand, you dont CARE if some users are unhappy, then that's a whole other problem. > If an user has a strong opinion about our maintainceship the best > he has to do is to propose patches and/or to become a maintainer. Of > course, there is the users mailing list, the bug-tracking system that I > read and if the request is reasonable an action follows. Making a large policy principle change, not bothering to check if it makes users unhappy, and then reverting it down the road when users bother to complain, is a sign of a user-hostile development process. Not to mention an inefficient/chaotic process. That's not a good thing for opencsw, in my opinion. This is not a maintainer-internal-only issue. This is a directly user-facing issue, both in the specific slp case, but also in the much larger general policy case. From maciej at opencsw.org Sun Jan 9 22:55:33 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 9 Jan 2011 21:55:33 +0000 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 9 de Janeiro de 2011 16:26, Philip Brown escreveu: > On Sun, Jan 9, 2011 at 7:53 AM, Ben Walton wrote: >> Excerpts from Peter Bonivart's message of Sun Jan 09 09:28:58 -0500 2011: >> >>> +1 >> >> +1 from me too. ?If we can't reliably use the sun provided libraries >> but can deliver our own, we should. > > Are you seriously looking to make this a policy? > You know, "x11" is not "core/required" either. > There are probably others. (not many, I admit, but still) X11 stuff is different in that it's a desktop installation, which is likely done using the complete package set. Installing a Solaris desktop starting from a core install would be annoying, I don't think anybody does that. I would like to be able to provide such a library if I see a reason for it. In the case of cups I do: it's reasonable to assume that cups is installed on servers, and servers tend to be installed using the core package set, with a couple cherry-picked additions (bash, for instance). The Solaris slp library might or might not be among the added packages. Notably, slp is not required by the stock Solaris lpd, so if you had a running Solaris printserver and you install cups on it, you'll hit that missing library. > This goes against a "day 1" method of doing things: if a Solaris > library/program is "available", and it is reasonably assumed to always > be up to date "enough", in the future, then we use it. It is reasonable enough, but at the same time, in the case of cups, the failure mode is quite unpleasant, and the solution (you can call it a workaround if you want) is quite simple. > yes we duplicate some sun libraries and progs, but only the ones where > sun just doesnt keep their libs/progs up to date enough. > > if sun's slp libs are unusably out of date, I have no problem with > shipping our own. But shipping our own, when we dont *need* to, is a > huge change in policy and attitude for opencsw. ? I think it would > merit a userbase poll. It's not fair to say that we don't need to. When libslp is not on the filesystem, we do need to, but it's too late. You can imagine a different solution in which you test that certain shared library is there before you install a package. But this needs a coordinated effort from both developers of installation utilities, and is not likely to be done in a near future. If it would be done, I'd happily remove openslp and rely on stock libslp. But until then, I don't want our users to install cups only to find out that it fails because of a missing shared library. I call that scenario a result of low package quality. From maciej at opencsw.org Sun Jan 9 23:33:48 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 9 Jan 2011 22:33:48 +0000 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: No dia 9 de Janeiro de 2011 15:25, Philip Brown escreveu: > On Sun, Jan 9, 2011 at 12:38 AM, Maciej (Matchek) Blizinski > wrote: >> No dia 8 de Janeiro de 2011 16:38, Philip Brown escreveu: >>>... >>> By that I mean [naturally generated there by the program's >>> config/installer, if we do nothing but specify >>> --prefix=/opt/csw/subprefix] >> >> I know what you mean, I was asking why you use the installer as a guideline. > > I go by the principle that if something is not constrained by our > standards, it should then match up what a user of the program expects > if they install it themselves. ?ie:"normal defaults for the program". Yes, if it's something that our standards don't regulate, it's fine to rely on what the installer does. If we talk about a vital element of our software distribution, we have to set installers aside. >> As an OpenCSW user, I perceive using /opt/csw at times, and >> /opt/csw/mysql5 at times, and /opt/csw/postgresql at times, as an >> inconsistent handling of files. ?It's enough hassle to integrate one >> prefix into your system - you need to set PATH, and think about that >> prefix potentially affecting shared library linking in your programs, >> about conflicting paths, etc. > > yes it is a hassle... which is why we have symlinks :) > We are probably long past time of implementing "alternatives" links > for mysql and postgres, into /opt/csw/bin, at least for the client > program. > > >> Standardized linking is one of the goals, and symlinks meet that goal, >> that's right. ?A bigger goal is to achieve a standard filesystem >> layout. >> >> The reason to insist is that our file placement policy is not "place >> your files wherever you like, just make symlinks at the right >> locations". > > certainly that is not appropriate. I suppose it would be helpful to > explicitly call out in this discussion, > "programs should not be configured with any prefix other than > /opt/csw, unless there is a compelling requirement to have a > subprefix". (such as an ongoing need to support more than one version > of a particular program installed at a time) Fair enough. However, even an ongoing need to support more than one version of a program does not necessarily mean that we need to compile programs with a different prefix. Take gettext for example. If we applied your logic to gettext, we'd have /opt/csw/gnu/bin with the utility, and libintl.so.8 would live under /opt/csw/gnu/lib. But we didn't do that. Instead, we used our standard prefix and added a letter in front of binary's name. This way, libintl.so.8 got installed in /opt/csw/lib, which is an excellent place for it to be. I believe that it's the same with cases such as MySQL and PostgreSQL. The only conflicting parts are the binaries, and there is a number of solutions better than using a custom prefix. A custom library directory (/opt/csw/foo/lib) is therefore only a side effect of a not necessarily optimal solution to a technical problem. That doesn't strike me as a compelling argument to keep libraries at a nonstandard location. What I'm proposing, is that we take the gettext (and coreutils, ggrep, etc) approach to shared libraries. Which brings me to the next point... >> The following statement still stands: >> >> The fact that some users of a common resource are special, doesn't >> mean that the resource should be. > > sorry, I dont think I fully understand what you are saying there. The general case of the statement probably doesn't need much explanations. You don't have separate web servers for Firefox, Google Chrome and elinks. Just because one client is special, doesn't mean you need to make the shared resource special. In the case of shared libraries, they are the shared resource, and binaries linking to them are the clients. Some clients (/opt/csw/muysql5/bin/mysql) are special, some others, like myodbc or php, aren't. The fact that some binaries linking to it live under a different prefix, doesn't mean that shared libraries need to. >>> I myself have done a quickie "hmm, wonder how much stuff is under >>> there? du -k /some/prefix" ?and then been **really annoyed** when I >>> found out later, that not everything was in there. >> >> You must be easy to annoy... ?I don't know what would be your goal >> behind "du -k /some/prefix", but I suspect it would be hard to defend >> as a basis for OpenCSW filesystem policy. ?If there's any prefix you >> might be interested in measuring, it's /opt/csw. ?Any other /opt/csw >> based custom prefixes will never be self-sufficient. > > its not about being self-sufficient. it was most likely about typical > sysadmin methodologies in deciding what to clean up. > "Hmm.. this filesystem is way too full. what can I get rid of cleanly? > lets run du -k" > Then when you get obvious "big directories" that you are not using, > you can remove them by "appropriate" means, which may still be > "pkgrm". ?There's probably other reasons lurking... i think I dont > remember the full reasons. I feel this branch of our discussion borders on ridiculous, but okay, let's continue if you wish to. If you want to cleanly get rid of some files, removing /opt/csw/mysql5 might be a very bad move if libmysqlclient is in /opt/csw/mysql5/lib. You might have a program you use (say, php5 or bacula, or postfix) linking against libmysqlclient. Removing /opt/csw/mysql5 may effectively disable your website, or mail server, or whatever it is you're running. In such scenario, if you insist on it, having libmysqlclient located under /opt/csw/lib is a better option, because your web or mail server will continue functioning even after the removal. From phil at bolthole.com Mon Jan 10 00:11:12 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 9 Jan 2011 15:11:12 -0800 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jan 9, 2011 at 1:55 PM, Maciej (Matchek) Blizinski wrote: > > It's not fair to say that we don't need to. ?When libslp is not on the > filesystem, we do need to, but it's too late. ?You can imagine a > different solution in which you test that certain shared library is > there before you install a package. ?But this needs a coordinated > effort from both developers of installation utilities, and is not > likely to be done in a near future. errr... maybe I'm missing something here. But we already have a "test"/safety check. it works with pkg-get, pkgutil, and even plain old pkgadd. Declare a dependency on SUNWslpu. Its always been "allowed" to do so, so we dont have to change any of our standards to do so. And it fulfills your "check before install" issue. What's wrong with that? From phil at bolthole.com Mon Jan 10 00:37:10 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 9 Jan 2011 15:37:10 -0800 Subject: [csw-maintainers] MySQL shared libraries - how about /opt/csw/lib? In-Reply-To: References: Message-ID: On Sun, Jan 9, 2011 at 2:33 PM, Maciej (Matchek) Blizinski wrote: > No dia 9 de Janeiro de 2011 15:25, Philip Brown escreveu: >> >> certainly that is not appropriate. I suppose it would be helpful to >> explicitly call out in this discussion, >> "programs should not be configured with any prefix other than >> /opt/csw, unless there is a compelling requirement to have a >> subprefix". (such as an ongoing need to support more than one version >> of a particular program installed at a time) .../ > Fair enough. ?However, even an ongoing need to support more than one > version of a program does not necessarily mean that we need to compile > programs with a different prefix. I agree. Rather than quoting the next chunk of your email, I'll just say feel free to make the language about "compelling requirement" tighter. Certainly, there are some programs that can cleanly support multiple versions installed, without subprefixes. Then again, there are others which do not. > The general case of the statement probably doesn't need much > explanations. ?You don't have separate web servers for Firefox, Google > Chrome and elinks. ?Just because one client is special, doesn't mean > you need to make the shared resource special. Interesting that you bring up firefox. Because is another thing that effectively "has its own prefix", with symlinks from /opt/csw/bin so users don thave to tweak their path. [well okay its a wrapper script not a symlink :) but same principle. All the real libraries live under the firefox prefix] >>> ... ?Any other /opt/csw >>> based custom prefixes will never be self-sufficient. >> >> its not about being self-sufficient. it was most likely about typical >> sysadmin methodologies in deciding what to clean up. >> "Hmm.. this filesystem is way too full. what can I get rid of cleanly? >> lets run du -k" >> Then when you get obvious "big directories" that you are not using, >> you can remove them by "appropriate" means, which may still be >> "pkgrm". ?There's probably other reasons lurking... i think I dont >> remember the full reasons. > > I feel this branch of our discussion borders on ridiculous, but okay, > let's continue if you wish to. >... > If you want to cleanly get rid of some files, removing /opt/csw/mysql5 > might be a very bad move if libmysqlclient is in /opt/csw/mysql5/lib. > You might have a program you use (say, php5 or bacula, or postfix) > linking against libmysqlclient. [...] I explicitly said in my message (which you even quoted), that in such an instance, I may use pkgrm to remove the files. For initial diagnosis/investigation, sometimes it's nice to be able to use "normal' filesystem tools rather than pkg ones, even if actual file add/removal is handle by pkg tools. So in that case, user would get a warning on pkgrm that something else is using it. > ?Removing /opt/csw/mysql5 may > effectively disable your website, or mail server, or whatever it is > you're running. ?In such scenario, if you insist on it, having > libmysqlclient located under /opt/csw/lib is a better option, because > your web or mail server will continue functioning even after the > removal. contrariwise, if someone discovers that they are using the shared libs from mysql, they will probably find it useful to have the client around for debug/admin purposes. It then becomes a slippery slope down, "well, we have the 'real' shared lib in /opt/csw/lib, so lets have the 'real' client prog in /opt/csw/bin".... On the other hand, if symlinks are good enough for the client prog that is sub-prefixed, it should be good enough for the shared lib that is sub-prefixed? There's the other side of the consistency sword. From william at wbonnet.net Mon Jan 10 00:37:09 2011 From: william at wbonnet.net (William Bonnet) Date: Mon, 10 Jan 2011 00:37:09 +0100 Subject: [csw-maintainers] Some new problems with manpages In-Reply-To: <4D2A3B67.6000108@opencsw.org> References: <4D2A3B67.6000108@opencsw.org> Message-ID: <4D2A46A5.9000903@wbonnet.net> Hi > William, can you take a look? I have added a new icon on the top of the right sidebar. How about this http://www-mockup.opencsw.org ? cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From bwalton at opencsw.org Mon Jan 10 00:41:29 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 09 Jan 2011 18:41:29 -0500 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: <1294615492-sup-8652@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sun Jan 09 11:26:37 -0500 2011: > > +1 from me too. ?If we can't reliably use the sun provided libraries > > but can deliver our own, we should. > > Are you seriously looking to make this a policy? No. I'm voicing my support for the idea in this particular case. Not every word I type is 'setting policy.' This is a discussion among peers, isn't it? > This goes against a "day 1" method of doing things: if a Solaris > library/program is "available", and it is reasonably assumed to > always be up to date "enough", in the future, then we use it. This makes perfect sense for core packages. We have a _specific_ problem with availability in this case though. I suggested a checkinstall script at one point, but you didn't care for that solution. I think that ultimately, depending on the SUNW package is the nicest solution, but it's been shown that this is not a stable choice for the long term as names can and have changed. So, we need a reliable way of providing this dependency for the people wanting to use cups on their boxes. This method should be transparent and provide fail fast error handling. Depending on our own libslp package gives all of these benefits. The downside is that there are now two libslp's on the system. Someone please correct me if I'm wrong here, but the slp provided by SUNWslpu is the Sun implementation of this protocol, correct? The package Maciej has provided is of OpenSLP. This means that it's only providing slp functionality, not the same library. (There very well might still be a naming if the parent paths are ignored...) Interestingly, this issue has been around for a _long_ time now: http://osdir.com/ml/solaris.blastwave.user/2004-09/msg00010.html > if sun's slp libs are unusably out of date, I have no problem with > shipping our own. But shipping our own, when we dont *need* to, is a > huge change in policy and attitude for opencsw. I think it would > merit a userbase poll. I don't think this is an issue that warrants polling the users. We're not talking about a drastic policy change here. Lets get more constructive. If you don't consider either checkinstall scripts or SUNW dependencies (setting aside your reasons for both right now) as good solutions here, what do you think is a good solution? In my opinion, making the admin dig up a package file from a potentially inconvenient location (and only after they've found a non-working cups) is worse than simply delivering the functionality ourselves. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jan 10 00:49:23 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 09 Jan 2011 18:49:23 -0500 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: <1294616521-sup-2203@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sun Jan 09 18:11:12 -0500 2011: > errr... maybe I'm missing something here. But we already have a > "test"/safety check. it works with pkg-get, pkgutil, and even plain > old > pkgadd. > Declare a dependency on SUNWslpu. Ok, ignore the last portion of my previous reply. This landed while I was composing that. This is good, but not great. The problems with it are: 1. It sill makes an admin find this package from some (potentially inconvenient) location. 2. We've been previously bitten by name changes in SUNW packages. This would be a maintainer burden going forward if it happened. 3. Some of the toolchain needs modification to handle this nicely. None of these by themselves are showstoppers, but taken as a whole, they're not very attractive. Modifying the tools is the easiest to swallow.[1] The name change issue is only a potentiality but James has pointed out that this _has_ been a problem with other packages previously. What do you say to sunslp vs openslp? Thanks -Ben [1] Peter B: Why do you have your tools handle SUNW deps the way they do? -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jan 10 00:53:43 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 09 Jan 2011 18:53:43 -0500 Subject: [csw-maintainers] Some new problems with manpages In-Reply-To: <4D2A46A5.9000903@wbonnet.net> References: <4D2A3B67.6000108@opencsw.org> <4D2A46A5.9000903@wbonnet.net> Message-ID: <1294617197-sup-6893@pinkfloyd.chass.utoronto.ca> Excerpts from William Bonnet's message of Sun Jan 09 18:37:09 -0500 2011: Hi William, > I have added a new icon on the top of the right sidebar. How about this > http://www-mockup.opencsw.org ? I like it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Mon Jan 10 01:41:13 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 10 Jan 2011 00:41:13 +0000 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 9 de Janeiro de 2011 23:11, Philip Brown escreveu: > On Sun, Jan 9, 2011 at 1:55 PM, Maciej (Matchek) Blizinski > wrote: >> >> It's not fair to say that we don't need to. ?When libslp is not on the >> filesystem, we do need to, but it's too late. ?You can imagine a >> different solution in which you test that certain shared library is >> there before you install a package. ?But this needs a coordinated >> effort from both developers of installation utilities, and is not >> likely to be done in a near future. > > > errr... maybe I'm missing something here. But we already have a > "test"/safety check. it works with pkg-get, pkgutil, and even plain > old > pkgadd. > Declare a dependency on SUNWslpu. > > Its always been "allowed" to do so, so we dont have to change any of > our standards to do so. > And it fulfills your "check before install" issue. > > What's wrong with that? In general, that we can't safely declare dependencies on SUNW packages. The same files are in different packages on different Solaris versions. For example, /usr/lib/sparcv9/libslp.so.1 is in SUNWslpx on Solaris 9 and in SUNWslpu on Solaris 10. In our particular case we could declare a dependency on SUNWslpu, because we don't have 64-bit cups libraries yet. When we compile 64-bit cups libraries, we won't be able to declare a dependency that would guarantee the presence of a 64-bit libslp. From bwalton at opencsw.org Mon Jan 10 01:51:17 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 09 Jan 2011 19:51:17 -0500 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: <1294620617-sup-8409@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sun Jan 09 19:41:13 -0500 2011: Hi Maciej, > In general, that we can't safely declare dependencies on SUNW > packages. The same files are in different packages on different > Solaris versions. For example, /usr/lib/sparcv9/libslp.so.1 is in > SUNWslpx on Solaris 9 and in SUNWslpu on Solaris 10. Thanks for this reminder. I'd forgotten that there was already a specific issue with the names involved here. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Mon Jan 10 09:39:56 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 10 Jan 2011 09:39:56 +0100 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: (Philip Brown's message of "Sun, 9 Jan 2011 12:40:34 -0800") References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Sun, Jan 9, 2011 at 10:46 AM, Peter FELECAN wrote: >> Philip Brown writes: >> >>> On Sun, Jan 9, 2011 at 8:57 AM, Peter FELECAN wrote: >>>> Philip Brown writes: >>>>... >>> you are strongly against listening to our users? >>> an odd sort of attitude. >> >> You're distorting things. Asking for an user base pool is always part of >> your strategy of last defense: playing the advocate of the nebulous user >> base. > > They become less "nebulous" if we actually ask them about their needs. > > Based on prior experience dealing with CSW user complaints, I know > that some users will be unhappy if we needlessly clone sun packages. > Ideally, you might accept my experience on this. > But, presuming you wont, and you doubt that users would be unhappy, we > should settle the issue by asking them. > > If on the other hand, you dont CARE if some users are unhappy, then > that's a whole other problem. This reminds me of market-droid arguments. In the end, however, the "user" will have a non functional cups. >> If an user has a strong opinion about our maintainceship the best >> he has to do is to propose patches and/or to become a maintainer. Of >> course, there is the users mailing list, the bug-tracking system that I >> read and if the request is reasonable an action follows. > > Making a large policy principle change, not bothering to check if it > makes users unhappy, and then reverting it down the road when users > bother to complain, is a sign of a user-hostile development process. > Not to mention an inefficient/chaotic process. > That's not a good thing for opencsw, in my opinion. > > This is not a maintainer-internal-only issue. This is a directly > user-facing issue, both in the specific slp case, but also in the much > larger general policy case. Personally I don't get this "user-facing" issue. Anyway, the question for which I answered initially was if I agree with an OpenSLP package. And it's still affirmative. -- Peter From bonivart at opencsw.org Mon Jan 10 10:22:29 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 10 Jan 2011 10:22:29 +0100 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: <1294616521-sup-2203@pinkfloyd.chass.utoronto.ca> References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> <1294616521-sup-2203@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Jan 10, 2011 at 12:49 AM, Ben Walton wrote: > [1] Peter B: Why do you have your tools handle SUNW deps the way they > ? ?do? Because it's not possible to calculate dependencies for packages that are not in the catalog. Our catalogs have never (for years at least) contained any SUNW dependencies so it wasn't a design criteria for me. /peter From james at opencsw.org Mon Jan 10 11:11:27 2011 From: james at opencsw.org (James Lee) Date: Mon, 10 Jan 2011 10:11:27 GMT Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: <20110110.10112700.2164600782@gyor.oxdrove.co.uk> On 09/01/11, 21:55:33, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel): > > Are you seriously looking to make this a policy? > > You know, "x11" is not "core/required" either. > > There are probably others. (not many, I admit, but still) > X11 stuff is different in that it's a desktop installation, which is > likely done using the complete package set. Installing a Solaris > desktop starting from a core install would be annoying, I don't think > anybody does that. X11 can be needed for command line programs that also have display functionality, X11 is not not just for desktops. $ ldd /opt/csw/bin/gm | grep X11 libX11.so.4 => /usr/openwin/lib/libX11.so.4 Adding system packages after patching could be a problem as the additions aren't patched. I'm sure when we discussed this before we recommended that users have a full install. The full OS is 1% of my newest machine but I've done full installs since 1GB hard drives (the OS was smaller then, 1GB sounded bigger too) because someday not doing so will bite me - as here. Why does anyone not do a full install? James. From pfelecan at opencsw.org Mon Jan 10 12:18:23 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 10 Jan 2011 12:18:23 +0100 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: (Dagobert Michelsen's message of "Sat, 8 Jan 2011 23:57:37 +0100") References: <1294407750-sup-7734@pinkfloyd.chass.utoronto.ca> <881332CF-A1CC-4B28-B191-14D854265DBD@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 08.01.2011 um 14:06 schrieb Peter FELECAN: >> Dagobert Michelsen writes: >>> Am 08.01.2011 um 10:43 schrieb Peter FELECAN: >>>> Ben Walton writes: >>>>> Excerpts from Peter FELECAN's message of Fri Jan 07 03:23:59 -0500 2011: >>>>> >>>>>> I think that we can use libintl without much worry; the kludgy way >>>>>> that they use to alleviate a SUN libc issue will fade away when the >>>>>> support for Solaris 9 is terminated. Anyway, caution is always a >>>>>> good stance. >>>>> >>>>> I have a mostly up-to-date build description for ggettext ready to go, >>>>> but I stalled it while waiting for the arbitration results. It needs >>>>> a bit of testing yet too. >>>>> >>>>> I think this package would benefit from being built separately on sol9 >>>>> and sol10 so that this issue only affects sol9. I'll try to get back >>>>> to this, but if someone else wants to pick it up, most of the work is >>>>> done already. >>>> >>>> I don't think that is necessary to have separate packages. In the code >>>> that I cited in my detailed mail, you can add a run-time detection of >>>> the release of Solaris on which it actually runs and act accordingly. I >>>> can provide an easy patch , preferably for 0.18.1. If we validate this, >>>> we can submit the patch upstream. >>> >>> That would be excellent!! >> >> Note that I'll publicly provide the patch only on request from the >> person who intent to package a new gettext set based on 0.18.1 or >> greater. > > As Ben already did most of the work I'll of course let him the honour > of submitting it :-) Of course I lend him a hand if necesssary, so > you can already start patching! Here are the patches, to apply on the 0.18.1 release of gettext, and the report that I made to the upstream project http://savannah.gnu.org/bugs/?32087 Summary: libpthread linkage detection on Solaris Project: GNU gettext Submitted by: pfelecan Submitted on: Mon 10 Jan 2011 11:31:30 AM CET Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any _______________________________________________________ Details: While I package gdb on Solaris 10 for the Open CSW project (http://www.opencsw.org/) I found that the dynamic detection for linking with pthread library by creating an ephemeral thread triggers an assertion in gdb's thread management. This is clearly a bug in gdb which I'll report on the corresponding system. However, this behavior can be avoided by changing the detection method. Solaris 9 and previous had an issue with defining the POSIX thread related symbols in libc but with non operational code. For this reason, a test in the configure process is made in gettext-runtime/m4/threadlib.m4 and if it detects that we are configuring on Solaris the dynamic detection in activated in the threadlib.c code in 3 sub-directories. On Solaris 10 and later releases the original reason is no more pertinent as the defined symbols in libc are correct. I tested this on SPARC and Intel using the code in threadlib.c and without linking with libpthread. Consequently I propose a 2 pronged patch: 1. if the package is configured on Solaris 10 or later do not activate PTHREAD_IN_USE_DETECTION_HARD. -------------- next part -------------- A non-text attachment was scrubbed... Name: thread_configure_solaris10.patch Type: text/x-patch Size: 1681 bytes Desc: Configuration URL: -------------- next part -------------- 2. if the package is configured and built on Solaris 9 or previous but run on Solaris 10 or later the test using the ephemeral thread is not necessary. -------------- next part -------------- A non-text attachment was scrubbed... Name: thread_run_solaris10.patch Type: text/x-patch Size: 4417 bytes Desc: Run URL: -------------- next part -------------- -- Peter From dam at opencsw.org Mon Jan 10 14:16:46 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 10 Jan 2011 14:16:46 +0100 Subject: [csw-maintainers] CPAN package using GAR v1 In-Reply-To: <4D291771.80601@wbonnet.net> References: <4D27C0B3.1060908@wbonnet.net> <4D291771.80601@wbonnet.net> Message-ID: <0917477C-A0D7-422B-AFE0-0DB819CA7FDB@opencsw.org> Hi William, Am 09.01.2011 um 03:03 schrieb William Bonnet: >> We have a list at http://wiki.opencsw.org/project-perl with modules >> needing an update. If you could produce a list of GAR V1 packages I'm >> interested in adding them to that list for a complete update as well. > > The switch has been done. Here is attached the list of packages from v1 and there status. 63 packages need to be update. This number can have a little error since 3 packages failed the upstream test. And uwatch2 does not detect yet change of cpan maintainer. This will be fixed in a couple of days. > > If you are interested in auto bumping the version let me know, it is available but not yet in production. These would make good candidates. Additionally, the v1 packages need to be converted to the new naming style and it should get rid of the gspecs and explicitly set PACAKGES and CATALOGNAME. Best regards -- Dago > > cheers > W. > > AnyData : Package is up-to-date. Current version is 0.10 > Apache-AuthPAM : Package is up-to-date. Current version is 0.01 > Apache-PAR : Package is up-to-date. Current version is 0.30 > Apache-Session : A new version of upstream files is available. Package can be upgraded from version 1.6 to 1.54 > Apache-Template : Package is up-to-date. Current version is 0.09 > Apache-Test : A new version of upstream files is available. Package can be upgraded from version 1.30 to 1.34 > Archive-Extract : A new version of upstream files is available. Package can be upgraded from version 0.16 to 0.34 > Archive-SelfExtract : Package is up-to-date. Current version is 1.3 > Array-Compare : A new version of upstream files is available. Package can be upgraded from version 1.13 to 2.01 > Array-Window : A new version of upstream files is available. Package can be upgraded from version 1.00 to 1.02 > Attribute-Handlers : Package is up-to-date. Current version is 0.78 > Bit-Vector : Package is up-to-date. Current version is 7.1 > BSD-Resource : A new version of upstream files is available. Package can be upgraded from version 1.28 to 1.2904 > C-Scan : Package is up-to-date. Current version is 0.74 > Cache : Package is up-to-date. Current version is 2.04 > Cache-Memcached : A new version of upstream files is available. Package can be upgraded from version 1.18 to 1.28 > Carp-Clan : Package is up-to-date. Current version is 6.04 > Catalyst : Package is up-to-date. Current version is 5.61 > CGI.pm : A new version of upstream files is available. Package can be upgraded from version 3.27 to 3.50 > CGI-Application : A new version of upstream files is available. Package can be upgraded from version 4.06 to 4.31 > CGI-Application-Dispatch : A new version of upstream files is available. Package can be upgraded from version 2.10 to 2.12 > CGI-Application-Plugin-LogDispatch : A new version of upstream files is available. Package can be upgraded from version 1.00 to 1.02 > CGI-Builder : Package is up-to-date. Current version is 1.36 > CGI-SpeedyCGI : Package is up-to-date. Current version is 2.22 > CGP-CLI : Package is up-to-date. Current version is 2.7.5 > Class-BlackHole : Package is up-to-date. Current version is 0.04 > Class-DBI : Package is up-to-date. Current version is 3.0.3 > Class-DBI-Loader : Package is up-to-date. Current version is 0.03 > Class-DBI-mysql : Package is up-to-date. Current version is 1.00 > Class-DBI-Pg : Package is up-to-date. Current version is 0.03 > Class-DBI-SQLite : Package is up-to-date. Current version is 0.11 > Class-ISA : Package is up-to-date. Current version is 0.33 > Class-Loader : Package is up-to-date. Current version is 2.03 > Class-Trigger : A new version of upstream files is available. Package can be upgraded from version 0.11 to 0.14 > Class-WhiteHole : Package is up-to-date. Current version is 0.04 > Config-IniFiles : Package is up-to-date. Current version is 2.38 > Convert-ASCII-Armour : Package is up-to-date. Current version is 1.4 > Convert-PEM : A new version of upstream files is available. Package can be upgraded from version 0.07 to 0.08 > Crypt-DES : Package is up-to-date. Current version is 2.05 > Crypt-DES_EDE3 : Package is up-to-date. Current version is 0.01 > Crypt-DH : Package is up-to-date. Current version is 0.06 > Crypt-DSA : Package is up-to-date. Current version is 0.14 > Crypt-OpenPGP : A new version of upstream files is available. Package can be upgraded from version 1.03 to 1.06 > Crypt-OpenSSL-DSA : Package is up-to-date. Current version is 0.13 > Crypt-OpenSSL-PKCS12 : A new version of upstream files is available. Package can be upgraded from version 0.3 to 0.5 > Crypt-OpenSSL-X509 : A new version of upstream files is available. Package can be upgraded from version 0.4 to 1.6 > Crypt-Primes : Package is up-to-date. Current version is 0.50 > Crypt-Random : Package is up-to-date. Current version is 1.25 > Crypt-Rijndael : Package is up-to-date. Current version is 1.09 > Crypt-RIPEMD160 : Package is up-to-date. Current version is 0.04 > Crypt-RSA : A new version of upstream files is available. Package can be upgraded from version 1.58 to 1.99 > Crypt-SSLeay : Package is up-to-date. Current version is 0.57 > Crypt-Twofish : A new version of upstream files is available. Package can be upgraded from version 2.12 to 2.14 > Curses : Package is up-to-date. Current version is 1.06 > Curses-UI : Package is up-to-date. Current version is 0.95 > Data-Buffer : Package is up-to-date. Current version is 0.04 > Data-Dump : A new version of upstream files is available. Package can be upgraded from version 1.08 to 1.19 > Data-Flow : A new version of upstream files is available. Package can be upgraded from version 0.09 to 1.02 > Data-ShowTable : Package is up-to-date. Current version is 3.3 > Data-UUID : A new version of upstream files is available. Package can be upgraded from version 1.203 to 1.217 > Date-Calc : Package is up-to-date. Current version is 6.3 > Date-Simple : Package is up-to-date. Current version is 3.02 > DBD-AnyData : A new version of upstream files is available. Package can be upgraded from version 0.08 to 0.09 > DBD-CSV : A new version of upstream files is available. Package can be upgraded from version 0.22 to 0.2002 > DBD-File : Package is up-to-date. Current version is 0.35 > DBD-mysql : A new version of upstream files is available. Package can be upgraded from version 3.0006 to 4.018 > DBIx-ContextualFetch : Package is up-to-date. Current version is 1.03 > DBIx-Password : A new version of upstream files is available. Package can be upgraded from version 1.8 to 1.9 > DBIx-SearchBuilder : A new version of upstream files is available. Package can be upgraded from version 1.45 to 1.54 > Devel-Cover : A new version of upstream files is available. Package can be upgraded from version 0.65 to 0.73 > Devel-Cycle : A new version of upstream files is available. Package can be upgraded from version 1.07 to 1.11 > Devel-LeakTrace : Package is up-to-date. Current version is 0.05 > Devel-Trace : Package is up-to-date. Current version is 0.10 > Digest-BubbleBabble : Package is up-to-date. Current version is 0.01 > Digest-MD2 : Package is up-to-date. Current version is 2.03 > Digest-Nilsimsa : Package is up-to-date. Current version is 0.06 > Email-Valid : Package is up-to-date. Current version is 0.15 > Env-Path : Package is up-to-date. Current version is 0.18 > Event : A new version of upstream files is available. Package can be upgraded from version 1.08 to 1.13 > Exception-Class : A new version of upstream files is available. Package can be upgraded from version 1.23 to 1.32 > Exception-Class-DBI : A new version of upstream files is available. Package can be upgraded from version 0.95 to 1.00 > ExtUtils-AutoInstall : Package is up-to-date. Current version is 0.63 > ExtUtils-XSBuilder : Package is up-to-date. Current version is 0.28 > File-chdir : Package is up-to-date. Current version is 0.06 > File-MMagic : Package is up-to-date. Current version is 1.27 > File-Modified : Package is up-to-date. Current version is 0.07 > File-NFSLock : Package is up-to-date. Current version is 1.20 > File-Type : Package is up-to-date. Current version is 0.22 > Font-AFM : A new version of upstream files is available. Package can be upgraded from version 1.19 to 1.20 > Frontier-RPC : Package is up-to-date. Current version is 0.07b4 > Gnome2 : Package is up-to-date. Current version is 1.001 > Gnome2-Canvas : Package is up-to-date. Current version is 1.001 > Gnome2-GConf : Package is up-to-date. Current version is 1.000 > Gnome2-Print : Package is up-to-date. Current version is 0.94 > Gnome2-VFS : Package is up-to-date. Current version is 1.003 > Gnome2-Wnck : Package is up-to-date. Current version is 0.02 > Graph : A new version of upstream files is available. Package can be upgraded from version 0.81 to 0.20105 > GraphViz : A new version of upstream files is available. Package can be upgraded from version 2.02 to 2.04 > Gtk2-GladeXML : Package is up-to-date. Current version is 1.004 > Gtk2-Ex-PodViewer : A new version of upstream files is available. Package can be upgraded from version 0.13 to 0.18 > Gtk2-TrayIcon : Package is up-to-date. Current version is 0.03 > HTML-CalendarMonth : A new version of upstream files is available. Package can be upgraded from version 1.18 to 1.25 > HTML-Element-Extended : A new version of upstream files is available. Package can be upgraded from version 1.17 to 1.18 > HTML-TokeParser-Simple : Package is up-to-date. Current version is 3.15 > HTTP-Body : Package is up-to-date. Current version is 0.5 > HTTP-DAV : Package is up-to-date. Current version is 0.31 > I18N-LangTags : Package is up-to-date. Current version is 0.35 > Ima-DBI : Package is up-to-date. Current version is 0.34 > Image-Info : Package is up-to-date. Current version is 1.16 > Image-Size : A new version of upstream files is available. Package can be upgraded from version 3.01 to 3.230 > IO-Pager : Package is up-to-date. Current version is 0.06 > IO-String : Package is up-to-date. Current version is 1.08 > IO-Util : Package is up-to-date. Current version is 1.5 > Jcode : A new version of upstream files is available. Package can be upgraded from version 2.06 to 2.07 > libxml-perl : Package is up-to-date. Current version is 0.08 > Locale-Maketext-Fuzzy : Package is up-to-date. Current version is 0.02 > Mail-Box-Parser-C : Package is up-to-date. Current version is 3.006 > Math-Bezier : Package is up-to-date. Current version is 0.01 > Math-GMP : Package is up-to-date. Current version is 2.04 > Math-Interpolate : Package is up-to-date. Current version is 1.05 > Math-Pari : A new version of upstream files is available. Package can be upgraded from version 2.010709 to 2.01080604 > MLDBM-Sync : Package is up-to-date. Current version is 0.30 > mod_perl : A new version of upstream files is available. Package can be upgraded from version 1.31 to 2.0.4 > mod_perl : Package is up-to-date. Current version is 2.0.4 > Module-ScanDeps : Package is up-to-date. Current version is 0.54 > Module-Versions-Report : Package is up-to-date. Current version is 1.02 > Net-SSH-Perl : Package is up-to-date. Current version is 1.25 > Object-MultiType : Package is up-to-date. Current version is 0.05 > OOTools : Package is up-to-date. Current version is 2.21 > PAR : Package is up-to-date. Current version is 0.90 > PAR-Dist : Package is up-to-date. Current version is 0.07 > Path-Class : A new version of upstream files is available. Package can be upgraded from version 0.17 to 0.23 > Pod-POM : Package is up-to-date. Current version is 0.17 > PodToHTML : Package is up-to-date. Current version is 0.05 > Proc-ProcessTable : Package is up-to-date. Current version is 0.45 > psh : Package is up-to-date. Current version is 1.8 > Regexp-Shellish : Package is up-to-date. Current version is 0.93 > RPC-XML : A new version of upstream files is available. Package can be upgraded from version 0.69 to 0.73 > Schedule-Cron : A new version of upstream files is available. Package can be upgraded from version 0.97 to 1.00 > sdf : Package is up-to-date. Current version is 2.001 > SOAP-WSDL : A new version of upstream files is available. Package can be upgraded from version 1.20 to 2.00.10 > sol-inst : Package is up-to-date. Current version is 0.90a > Solaris-DeviceTree : Package is up-to-date. Current version is 0.03 > Solaris-Sysconf : Package is up-to-date. Current version is 0.01 > SQL-Statement : Package is up-to-date. Current version is 1.15 > Statistics-Descriptive : Package is up-to-date. Current version is 2.6 > String-CRC32 : Package is up-to-date. Current version is 1.4 > String-ShellQuote : A new version of upstream files is available. Package can be upgraded from version 1.03 to 1.04 > Sub-Override : Package is up-to-date. Current version is 0.08 > SVN-Notify : A new version of upstream files is available. Package can be upgraded from version 2.64 to 2.80 > SVN-Simple : A new version of upstream files is available. Package can be upgraded from version 0.27 to 0.28 > Unix-Syslog : A new version of upstream files is available. Package can be upgraded from version 0.97 to 1.1 > Template-Extract : Package is up-to-date. Current version is 0.40 > Template-TAL : Package is up-to-date. Current version is 0.9 > Template-Toolkit : Package is up-to-date. Current version is 2.22 > Term-Cap : A new version of upstream files is available. Package can be upgraded from version 1.09 to 1.12 > TermReadKey : Package is up-to-date. Current version is 2.30 > Test-Class : A new version of upstream files is available. Package can be upgraded from version 0.11 to 0.36 > Test-Differences : Package is up-to-date. Current version is 0.47 > Test-Distribution : Package is up-to-date. Current version is 2.00 > Test-Inline : Package is up-to-date. Current version is 0.16 > Test-Manifest : A new version of upstream files is available. Package can be upgraded from version 1.17 to 1.23 > Test-Memory-Cycle : Package is up-to-date. Current version is 1.04 > Test-MockObject : Package is up-to-date. Current version is 1.09 > Test-XML : A new version of upstream files is available. Package can be upgraded from version 0.07 to 0.08 > Text-Autoformat : A new version of upstream files is available. Package can be upgraded from version 1.13 to 1.669002 > Text-Diff : Package is up-to-date. Current version is 0.35 > Text-Quoted : Package is up-to-date. Current version is 1.10 > Text-Scraper : Package is up-to-date. Current version is 0.02 > Text-Tabs+Wrap : Package is up-to-date. Current version is 2006.0711 > Text-Template : A new version of upstream files is available. Package can be upgraded from version 1.44 to 1.45 > Tie-DBI : Package is up-to-date. Current version is 1.02 > Tie-EncryptedHash : A new version of upstream files is available. Package can be upgraded from version 1.21 to 1.24 > Tie-MLDBM : Package is up-to-date. Current version is 1.04 > Time-HiRes : A new version of upstream files is available. Package can be upgraded from version 1.9707 to 1.9721 > Tree-Simple : A new version of upstream files is available. Package can be upgraded from version 1.16 to 1.18 > Unicode-Map8 : A new version of upstream files is available. Package can be upgraded from version 0.12 to 0.13 > Unicode-MapUTF8 : Package is up-to-date. Current version is 1.11 > UNIVERSAL-moniker : Package is up-to-date. Current version is 0.08 > UNIVERSAL-require : A new version of upstream files is available. Package can be upgraded from version 0.11 to 0.13 > VCP : Package is up-to-date. Current version is 0.9.20050110 > VCP-Dest-svk : Package is up-to-date. Current version is 0.29 > Want : Package is up-to-date. Current version is 0.18 > WWW-Mechanize : A new version of upstream files is available. Package can be upgraded from version 1.22 to 1.66 > X11-Protocol : Package is up-to-date. Current version is 0.56 > XML-Atom : A new version of upstream files is available. Package can be upgraded from version 0.25 to 0.37 > XML-AutoWriter : Package is up-to-date. Current version is 0.39 > XML-DOM : Package is up-to-date. Current version is 1.44 > XML-Encoding : Package is up-to-date. Current version is 1.01 > XML-GDOME : Package is up-to-date. Current version is 0.86 > XML-GDOME-XSLT : Package is up-to-date. Current version is 0.75 > XML-LibXML : A new version of upstream files is available. Package can be upgraded from version 1.70 to 1.62001 > XML-LibXML-Common : Package is up-to-date. Current version is 0.13 > XML-RegExp : Package is up-to-date. Current version is 0.03 > XML-Smart : Package is up-to-date. Current version is 1.6.9 > > -- > > William http://www.wbonnet.net > > http://www.opencsw.org Community SoftWare for Solaris > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From dam at opencsw.org Mon Jan 10 14:39:28 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 10 Jan 2011 14:39:28 +0100 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[12471] csw/mgar/pkg/cswutils/trunk/files/checkpkg In-Reply-To: References: Message-ID: Hi, Am 09.01.2011 um 18:29 schrieb Peter FELECAN: > theferret at users.sourceforge.net writes: > >> @@ -89,14 +195,13 @@ >> # check for badly set RUNPATHs. sigh. >> # Note that need to escape one /, so that it does not >> #trigger check if checking its own package >> - badpaths="[/]export/medusa [/]opt/build [/]export/home [/]usr/share [/]usr/local" >> + badpaths="[/]export/medusa [/]opt/build [/]export/home [/]usr/share [/]usr/local" Please remove /export/medusa and /opt/build. These are pathes from the Blastwave buildfarm which can't be in current builds. If they are present in a current package it is from legacy .so-libraries which must stay the way they are anyway. Best regards -- Dago From dam at opencsw.org Mon Jan 10 14:41:33 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 10 Jan 2011 14:41:33 +0100 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: <5798142E-4F9A-4076-87D3-9C5EEC5D33E9@opencsw.org> Hi, Am 09.01.2011 um 22:55 schrieb Maciej (Matchek) Blizinski: > No dia 9 de Janeiro de 2011 16:26, Philip Brown escreveu: >> On Sun, Jan 9, 2011 at 7:53 AM, Ben Walton wrote: >>> Excerpts from Peter Bonivart's message of Sun Jan 09 09:28:58 -0500 2011: >>> >>>> +1 >>> >>> +1 from me too. If we can't reliably use the sun provided libraries >>> but can deliver our own, we should. >> >> Are you seriously looking to make this a policy? >> You know, "x11" is not "core/required" either. >> There are probably others. (not many, I admit, but still) > > X11 stuff is different in that it's a desktop installation, which is > likely done using the complete package set. X11 stuff is different as providing CSW-specific X11 *breaks* OpenGL acceleration. Best regards -- Dago From dam at opencsw.org Mon Jan 10 15:07:38 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 10 Jan 2011 15:07:38 +0100 Subject: [csw-maintainers] CPAN package using GAR v1 In-Reply-To: <0917477C-A0D7-422B-AFE0-0DB819CA7FDB@opencsw.org> References: <4D27C0B3.1060908@wbonnet.net> <4D291771.80601@wbonnet.net> <0917477C-A0D7-422B-AFE0-0DB819CA7FDB@opencsw.org> Message-ID: <70B092BC-A680-42DE-8785-381BA0B5EBB4@opencsw.org> Hi William, Am 10.01.2011 um 14:16 schrieb Dagobert Michelsen: > Am 09.01.2011 um 03:03 schrieb William Bonnet: >>> We have a list at http://wiki.opencsw.org/project-perl with modules >>> needing an update. If you could produce a list of GAR V1 packages I'm >>> interested in adding them to that list for a complete update as well. >> >> The switch has been done. Here is attached the list of packages from v1 and there status. 63 packages need to be update. This number can have a little error since 3 packages failed the upstream test. And uwatch2 does not detect yet change of cpan maintainer. This will be fixed in a couple of days. >> >> If you are interested in auto bumping the version let me know, it is available but not yet in production. > > These would make good candidates. Additionally, the v1 packages need to be converted > to the new naming style and it should get rid of the gspecs and explicitly set > PACAKGES and CATALOGNAME. I would like to see which packages for these are unmaintained. William, we talked some time ago abour the xmlrpc-interface to the database. It would be cool if you could add a function to list the maintainer name for a package, then I could go over all of these and see which of them are owned by "retired" maintainers and which of them have not been released at all. Best regards -- Dago > > Best regards > > -- Dago > >> >> cheers >> W. >> >> AnyData : Package is up-to-date. Current version is 0.10 >> Apache-AuthPAM : Package is up-to-date. Current version is 0.01 >> Apache-PAR : Package is up-to-date. Current version is 0.30 >> Apache-Session : A new version of upstream files is available. Package can be upgraded from version 1.6 to 1.54 >> Apache-Template : Package is up-to-date. Current version is 0.09 >> Apache-Test : A new version of upstream files is available. Package can be upgraded from version 1.30 to 1.34 >> Archive-Extract : A new version of upstream files is available. Package can be upgraded from version 0.16 to 0.34 >> Archive-SelfExtract : Package is up-to-date. Current version is 1.3 >> Array-Compare : A new version of upstream files is available. Package can be upgraded from version 1.13 to 2.01 >> Array-Window : A new version of upstream files is available. Package can be upgraded from version 1.00 to 1.02 >> Attribute-Handlers : Package is up-to-date. Current version is 0.78 >> Bit-Vector : Package is up-to-date. Current version is 7.1 >> BSD-Resource : A new version of upstream files is available. Package can be upgraded from version 1.28 to 1.2904 >> C-Scan : Package is up-to-date. Current version is 0.74 >> Cache : Package is up-to-date. Current version is 2.04 >> Cache-Memcached : A new version of upstream files is available. Package can be upgraded from version 1.18 to 1.28 >> Carp-Clan : Package is up-to-date. Current version is 6.04 >> Catalyst : Package is up-to-date. Current version is 5.61 >> CGI.pm : A new version of upstream files is available. Package can be upgraded from version 3.27 to 3.50 >> CGI-Application : A new version of upstream files is available. Package can be upgraded from version 4.06 to 4.31 >> CGI-Application-Dispatch : A new version of upstream files is available. Package can be upgraded from version 2.10 to 2.12 >> CGI-Application-Plugin-LogDispatch : A new version of upstream files is available. Package can be upgraded from version 1.00 to 1.02 >> CGI-Builder : Package is up-to-date. Current version is 1.36 >> CGI-SpeedyCGI : Package is up-to-date. Current version is 2.22 >> CGP-CLI : Package is up-to-date. Current version is 2.7.5 >> Class-BlackHole : Package is up-to-date. Current version is 0.04 >> Class-DBI : Package is up-to-date. Current version is 3.0.3 >> Class-DBI-Loader : Package is up-to-date. Current version is 0.03 >> Class-DBI-mysql : Package is up-to-date. Current version is 1.00 >> Class-DBI-Pg : Package is up-to-date. Current version is 0.03 >> Class-DBI-SQLite : Package is up-to-date. Current version is 0.11 >> Class-ISA : Package is up-to-date. Current version is 0.33 >> Class-Loader : Package is up-to-date. Current version is 2.03 >> Class-Trigger : A new version of upstream files is available. Package can be upgraded from version 0.11 to 0.14 >> Class-WhiteHole : Package is up-to-date. Current version is 0.04 >> Config-IniFiles : Package is up-to-date. Current version is 2.38 >> Convert-ASCII-Armour : Package is up-to-date. Current version is 1.4 >> Convert-PEM : A new version of upstream files is available. Package can be upgraded from version 0.07 to 0.08 >> Crypt-DES : Package is up-to-date. Current version is 2.05 >> Crypt-DES_EDE3 : Package is up-to-date. Current version is 0.01 >> Crypt-DH : Package is up-to-date. Current version is 0.06 >> Crypt-DSA : Package is up-to-date. Current version is 0.14 >> Crypt-OpenPGP : A new version of upstream files is available. Package can be upgraded from version 1.03 to 1.06 >> Crypt-OpenSSL-DSA : Package is up-to-date. Current version is 0.13 >> Crypt-OpenSSL-PKCS12 : A new version of upstream files is available. Package can be upgraded from version 0.3 to 0.5 >> Crypt-OpenSSL-X509 : A new version of upstream files is available. Package can be upgraded from version 0.4 to 1.6 >> Crypt-Primes : Package is up-to-date. Current version is 0.50 >> Crypt-Random : Package is up-to-date. Current version is 1.25 >> Crypt-Rijndael : Package is up-to-date. Current version is 1.09 >> Crypt-RIPEMD160 : Package is up-to-date. Current version is 0.04 >> Crypt-RSA : A new version of upstream files is available. Package can be upgraded from version 1.58 to 1.99 >> Crypt-SSLeay : Package is up-to-date. Current version is 0.57 >> Crypt-Twofish : A new version of upstream files is available. Package can be upgraded from version 2.12 to 2.14 >> Curses : Package is up-to-date. Current version is 1.06 >> Curses-UI : Package is up-to-date. Current version is 0.95 >> Data-Buffer : Package is up-to-date. Current version is 0.04 >> Data-Dump : A new version of upstream files is available. Package can be upgraded from version 1.08 to 1.19 >> Data-Flow : A new version of upstream files is available. Package can be upgraded from version 0.09 to 1.02 >> Data-ShowTable : Package is up-to-date. Current version is 3.3 >> Data-UUID : A new version of upstream files is available. Package can be upgraded from version 1.203 to 1.217 >> Date-Calc : Package is up-to-date. Current version is 6.3 >> Date-Simple : Package is up-to-date. Current version is 3.02 >> DBD-AnyData : A new version of upstream files is available. Package can be upgraded from version 0.08 to 0.09 >> DBD-CSV : A new version of upstream files is available. Package can be upgraded from version 0.22 to 0.2002 >> DBD-File : Package is up-to-date. Current version is 0.35 >> DBD-mysql : A new version of upstream files is available. Package can be upgraded from version 3.0006 to 4.018 >> DBIx-ContextualFetch : Package is up-to-date. Current version is 1.03 >> DBIx-Password : A new version of upstream files is available. Package can be upgraded from version 1.8 to 1.9 >> DBIx-SearchBuilder : A new version of upstream files is available. Package can be upgraded from version 1.45 to 1.54 >> Devel-Cover : A new version of upstream files is available. Package can be upgraded from version 0.65 to 0.73 >> Devel-Cycle : A new version of upstream files is available. Package can be upgraded from version 1.07 to 1.11 >> Devel-LeakTrace : Package is up-to-date. Current version is 0.05 >> Devel-Trace : Package is up-to-date. Current version is 0.10 >> Digest-BubbleBabble : Package is up-to-date. Current version is 0.01 >> Digest-MD2 : Package is up-to-date. Current version is 2.03 >> Digest-Nilsimsa : Package is up-to-date. Current version is 0.06 >> Email-Valid : Package is up-to-date. Current version is 0.15 >> Env-Path : Package is up-to-date. Current version is 0.18 >> Event : A new version of upstream files is available. Package can be upgraded from version 1.08 to 1.13 >> Exception-Class : A new version of upstream files is available. Package can be upgraded from version 1.23 to 1.32 >> Exception-Class-DBI : A new version of upstream files is available. Package can be upgraded from version 0.95 to 1.00 >> ExtUtils-AutoInstall : Package is up-to-date. Current version is 0.63 >> ExtUtils-XSBuilder : Package is up-to-date. Current version is 0.28 >> File-chdir : Package is up-to-date. Current version is 0.06 >> File-MMagic : Package is up-to-date. Current version is 1.27 >> File-Modified : Package is up-to-date. Current version is 0.07 >> File-NFSLock : Package is up-to-date. Current version is 1.20 >> File-Type : Package is up-to-date. Current version is 0.22 >> Font-AFM : A new version of upstream files is available. Package can be upgraded from version 1.19 to 1.20 >> Frontier-RPC : Package is up-to-date. Current version is 0.07b4 >> Gnome2 : Package is up-to-date. Current version is 1.001 >> Gnome2-Canvas : Package is up-to-date. Current version is 1.001 >> Gnome2-GConf : Package is up-to-date. Current version is 1.000 >> Gnome2-Print : Package is up-to-date. Current version is 0.94 >> Gnome2-VFS : Package is up-to-date. Current version is 1.003 >> Gnome2-Wnck : Package is up-to-date. Current version is 0.02 >> Graph : A new version of upstream files is available. Package can be upgraded from version 0.81 to 0.20105 >> GraphViz : A new version of upstream files is available. Package can be upgraded from version 2.02 to 2.04 >> Gtk2-GladeXML : Package is up-to-date. Current version is 1.004 >> Gtk2-Ex-PodViewer : A new version of upstream files is available. Package can be upgraded from version 0.13 to 0.18 >> Gtk2-TrayIcon : Package is up-to-date. Current version is 0.03 >> HTML-CalendarMonth : A new version of upstream files is available. Package can be upgraded from version 1.18 to 1.25 >> HTML-Element-Extended : A new version of upstream files is available. Package can be upgraded from version 1.17 to 1.18 >> HTML-TokeParser-Simple : Package is up-to-date. Current version is 3.15 >> HTTP-Body : Package is up-to-date. Current version is 0.5 >> HTTP-DAV : Package is up-to-date. Current version is 0.31 >> I18N-LangTags : Package is up-to-date. Current version is 0.35 >> Ima-DBI : Package is up-to-date. Current version is 0.34 >> Image-Info : Package is up-to-date. Current version is 1.16 >> Image-Size : A new version of upstream files is available. Package can be upgraded from version 3.01 to 3.230 >> IO-Pager : Package is up-to-date. Current version is 0.06 >> IO-String : Package is up-to-date. Current version is 1.08 >> IO-Util : Package is up-to-date. Current version is 1.5 >> Jcode : A new version of upstream files is available. Package can be upgraded from version 2.06 to 2.07 >> libxml-perl : Package is up-to-date. Current version is 0.08 >> Locale-Maketext-Fuzzy : Package is up-to-date. Current version is 0.02 >> Mail-Box-Parser-C : Package is up-to-date. Current version is 3.006 >> Math-Bezier : Package is up-to-date. Current version is 0.01 >> Math-GMP : Package is up-to-date. Current version is 2.04 >> Math-Interpolate : Package is up-to-date. Current version is 1.05 >> Math-Pari : A new version of upstream files is available. Package can be upgraded from version 2.010709 to 2.01080604 >> MLDBM-Sync : Package is up-to-date. Current version is 0.30 >> mod_perl : A new version of upstream files is available. Package can be upgraded from version 1.31 to 2.0.4 >> mod_perl : Package is up-to-date. Current version is 2.0.4 >> Module-ScanDeps : Package is up-to-date. Current version is 0.54 >> Module-Versions-Report : Package is up-to-date. Current version is 1.02 >> Net-SSH-Perl : Package is up-to-date. Current version is 1.25 >> Object-MultiType : Package is up-to-date. Current version is 0.05 >> OOTools : Package is up-to-date. Current version is 2.21 >> PAR : Package is up-to-date. Current version is 0.90 >> PAR-Dist : Package is up-to-date. Current version is 0.07 >> Path-Class : A new version of upstream files is available. Package can be upgraded from version 0.17 to 0.23 >> Pod-POM : Package is up-to-date. Current version is 0.17 >> PodToHTML : Package is up-to-date. Current version is 0.05 >> Proc-ProcessTable : Package is up-to-date. Current version is 0.45 >> psh : Package is up-to-date. Current version is 1.8 >> Regexp-Shellish : Package is up-to-date. Current version is 0.93 >> RPC-XML : A new version of upstream files is available. Package can be upgraded from version 0.69 to 0.73 >> Schedule-Cron : A new version of upstream files is available. Package can be upgraded from version 0.97 to 1.00 >> sdf : Package is up-to-date. Current version is 2.001 >> SOAP-WSDL : A new version of upstream files is available. Package can be upgraded from version 1.20 to 2.00.10 >> sol-inst : Package is up-to-date. Current version is 0.90a >> Solaris-DeviceTree : Package is up-to-date. Current version is 0.03 >> Solaris-Sysconf : Package is up-to-date. Current version is 0.01 >> SQL-Statement : Package is up-to-date. Current version is 1.15 >> Statistics-Descriptive : Package is up-to-date. Current version is 2.6 >> String-CRC32 : Package is up-to-date. Current version is 1.4 >> String-ShellQuote : A new version of upstream files is available. Package can be upgraded from version 1.03 to 1.04 >> Sub-Override : Package is up-to-date. Current version is 0.08 >> SVN-Notify : A new version of upstream files is available. Package can be upgraded from version 2.64 to 2.80 >> SVN-Simple : A new version of upstream files is available. Package can be upgraded from version 0.27 to 0.28 >> Unix-Syslog : A new version of upstream files is available. Package can be upgraded from version 0.97 to 1.1 >> Template-Extract : Package is up-to-date. Current version is 0.40 >> Template-TAL : Package is up-to-date. Current version is 0.9 >> Template-Toolkit : Package is up-to-date. Current version is 2.22 >> Term-Cap : A new version of upstream files is available. Package can be upgraded from version 1.09 to 1.12 >> TermReadKey : Package is up-to-date. Current version is 2.30 >> Test-Class : A new version of upstream files is available. Package can be upgraded from version 0.11 to 0.36 >> Test-Differences : Package is up-to-date. Current version is 0.47 >> Test-Distribution : Package is up-to-date. Current version is 2.00 >> Test-Inline : Package is up-to-date. Current version is 0.16 >> Test-Manifest : A new version of upstream files is available. Package can be upgraded from version 1.17 to 1.23 >> Test-Memory-Cycle : Package is up-to-date. Current version is 1.04 >> Test-MockObject : Package is up-to-date. Current version is 1.09 >> Test-XML : A new version of upstream files is available. Package can be upgraded from version 0.07 to 0.08 >> Text-Autoformat : A new version of upstream files is available. Package can be upgraded from version 1.13 to 1.669002 >> Text-Diff : Package is up-to-date. Current version is 0.35 >> Text-Quoted : Package is up-to-date. Current version is 1.10 >> Text-Scraper : Package is up-to-date. Current version is 0.02 >> Text-Tabs+Wrap : Package is up-to-date. Current version is 2006.0711 >> Text-Template : A new version of upstream files is available. Package can be upgraded from version 1.44 to 1.45 >> Tie-DBI : Package is up-to-date. Current version is 1.02 >> Tie-EncryptedHash : A new version of upstream files is available. Package can be upgraded from version 1.21 to 1.24 >> Tie-MLDBM : Package is up-to-date. Current version is 1.04 >> Time-HiRes : A new version of upstream files is available. Package can be upgraded from version 1.9707 to 1.9721 >> Tree-Simple : A new version of upstream files is available. Package can be upgraded from version 1.16 to 1.18 >> Unicode-Map8 : A new version of upstream files is available. Package can be upgraded from version 0.12 to 0.13 >> Unicode-MapUTF8 : Package is up-to-date. Current version is 1.11 >> UNIVERSAL-moniker : Package is up-to-date. Current version is 0.08 >> UNIVERSAL-require : A new version of upstream files is available. Package can be upgraded from version 0.11 to 0.13 >> VCP : Package is up-to-date. Current version is 0.9.20050110 >> VCP-Dest-svk : Package is up-to-date. Current version is 0.29 >> Want : Package is up-to-date. Current version is 0.18 >> WWW-Mechanize : A new version of upstream files is available. Package can be upgraded from version 1.22 to 1.66 >> X11-Protocol : Package is up-to-date. Current version is 0.56 >> XML-Atom : A new version of upstream files is available. Package can be upgraded from version 0.25 to 0.37 >> XML-AutoWriter : Package is up-to-date. Current version is 0.39 >> XML-DOM : Package is up-to-date. Current version is 1.44 >> XML-Encoding : Package is up-to-date. Current version is 1.01 >> XML-GDOME : Package is up-to-date. Current version is 0.86 >> XML-GDOME-XSLT : Package is up-to-date. Current version is 0.75 >> XML-LibXML : A new version of upstream files is available. Package can be upgraded from version 1.70 to 1.62001 >> XML-LibXML-Common : Package is up-to-date. Current version is 0.13 >> XML-RegExp : Package is up-to-date. Current version is 0.03 >> XML-Smart : Package is up-to-date. Current version is 1.6.9 >> >> -- >> >> William http://www.wbonnet.net >> >> http://www.opencsw.org Community SoftWare for Solaris >> >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From bwalton at opencsw.org Mon Jan 10 15:17:24 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 10 Jan 2011 09:17:24 -0500 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> <1294616521-sup-2203@pinkfloyd.chas s.utoronto.ca> Message-ID: <1294668925-sup-4890@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Mon Jan 10 04:22:29 -0500 2011: Hi Peter, > Because it's not possible to calculate dependencies for packages > that are not in the catalog. Our catalogs have never (for years at > least) contained any SUNW dependencies so it wasn't a design > criteria for me. Makes sense. I guess not having them in the catalog or handled by pkgutil isn't a big deal anyway as the underlying pkgadd will still note the requirement (if it's missing) for any package that does declare the dependency. Overally, this isn't a good idea anyway. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Mon Jan 10 16:37:17 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 10 Jan 2011 15:37:17 +0000 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: <1294668925-sup-4890@pinkfloyd.chass.utoronto.ca> References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> <1294668925-sup-4890@pinkfloyd.chass.utoronto.ca> Message-ID: Let's sum it up. If I understand correctly, permission to depend on openslp has not been granted. Instead, we can declare a dependency on SUNWslpu. It will not result in automatic installation of libslp, but will display a message during package installation, that SUNWslpu is missing. The 64-bit libslp is in differently named packages between Solaris 9 and 10, which could be potentially be a showstopper. However, in the case of cups, because (by coincidence) there are no 64-bit cups libraries, we don't need to declare a dependency providing the 64-bit libslp. Therefore, we'll declare a dependency on SUNWslpu until 64-bit cups libraries come along. We'll revisit the issue then. Is that the result of our discussion? From william at wbonnet.net Mon Jan 10 17:32:40 2011 From: william at wbonnet.net (William Bonnet) Date: Mon, 10 Jan 2011 17:32:40 +0100 Subject: [csw-maintainers] CPAN package using GAR v1 In-Reply-To: <4D2B1F96.1010501@on-x.com> References: <4D27C0B3.1060908@wbonnet.net> <4D291771.80601@wbonnet.net> <0917477C-A0D7-422B-AFE0-0DB819CA7FDB@opencsw.org> <70B092BC-A680-42DE-8785-381BA0B5EBB4@opencsw.org> <4D2B1F96.1010501@on-x.com> Message-ID: <4D2B34A8.4020505@wbonnet.net> Hi > >> I would like to see which packages for these are unmaintained. >> William, we talked some time ago abour the xmlrpc-interface to the >> database. >> It would be cool if you could add a function to list the maintainer >> name for >> a package, then I could go over all of these and see which of them >> are owned >> by "retired" maintainers and which of them have not been released at >> all. It's ready but not yet on production. There will be a target: gmake get-maintainer which outputs the name and status of the maintainer for each package in the current directory. It's very handy when looking to a package. I'll try to push it asap, first i need to push the qa database, and there is still a few bugs to hunt. It should go on the mockup this week. cheers W. From pfelecan at opencsw.org Mon Jan 10 17:34:11 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 10 Jan 2011 17:34:11 +0100 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: (Maciej Blizinski's message of "Mon, 10 Jan 2011 15:37:17 +0000") References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> <1294668925-sup-4890@pinkfloyd.chass.utoronto.ca> Message-ID: "Maciej (Matchek) Blizinski" writes: > Let's sum it up. If I understand correctly, permission to depend on > openslp has not been granted. Instead, we can declare a dependency on > SUNWslpu. It will not result in automatic installation of libslp, but > will display a message during package installation, that SUNWslpu is > missing. The 64-bit libslp is in differently named packages between > Solaris 9 and 10, which could be potentially be a showstopper. > However, in the case of cups, because (by coincidence) there are no > 64-bit cups libraries, we don't need to declare a dependency providing > the 64-bit libslp. Therefore, we'll declare a dependency on SUNWslpu > until 64-bit cups libraries come along. We'll revisit the issue then. > > Is that the result of our discussion? Not really. There were 4 people (you, Ben, Peter Bonivart and myself) agreeing with a Open CSW package for openslp. Phil is against. My interpretation is exactly the reverse of your summary. Anyhow, if you changed your mind I don't have a thing to say. -- Peter From maciej at opencsw.org Mon Jan 10 17:38:47 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 10 Jan 2011 16:38:47 +0000 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> <1294668925-sup-4890@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 10 de Janeiro de 2011 16:34, Peter FELECAN escreveu: >> Is that the result of our discussion? > > Not really. There were 4 people (you, Ben, Peter Bonivart and myself) > agreeing with a Open CSW package for openslp. Phil is against. My > interpretation is exactly the reverse of your summary. Anyhow, if you > changed your mind I don't have a thing to say. I haven't changed my mind, I only summarized the discussion. I haven't been granted permission, there's nothing I can do, is there? From bonivart at opencsw.org Mon Jan 10 17:52:39 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 10 Jan 2011 17:52:39 +0100 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> <1294668925-sup-4890@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Jan 10, 2011 at 5:38 PM, Maciej (Matchek) Blizinski wrote: > I haven't changed my mind, I only summarized the discussion. ?I > haven't been granted permission, there's nothing I can do, is there? The release manager should enforce agreed upon solutions, not make up his own on a package-by-package basis while holding our packages hostage to gain leverage. /peter From maciej at opencsw.org Mon Jan 10 17:52:33 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 10 Jan 2011 16:52:33 +0000 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> <1294668925-sup-4890@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 10 de Janeiro de 2011 16:38, Maciej (Matchek) Blizinski escreveu: > No dia 10 de Janeiro de 2011 16:34, Peter FELECAN > escreveu: >>> Is that the result of our discussion? >> >> Not really. There were 4 people (you, Ben, Peter Bonivart and myself) >> agreeing with a Open CSW package for openslp. Phil is against. My >> interpretation is exactly the reverse of your summary. Anyhow, if you >> changed your mind I don't have a thing to say. > > I haven't changed my mind, I only summarized the discussion. ?I > haven't been granted permission, there's nothing I can do, is there? By the way, I've experimented a bit with asciidoc and tables, to see if I can quickly sketch a pro-con table. Here's the result: http://buildfarm.opencsw.org/~maciej/slp-discuss/ Maciej From pfelecan at opencsw.org Mon Jan 10 20:56:23 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 10 Jan 2011 20:56:23 +0100 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: (Maciej Blizinski's message of "Mon, 10 Jan 2011 16:52:33 +0000") References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> <1294668925-sup-4890@pinkfloyd.chass.utoronto.ca> Message-ID: "Maciej (Matchek) Blizinski" writes: > No dia 10 de Janeiro de 2011 16:38, Maciej (Matchek) Blizinski > escreveu: >> No dia 10 de Janeiro de 2011 16:34, Peter FELECAN >> escreveu: >>>> Is that the result of our discussion? >>> >>> Not really. There were 4 people (you, Ben, Peter Bonivart and myself) >>> agreeing with a Open CSW package for openslp. Phil is against. My >>> interpretation is exactly the reverse of your summary. Anyhow, if you >>> changed your mind I don't have a thing to say. >> >> I haven't changed my mind, I only summarized the discussion. ?I >> haven't been granted permission, there's nothing I can do, is there? > > By the way, I've experimented a bit with asciidoc and tables, to see > if I can quickly sketch a pro-con table. Here's the result: > > http://buildfarm.opencsw.org/~maciej/slp-discuss/ Which makes quite clear which is the optimal choice for "*users*". -- Peter From bwalton at opencsw.org Mon Jan 10 22:19:29 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 10 Jan 2011 16:19:29 -0500 Subject: [csw-maintainers] [RFE] Add version to gmake pkglist output In-Reply-To: <6C8F1E54-F0DE-4E1C-9B3F-5D3F0E55475C@wbonnet.net> References: <6C8F1E54-F0DE-4E1C-9B3F-5D3F0E55475C@wbonnet.net> Message-ID: <1294694341-sup-8597@pinkfloyd.chass.utoronto.ca> Excerpts from William Bonnet's message of Fri Jan 07 11:27:17 -0500 2011: Hi William, > [wbonnet at current9s:~/gar/pkg/cpan/Object-Accessor/trunk]$ gmake pkglist > /home/wbonnet/gar/pkg/cpan/Object-Accessor/trunk > pm_objaccessor CSWpmobjaccessor 0.36 I don't see any reason not to add this info... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From skayser at opencsw.org Mon Jan 10 23:15:03 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 10 Jan 2011 23:15:03 +0100 Subject: [csw-maintainers] Wintercamp 2010/2011? In-Reply-To: <4D238337.8040604@opencsw.org> References: <20101207162737.GB30288@sebastiankayser.de> <23E107A9-D5DE-44EB-A7FE-B54E8AFDA937@opencsw.org> <20101207211455.GE30288@sebastiankayser.de> <1EA6BB8D-C7B6-4C7B-A4E1-7D4CFA5036EF@opencsw.org> <20101223122148.GC4011@sebastiankayser.de> <4D238337.8040604@opencsw.org> Message-ID: <4D2B84E7.1060704@opencsw.org> ?hsan Do?an wrote on 04.01.2011 21:29: > Am 23.12.2010 13:38, schrieb Maciej (Matchek) Blizinski: > >>> Any further would-like-to-attendees please submit your availability on >>> the Doodle poll. Current poll status suggests the weekend of 19/20th >>> February. Are the dates still good for all those who voted (in >>> particular for you, Maciej, as our host)? If not, please update your >>> availability. >> >> Yes, these dates are good. > > Also fine for me. > > So, is it then Luxembourg? Dublin for winter camp, Luxembourg for summer camp. At least that's what I scratched together from my grey matter and the archives. [1] All settled? /me eager to book the flights. Sebastian [1] http://lists.opencsw.org/pipermail/maintainers/2010-December/013343.html From william at wbonnet.net Tue Jan 11 17:06:52 2011 From: william at wbonnet.net (William Bonnet) Date: Tue, 11 Jan 2011 17:06:52 +0100 Subject: [csw-maintainers] An idea: OpenCSW on FLOSS Weekly In-Reply-To: <4D2C7E9E.2080402@on-x.com> References: <4D2C7E9E.2080402@on-x.com> Message-ID: <4D2C801C.9040504@wbonnet.net> Hi could just check the weekly package announces for that, if they are >>> archived somewhers. I think they are. >> Does anyone have that data at hand? William? You can get the statistics in graphic mode at the following URL : http://www.opencsw.org/get-it/package-statistics/ The raw data are stored in the spmtcsw database table pkg_stats_statistics. Here the data since opencsw creation (no track of blastwave era) +---------+-----------+------------+--------------------+---------------------+-------------------+ | ID_STAT | STAT_YEAR | STAT_MONTH | STAT_PACKAGE_COUNT | STAT_CREATION_COUNT | STAT_UPDATE_COUNT | +---------+-----------+------------+--------------------+---------------------+-------------------+ | 1 | 2008 | 5 | 1803 | 1803 | 0 | | 2 | 2008 | 10 | 1806 | 3 | 0 | | 3 | 2008 | 12 | 1835 | 29 | 24 | | 8 | 2009 | 1 | 1857 | 22 | 51 | | 9 | 2009 | 2 | 1871 | 14 | 209 | | 10 | 2009 | 3 | 1927 | 56 | 241 | | 11 | 2009 | 4 | 1945 | 18 | 183 | | 12 | 2009 | 5 | 1980 | 35 | 149 | | 13 | 2009 | 6 | 2036 | 56 | 123 | | 14 | 2009 | 7 | 2047 | 11 | 44 | | 15 | 2009 | 8 | 2081 | 34 | 248 | | 16 | 2009 | 9 | 2102 | 21 | 203 | | 17 | 2009 | 10 | 2151 | 49 | 96 | | 18 | 2009 | 11 | 2193 | 42 | 126 | | 19 | 2009 | 12 | 2212 | 19 | 329 | | 20 | 2010 | 1 | 2254 | 42 | 97 | | 21 | 2010 | 2 | 2386 | 132 | 148 | | 22 | 2010 | 3 | 2487 | 101 | 249 | | 23 | 2010 | 4 | 2531 | 44 | 133 | | 24 | 2010 | 5 | 2502 | 12 | 58 | | 25 | 2010 | 6 | 2559 | 69 | 106 | | 26 | 2010 | 7 | 2575 | 16 | 77 | | 27 | 2010 | 8 | 2588 | 13 | 54 | | 28 | 2010 | 9 | 2594 | 6 | 112 | | 29 | 2010 | 10 | 2626 | 32 | 63 | | 30 | 2010 | 11 | 2662 | 36 | 47 | | 31 | 2010 | 12 | 2700 | 38 | 95 | | 32 | 2011 | 1 | 2724 | 24 | 24 | +---------+-----------+------------+--------------------+---------------------+-------------------+ cheers W. From bonivart at opencsw.org Tue Jan 11 17:20:15 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 11 Jan 2011 17:20:15 +0100 Subject: [csw-maintainers] Mirror push needed Message-ID: There's no updates on the mirrors since Jan 7th, there's a bunch of packages with status "batched" since then and I need a few of them to continue with the Perl packages. /peter From phil at bolthole.com Tue Jan 11 22:10:19 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 11 Jan 2011 13:10:19 -0800 Subject: [csw-maintainers] Mirror push needed In-Reply-To: References: Message-ID: okiedokie. should be out in the next 30 mins. On 1/11/11, Peter Bonivart wrote: > There's no updates on the mirrors since Jan 7th, there's a bunch of > packages with status "batched" since then and I need a few of them to > continue with the Perl packages. > > /peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From phil at bolthole.com Tue Jan 11 22:20:03 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 11 Jan 2011 13:20:03 -0800 Subject: [csw-maintainers] Mirror push needed In-Reply-To: References: Message-ID: Drat. push aborted, problem with catalog. Bug Dago to update: ERROR! Dependency CSWlibicu42 of package CSWlibicu is missing. should be 46, not 42, I believe. On 1/11/11, Philip Brown wrote: > okiedokie. should be out in the next 30 mins. > > > On 1/11/11, Peter Bonivart wrote: >> There's no updates on the mirrors since Jan 7th, there's a bunch of >> packages with status "batched" since then and I need a few of them to >> continue with the Perl packages. >> >> /peter >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> > From william at wbonnet.net Wed Jan 12 01:01:01 2011 From: william at wbonnet.net (William Bonnet) Date: Wed, 12 Jan 2011 01:01:01 +0100 Subject: [csw-maintainers] [website] Front page update Message-ID: <4D2CEF3D.7030900@wbonnet.net> Hi I have updated the front page of the web site. I tried to take in account most of comments i received. The work is not yet finished, especially on the front page i will modify search and feeds links in the next day. Please don't hesitate to send your comments. cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From dam at opencsw.org Wed Jan 12 09:10:39 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 12 Jan 2011 09:10:39 +0100 Subject: [csw-maintainers] Mirror push needed In-Reply-To: References: Message-ID: <34ED0509-96A0-4C2A-BCF0-51CE4093332C@opencsw.org> Hi Phil, Am 11.01.2011 um 22:20 schrieb Philip Brown: > Drat. push aborted, problem with catalog. > Bug Dago to update: > > ERROR! Dependency CSWlibicu42 of package CSWlibicu is missing. > > should be 46, not 42, I believe. No, that is the legacy .co where libicu is depending on to keep legacy applications happy. I copied these over: -rw-r--r-- 1 dam csw 2077 Jan 4 14:31 libicu-4.6,REV=2011.01.04-SunOS5.9-all-CSW.pkg.gz -rw-r--r-- 1 dam csw 7644884 Jan 4 14:03 libicu42-4.2.1,REV=2011.01.04-SunOS5.9-i386-CSW.pkg.gz -rw-r--r-- 1 dam csw 8328435 Jan 4 14:02 libicu42-4.2.1,REV=2011.01.04-SunOS5.9-sparc-CSW.pkg.gz If there is more missing and I am not around just grab it from /home/experimental/libicu. Bets regards -- Dago > > > > On 1/11/11, Philip Brown wrote: >> okiedokie. should be out in the next 30 mins. >> >> >> On 1/11/11, Peter Bonivart wrote: >>> There's no updates on the mirrors since Jan 7th, there's a bunch of >>> packages with status "batched" since then and I need a few of them to >>> continue with the Perl packages. >>> >>> /peter >>> _______________________________________________ >>> maintainers mailing list >>> maintainers at lists.opencsw.org >>> https://lists.opencsw.org/mailman/listinfo/maintainers >>> .:: This mailing list's archive is public. ::. >>> >> > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From bonivart at opencsw.org Wed Jan 12 16:25:22 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 12 Jan 2011 16:25:22 +0100 Subject: [csw-maintainers] /testing Please help test new Perl package with changed INC Message-ID: After years of having a Perl binary with a weird default INC we will now change it. This is the current INC: root at sol10[trunk]$ pkgparam CSWperl VERSION 5.10.1,REV=2010.12.10 ... Compiled at Dec 6 2010 17:53:49 @INC: /opt/csw/lib/perl/5.10.1 /opt/csw/share/perl/5.10.1 /opt/csw/lib/perl/site_perl /opt/csw/share/perl/site_perl /opt/csw/share/perl/site_perl /opt/csw/lib/perl/csw /opt/csw/share/perl/csw /opt/csw/share/perl/csw . This means that when we package the latest version of a module that is included in core Perl it will not be used by default since the INC places built-in (5.10.1) before vendor (csw). It also means that if you build your own modules, via e.g. CPAN, they will not be used either if they are also in core Perl. Locally one can manipulate the INC but we think it's time for a more reasonable default one. This is the new INC, the same as Red Hat Enterprise Linux 5 uses: root at sol10[trunk]$ pkgparam CSWperl VERSION 5.10.1,REV=2011.01.06 ... Compiled at Jan 5 2011 18:06:53 @INC: /opt/csw/lib/perl/site_perl /opt/csw/share/perl/site_perl /opt/csw/share/perl/site_perl /opt/csw/lib/perl/csw /opt/csw/share/perl/csw /opt/csw/share/perl/csw /opt/csw/lib/perl/5.10.1 /opt/csw/share/perl/5.10.1 . The above would first use your locally built modules (site_perl), then our packages modules (csw) and last the built-in modules from core Perl. Note that this doesn't matter if a CSW module package (or your CPAN module) is not in core Perl, it would of course be found with the old INC as well, the problem is when you want to use a newer version of something that is included in core Perl. Does anyone object to this change? Any reason we should not change this? We have also fixed an issue with DB_File.pm missing from the latest package. See https://www.opencsw.org/mantis/view.php?id=4544. You can install the new package with: # pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/perl-new -i perl Direct links to the packages: http://buildfarm.opencsw.org/experimental/perl-new/perl-5.10.1,REV=2011.01.06-SunOS5.9-sparc-CSW.pkg.gz http://buildfarm.opencsw.org/experimental/perl-new/perl-5.10.1,REV=2011.01.06-SunOS5.9-i386-CSW.pkg.gz http://buildfarm.opencsw.org/experimental/perl-new/perldoc-5.10.1,REV=2011.01.06-SunOS5.9-all-CSW.pkg.gz /peter From phil at bolthole.com Wed Jan 12 18:41:30 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 12 Jan 2011 09:41:30 -0800 Subject: [csw-maintainers] Mirror push needed In-Reply-To: <34ED0509-96A0-4C2A-BCF0-51CE4093332C@opencsw.org> References: <34ED0509-96A0-4C2A-BCF0-51CE4093332C@opencsw.org> Message-ID: On 1/12/11, Dagobert Michelsen wrote: > Hi Phil, > > Am 11.01.2011 um 22:20 schrieb Philip Brown: >> Drat. push aborted, problem with catalog. >> Bug Dago to update: >> >> ERROR! Dependency CSWlibicu42 of package CSWlibicu is missing. >> >> should be 46, not 42, I believe. > > No, that is the legacy .co where libicu is depending on to keep > legacy applications happy. oh right, whoops. thanks for the recopy. From gadavis at opencsw.org Wed Jan 12 19:45:39 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Wed, 12 Jan 2011 10:45:39 -0800 Subject: [csw-maintainers] Request for review of Fortran additions to Gar In-Reply-To: References: <4CFD421B.6080504@opencsw.org> Message-ID: <305EF50E-117E-45DA-958F-929530579459@opencsw.org> If there are no objections, can we go ahead and get this merged into the mainline v2? On Dec 6, 2010, at 3:00 PM, Maciej (Matchek) Blizinski wrote: > No dia 6 de Dezembro de 2010 20:05, Geoff Davis escreveu: >> Hi all, >> >> I thought I had submitted a request for this to the mailing list a while >> ago, but it has gone missing from my mailing list archives. >> >> I have implemented some changes to GAR to handle Fortran compilation using >> the Sun Studio and GCC compilers for Fortran. In particular, it sets the >> F77, FC, FFLAGS, and FCFLAGS variables to what I believe are sane values. I >> have been using them to build some packages, and would like to see if I can >> get them folded into the mainline GAR v2 distribution. >> >> My GAR branch is >> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2-fortran > > I was trying to look at the changes - in some sort of a diff view, > where I could see what changes have been made in the v2-fortran > branch. When I compared the v2-fortran directory from the point of > branching to its current state, I was seeing also changes that must > have been merged from the v2 branch. When I compared v2 and > v2-fortran directories, I was seeing changes that have not yet been > merged. So I took the liberty to merge changes from master to > v2-fortran. > > svn diff https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2{,-fortran} > | tee fortran.patch > > The command takes a bit of time to run. Here's the output: > > http://paste.pocoo.org/show/301600/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From maciej at opencsw.org Wed Jan 12 19:50:07 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 12 Jan 2011 18:50:07 +0000 Subject: [csw-maintainers] Request for review of Fortran additions to Gar In-Reply-To: <305EF50E-117E-45DA-958F-929530579459@opencsw.org> References: <4CFD421B.6080504@opencsw.org> <305EF50E-117E-45DA-958F-929530579459@opencsw.org> Message-ID: No dia 12 de Janeiro de 2011 18:45, Geoff Davis escreveu: > If there are no objections, can we go ahead and get this merged into the mainline v2? Please go ahead. Please review your changes before committing the code. Your change to v2 should be equal to the one I posted some time ago[1]. [1] http://paste.pocoo.org/show/301600/ From skayser at opencsw.org Wed Jan 12 23:18:48 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 12 Jan 2011 23:18:48 +0100 Subject: [csw-maintainers] [website] Front page update In-Reply-To: <4D2CEF3D.7030900@wbonnet.net> References: <4D2CEF3D.7030900@wbonnet.net> Message-ID: <20110112221848.GE4011@sebastiankayser.de> Hi William, * William Bonnet wrote: > I have updated the front page of the web site. I tried to take in > account most of comments i received. The work is not yet finished, > especially on the front page i will modify search and feeds links in the > next day. > > Please don't hesitate to send your comments. some initial feedback/thoughts: 1) News vs. announcements: I am aware of the motivation for different categories, but honestly think - and I know that I am repeating myself here - that this should be merged in the spirit of simplicity / less confusion (especially given our moderate update frequency). I could imagine to see this replaced by a section which references externals articles, news items, or even Twitter posts. Section name "External news & articles", "OpenCSW in the press" or similar. 2) Icon navbar to the right: People will most likely want to install our packages when they come to the page for the first time. Thus, I would strongly suggest to put "GET IT" first. Suggested overall sorting (implies grouping, can we add spacing?): GET IT \ PACKAGES -- package related SEARCH / FEEDS #OPENCSW \ BUG TRACKER -- communication channels MAILING LISTS / WIKI Or could we further reduce this list by grouping the communication channels into a single "SUPPORT Get in touch with us" or similar icon which links to http://www.opencsw.org/support/ .. (which in turn could then be structured into short sections "Mailing lists", "Bug Tracker", ...). Just so that we provide a well selected, short list of main navigation entry points on the front page. 3) Releases and updates: Is this going to be filled with our automated package release feed? Currently it might give the impression that our last released package is from 25th of August. 4) BUG TRACKER. Re-wording suggestion "View or report issues" instead of "Access to Mantis". 5) FEEDS. Right navbar entry is fine, but I would suggest to remove the redundant Feeds entry from the top navbar. Sebastian From bonivart at opencsw.org Thu Jan 13 00:01:28 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 13 Jan 2011 00:01:28 +0100 Subject: [csw-maintainers] Mirror push needed In-Reply-To: References: <34ED0509-96A0-4C2A-BCF0-51CE4093332C@opencsw.org> Message-ID: On Wed, Jan 12, 2011 at 6:41 PM, Philip Brown wrote: > On 1/12/11, Dagobert Michelsen wrote: >> Hi Phil, >> >> Am 11.01.2011 um 22:20 schrieb Philip Brown: >>> Drat. push aborted, problem with catalog. >>> Bug Dago to update: >>> >>> ERROR! Dependency CSWlibicu42 of package CSWlibicu is missing. >>> >>> should be 46, not 42, I believe. >> >> No, that is the legacy .co where libicu is depending on to keep >> legacy applications happy. > > oh right, whoops. > > thanks for the recopy. So now could we get a mirror push? /peter From skayser at opencsw.org Thu Jan 13 00:40:25 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 13 Jan 2011 00:40:25 +0100 Subject: [csw-maintainers] [website] drop empty pages and placeholders? Message-ID: <20110112234025.GG4011@sebastiankayser.de> Hi, while looking at our website for William's changes to the front page, I noticed a couple of (near) empty pages. Could we drop these? http://www.opencsw.org/use-it/how-to-upgrade/ http://www.opencsw.org/use-it/the-tools/ http://www.opencsw.org/support/documentation/ http://www.opencsw.org/extend-it/contribute-docs/ http://www.opencsw.org/extend-it/donate/ For one, to avoid linking empty content and for two, to reduce the amount of pages that we have (to maintain). Sebastian From skayser at opencsw.org Thu Jan 13 00:45:20 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 13 Jan 2011 00:45:20 +0100 Subject: [csw-maintainers] [website] procedure/mechanism for proposed changes? Message-ID: <20110112234520.GH4011@sebastiankayser.de> Hi, what's the "official" way to propose changes to pages on our web site? I'd like to tackle some content-wise and would appreciate a set of additional eyes for review purposes. Sebastian From william at wbonnet.net Thu Jan 13 01:29:57 2011 From: william at wbonnet.net (William Bonnet) Date: Thu, 13 Jan 2011 01:29:57 +0100 Subject: [csw-maintainers] [website] procedure/mechanism for proposed changes? In-Reply-To: <20110112234520.GH4011@sebastiankayser.de> References: <20110112234520.GH4011@sebastiankayser.de> Message-ID: <4D2E4785.8030202@wbonnet.net> Hi Sebastien Thanks for taking time to do some review on the web site :) > what's the "official" way to propose changes to pages on our web site? Actually we don't have one. It has to be defined. From a wordpress point of view, articles have different status, including a draft status. Drafts are not visible on the web site. So i propose to create draft of articles you would like to modify and get reviewed. Now question is who is going to review articles :) I think it depends on the content... Reviewer will certainly not always be the same. cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From william at wbonnet.net Thu Jan 13 01:33:01 2011 From: william at wbonnet.net (William Bonnet) Date: Thu, 13 Jan 2011 01:33:01 +0100 Subject: [csw-maintainers] [website] drop empty pages and placeholders? In-Reply-To: <20110112234025.GG4011@sebastiankayser.de> References: <20110112234025.GG4011@sebastiankayser.de> Message-ID: <4D2E483D.5030000@wbonnet.net> Hi Sebastian > For one, to avoid linking empty content and for two, to reduce the > amount of pages that we have (to maintain). I agree. We have to much pages on the web site. Espacially under "Extend It". Some are almost empty, some are way too much complicated. Many article should be reviewed and reworded. I don't have the time and knowledge (including English knowledge ;) ) to do it well. I would prefer to stick to the technical part of the web site until work in progress is finished (i'd like to put online uwatch2 and qa before Dublin). cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From skayser at opencsw.org Thu Jan 13 01:46:12 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 13 Jan 2011 01:46:12 +0100 Subject: [csw-maintainers] [website] procedure/mechanism for proposed changes? In-Reply-To: <4D2E4785.8030202@wbonnet.net> References: <20110112234520.GH4011@sebastiankayser.de> <4D2E4785.8030202@wbonnet.net> Message-ID: <20110113004612.GJ4011@sebastiankayser.de> Hi William, * William Bonnet wrote: > Thanks for taking time to do some review on the web site :) you're welcome, my pleasure. Good to see there's someone working on the site. > >what's the "official" way to propose changes to pages on our web site? > Actually we don't have one. It has to be defined. > > From a wordpress point of view, articles have different status, > including a draft status. Drafts are not visible on the web site. So i > propose to create draft of articles you would like to modify and get > reviewed. AFAIR wordpress drafts only accessible to people who are logged in? Or is this a setting that can be changed? Also, can a draft version be discarded so that changes which didn't make it don't accidently sneak into future page versions? Questions over questions :) > Now question is who is going to review articles :) > > I think it depends on the content... Reviewer will certainly not always > be the same. Ben and Maciej always served this role well in the past ;) There's two things when it comes to the review audience: 1) wording/language, that's where a native english person with a sense for writing will do and 2) ownership, that's where people who care about and/or maintain the content should get aware of changes and optionaly give their "yep" or "nay" comments. 1) is fairly easy and I already naivly used drafts before. For 2) I am definitly not interested in a complicated control mechanism, just want to ensure transparency and avoid accidently offending someone when changing a page. Sebastian P.S.: Does wordpress have some sort of change notification mechanism? From phil at bolthole.com Thu Jan 13 02:26:21 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 12 Jan 2011 17:26:21 -0800 Subject: [csw-maintainers] [website] Front page update In-Reply-To: <20110112221848.GE4011@sebastiankayser.de> References: <4D2CEF3D.7030900@wbonnet.net> <20110112221848.GE4011@sebastiankayser.de> Message-ID: On Wed, Jan 12, 2011 at 2:18 PM, Sebastian Kayser wrote: > > some initial feedback/thoughts: > > 1) News vs. announcements: I am aware of the motivation for different > ? categories, but honestly think - and I know that I am repeating > ? myself here - that this should be merged in the spirit of simplicity > ? / less confusion (especially given our moderate update frequency). I have the opposite opinion. "news" is trivial. When I go to technical websites, it irritates me when I get my time wasted by "news" that I dont care about, when I'm only interested in catching up on important announcements. If "announcements" are important enough to be designated as such, rather than news.. then they should be kept in a separate area. Otherwise, why bother to have a separate designation of "announcements" in the first place? > ? I could imagine to see this replaced by a section which references > ? externals articles, news items, or even Twitter posts. Section name > ? "External news & articles", "OpenCSW in the press" or similar. That could be interesting. ? Or could we further reduce this list by grouping the communication > ? channels into a single "SUPPORT Get in touch with us" or similar > ? icon which links to http://www.opencsw.org/support/ .. (which in turn > ? could then be structured into short sections "Mailing lists", "Bug > ? Tracker", ...). Just so that we provide a well selected, short list > ? of main navigation entry points on the front page. Another idea that sounds good to me. > 3) Releases and updates: Is this going to be filled with our automated > ? package release feed? Currently it might give the impression that our > ? last released package is from 25th of August. I think the old "weekly updates" section was more useful. The weekly html-window generation is stil going on -- its just not displayed. It could be easily modified to fit any newer desired formatting. From bwalton at opencsw.org Thu Jan 13 04:29:36 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 12 Jan 2011 22:29:36 -0500 Subject: [csw-maintainers] [website] drop empty pages and placeholders? In-Reply-To: <4D2E483D.5030000@wbonnet.net> References: <20110112234025.GG4011@sebastiankayser.de> <4D2E483D.5030000@wbonnet.net> Message-ID: <1294889327-sup-596@pinkfloyd.chass.utoronto.ca> Excerpts from William Bonnet's message of Wed Jan 12 19:33:01 -0500 2011: > article should be reviewed and reworded. I don't have the time and > knowledge (including English knowledge ;) ) to do it well. I'll offer to review any page that someone points out for grammar and wording. I don't have time to scan the site or write new content though. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Thu Jan 13 09:27:05 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 13 Jan 2011 09:27:05 +0100 Subject: [csw-maintainers] [website] procedure/mechanism for proposed changes? In-Reply-To: <20110112234520.GH4011@sebastiankayser.de> (Sebastian Kayser's message of "Thu, 13 Jan 2011 00:45:20 +0100") References: <20110112234520.GH4011@sebastiankayser.de> Message-ID: Sebastian Kayser writes: > what's the "official" way to propose changes to pages on our web site? > I'd like to tackle some content-wise and would appreciate a set of > additional eyes for review purposes. We had a discussion about having versioned control of the content and structure and to have a package for the web site. I know that is more complicated that it sounds. -- Peter From william at wbonnet.net Thu Jan 13 10:04:26 2011 From: william at wbonnet.net (William Bonnet) Date: Thu, 13 Jan 2011 10:04:26 +0100 Subject: [csw-maintainers] [website] procedure/mechanism for proposed changes? In-Reply-To: References: <20110112234520.GH4011@sebastiankayser.de> Message-ID: Hi > We had a discussion about having versioned control of the content and > structure and to have a package for the web site. I know that is more > complicated that it sounds. I will create a wordpress package when done with uwatch2 coding. Creating packages for php software is not that simple since you can expect stuff like wordpress to be installed several times to different places. At least that's what i like to do ;) Articles in Wordpress have a kind of configuration management. Wordpress manage articles history and draft/release status. You can come back in history of an article when you want, you can also have an history to what has been modified, and who did the modification. Finally all php code which is not shipped by wordpress tarball (but the file storing passwords and only password ) is under svn at sf.net Do we need something else ? Actually the missing part is the wordpress package IMHO cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From pfelecan at opencsw.org Thu Jan 13 11:10:03 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 13 Jan 2011 11:10:03 +0100 Subject: [csw-maintainers] [website] procedure/mechanism for proposed changes? In-Reply-To: (William Bonnet's message of "Thu, 13 Jan 2011 10:04:26 +0100") References: <20110112234520.GH4011@sebastiankayser.de> Message-ID: William Bonnet writes: > Hi > >> We had a discussion about having versioned control of the content and >> structure and to have a package for the web site. I know that is more >> complicated that it sounds. > > I will create a wordpress package when done with uwatch2 coding. Creating packages for php software is not that simple since you can expect stuff like wordpress to be installed several times to different places. At least that's what i like to do ;) > > Articles in Wordpress have a kind of configuration management. Wordpress manage articles history and draft/release status. You can come back in history of an article when you want, you can also have an history to what has been modified, and who did the modification. > > Finally all php code which is not shipped by wordpress tarball (but the file storing passwords and only password ) is under svn at sf.net > > Do we need something else ? Actually the missing part is the wordpress package IMHO The content itself? I know that the content can be exported/imported in XML thus "controllable" isn't it? -- Peter From maciej at opencsw.org Thu Jan 13 13:58:50 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 13 Jan 2011 12:58:50 +0000 Subject: [csw-maintainers] [website] procedure/mechanism for proposed changes? In-Reply-To: <20110113004612.GJ4011@sebastiankayser.de> References: <20110112234520.GH4011@sebastiankayser.de> <4D2E4785.8030202@wbonnet.net> <20110113004612.GJ4011@sebastiankayser.de> Message-ID: No dia 13 de Janeiro de 2011 00:46, Sebastian Kayser escreveu: > 1) is fairly easy and I already naivly used drafts before. For 2) I am > definitly not interested in a complicated control mechanism, just want > to ensure transparency and avoid accidently offending someone when > changing a page. I see what you mean. It's basically about asking others before making a change on the live website. We don't have a send patch / review mechanism for the wordpress site. If you want to make a significant change, you could write to the mailing list and describe what you want to do. If no one objects within two or three days, you can assume it's okay to go ahead. There's a worry that there always be someone objecting and anything proposed on the mailing list will result in a deadlock situation. I don't have a good idea how to solve this without frequent voting. From maciej at opencsw.org Thu Jan 13 15:08:25 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 13 Jan 2011 14:08:25 +0000 Subject: [csw-maintainers] Wintercamp 2010/2011? In-Reply-To: <4D2B84E7.1060704@opencsw.org> References: <20101207162737.GB30288@sebastiankayser.de> <23E107A9-D5DE-44EB-A7FE-B54E8AFDA937@opencsw.org> <20101207211455.GE30288@sebastiankayser.de> <1EA6BB8D-C7B6-4C7B-A4E1-7D4CFA5036EF@opencsw.org> <20101223122148.GC4011@sebastiankayser.de> <4D238337.8040604@opencsw.org> <4D2B84E7.1060704@opencsw.org> Message-ID: No dia 10 de Janeiro de 2011 22:15, Sebastian Kayser escreveu: > ?hsan Do?an wrote on 04.01.2011 21:29: >> Am 23.12.2010 13:38, schrieb Maciej (Matchek) Blizinski: >> >>>> Any further would-like-to-attendees please submit your availability on >>>> the Doodle poll. Current poll status suggests the weekend of 19/20th >>>> February. Are the dates still good for all those who voted (in >>>> particular for you, Maciej, as our host)? If not, please update your >>>> availability. >>> >>> Yes, these dates are good. >> >> Also fine for me. >> >> So, is it then Luxembourg? > > Dublin for winter camp, Luxembourg for summer camp. At least that's what > I scratched together from my grey matter and the archives. [1] > > All settled? /me eager to book the flights. The closest hotel is this: http://www.grandcanalhotel.ie/ I haven't researched prices. If anybody researched prices and found another nearby hotel for a good place, please let us know! From maciej at opencsw.org Thu Jan 13 18:25:36 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 13 Jan 2011 17:25:36 +0000 Subject: [csw-maintainers] Wintercamp 2010/2011 in Dublin Message-ID: Hello fellow maintainers! I'd like to announce the Wintercamp 2010/2011! This year, the Wintercamp will be held in Dublin, the European capital of cheap flights. The date is the weekend of 19th of February 2011. I've started a wiki page with information about the Wintercamp, containing accommodation details. The page is just a sketch, please don't hesitate to modify it. For example, should we also schedule a breakfast at the hotel? The Wintercamp will start on Friday, with a hacking session in a suite with conferencing space for 10 people, free wifi and a bar. What more could we ask for? The core part begins Saturday morning and continues until Sunday noon. More information on the wiki page. http://wiki.opencsw.org/wintercamp-2010 If you plan to attend, please add your name to the wiki page, or send me an e-mail, so I can add your name there. I'm really excited about meeting you guys! Looking forward to see you in person, Maciej From william at wbonnet.net Thu Jan 13 21:36:25 2011 From: william at wbonnet.net (William Bonnet) Date: Thu, 13 Jan 2011 21:36:25 +0100 Subject: [csw-maintainers] [website] procedure/mechanism for proposed changes? In-Reply-To: References: <20110112234520.GH4011@sebastiankayser.de> Message-ID: <4D2F6249.4020200@wbonnet.net> Hi > The content itself? I know that the content can be exported/imported in > XML thus "controllable" isn't it? Content itself is stored in a mysql database and is versioned by wordpress. We export it to almost whatever format we want. There exists lots of plugins, and internal format is documented. cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From william at wbonnet.net Thu Jan 13 21:42:51 2011 From: william at wbonnet.net (William Bonnet) Date: Thu, 13 Jan 2011 21:42:51 +0100 Subject: [csw-maintainers] [website] Front page update In-Reply-To: References: <4D2CEF3D.7030900@wbonnet.net> <20110112221848.GE4011@sebastiankayser.de> Message-ID: <4D2F63CB.7000207@wbonnet.net> Hi > If "announcements" are important enough to be designated as such, > rather than news.. then they should be kept in a separate area. > Otherwise, why bother to have a separate designation of > "announcements" in the first place? I do agree with this. I prefer to separate informations regarding to the nature and importance. That's about structure. But Sebastian is right that current data are outdated. I'll try to add a few posts when mirrors will be sync. Later there wil be an automatic feed for this. I have to do some cleanup in feeds... actually this is why you have both an entry in the top menu bar and an icon on the right. They link to the same thing, i can't suppress on without modifying the other. It's not complicated, but i have to change some code in the next days. I have created a page with only one set of news, whatever you call it. It does not look so well, and it does not really look like a front page. > That could be interesting. Tweets are easy to add. Once coded it's automatic. Press releases will have to be done by hand. Hopefully there is not a dozen a such news in a month ;) > 3) Releases and updates: Is this going to be filled with our automated YesI think the old "weekly updates" section was more useful. > The weekly html-window generation is stil going on -- its just not > displayed. It could be easily modified to fit any newer desired > formatting. It will replace soon updates or will be merged with updates. Some php code to write cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From ja at opencsw.org Thu Jan 13 22:02:01 2011 From: ja at opencsw.org (Juergen Arndt) Date: Thu, 13 Jan 2011 22:02:01 +0100 Subject: [csw-maintainers] Munin 1.4.5 in experimental (with support for the new rrdtool packages) In-Reply-To: References: Message-ID: Hi all, I've put new munin packages into experimental. They have dependencies to Dago's rebuilded packages of rrdtool. Feedback is welcome. Regards, Juergen -- Juergen Arndt From phil at bolthole.com Thu Jan 13 22:02:20 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 13 Jan 2011 13:02:20 -0800 Subject: [csw-maintainers] [website] Front page update In-Reply-To: <4D2F63CB.7000207@wbonnet.net> References: <4D2CEF3D.7030900@wbonnet.net> <20110112221848.GE4011@sebastiankayser.de> <4D2F63CB.7000207@wbonnet.net> Message-ID: On Thursday, January 13, 2011, William Bonnet wrote: > .... > 3) Releases and updates: Is this going to be filled with our automated > > YesI think the old "weekly updates" section was more useful. > > The weekly html-window generation is stil going on -- its just not > displayed. It could be easily modified to fit any newer desired > formatting. > > It will replace soon updates or will be merged with updates. Some php code to write > reminder: you don't want to dynamically generate this info every time. I already generate it for the email, so you could tell me where you'd like a copy and in what format From william at wbonnet.net Thu Jan 13 22:15:32 2011 From: william at wbonnet.net (William Bonnet) Date: Thu, 13 Jan 2011 22:15:32 +0100 Subject: [csw-maintainers] [website] Front page update In-Reply-To: References: <4D2CEF3D.7030900@wbonnet.net> <20110112221848.GE4011@sebastiankayser.de> <4D2F63CB.7000207@wbonnet.net> Message-ID: <4D2F6B74.6080202@wbonnet.net> Hi > > reminder: you don't want to dynamically generate this info every time. > I already generate it for the email, so you could tell me where you'd > like a copy and in what format Informations are already stored in the website database. They are used to generate graphics like this http://www.opencsw.org/get-it/package-statistics/ cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From bwalton at opencsw.org Fri Jan 14 03:17:25 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 13 Jan 2011 21:17:25 -0500 Subject: [csw-maintainers] [website] Front page update In-Reply-To: <4D2F63CB.7000207@wbonnet.net> References: <4D2CEF3D.7030900@wbonnet.net> <20110112221848.GE4011@sebastiankayser.de> <4D2F63CB.7000207@wbonnet.net> Message-ID: <1294971173-sup-6856@pinkfloyd.chass.utoronto.ca> Excerpts from William Bonnet's message of Thu Jan 13 15:42:51 -0500 2011: > I do agree with this. I prefer to separate informations regarding to > the nature and importance. That's about structure. But Sebastian is > right that current data are outdated. I'll try to add a few posts > when mirrors will be sync. Later there wil be an automatic feed for > this. Do we have a clear distinction to determine which place an item would go though? If it's posted to announce@ it can go in announements, otherwise news? I'm on the fence about which I prefer. A clean homepage is nice, thus I'd be inclined to at least move news to a non-frontpage location. On the other hand, we don't normally have enough news items to warrant a whole page for it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Jan 14 03:50:17 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 13 Jan 2011 21:50:17 -0500 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> <1294668925-sup-4890@pinkfloyd.chas s.utoronto.ca> Message-ID: <1294973391-sup-5061@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Mon Jan 10 14:56:23 -0500 2011: > Which makes quite clear which is the optimal choice for "*users*". Agreed. Phil, are you releasing this package to remove the cups blockade? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Jan 14 04:29:41 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 13 Jan 2011 22:29:41 -0500 Subject: [csw-maintainers] [website] procedure/mechanism for proposed changes? In-Reply-To: References: <20110112234520.GH4011@sebastiankayser.de> Message-ID: <1294975543-sup-7516@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Thu Jan 13 05:10:03 -0500 2011: Hi Peter, > The content itself? I know that the content can be exported/imported > in XML thus "controllable" isn't it? Are you envisioning a system whereby a push to the repository triggers a publishing action to the live site? We do this at work for one of our primary sites and it works well. We're able to lint the content ahead of time and apply whatever 'policy' to it we want. It's the updated to the production servers and mail notice is sent to anyone with commit rights. I'd be in favour of such a system for the opencsw website provided it doesn't add more complexity than it's worth. We already have collaborative maintenance of the site and internal wordpress content versioning...Has anyone done this with wordpress already? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From william at wbonnet.net Fri Jan 14 08:13:18 2011 From: william at wbonnet.net (William Bonnet) Date: Fri, 14 Jan 2011 08:13:18 +0100 Subject: [csw-maintainers] [website] procedure/mechanism for proposed changes? In-Reply-To: <1294975543-sup-7516@pinkfloyd.chass.utoronto.ca> References: <20110112234520.GH4011@sebastiankayser.de> <1294975543-sup-7516@pinkfloyd.chass.utoronto.ca> Message-ID: <4D2FF78E.7040401@wbonnet.net> Hi > Are you envisioning a system whereby a push to the repository triggers > a publishing action to the live site? Yes, that's almost already implemented with feeds and recent updates. I'm just not sure it works very well on the "website side", it has to go through some more testing / debug cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From wbonnet at on-x.com Tue Jan 11 17:00:30 2011 From: wbonnet at on-x.com (William Bonnet) Date: Tue, 11 Jan 2011 17:00:30 +0100 Subject: [csw-maintainers] An idea: OpenCSW on FLOSS Weekly In-Reply-To: References: Message-ID: <4D2C7E9E.2080402@on-x.com> Hi > >>> - the size of the developer community >>> - how to get involved / where to find us >>> - good to give some metrics such as numbers of updated packages per month / >>> year >> could just check the weekly package announces for that, if they are >> archived somewhers. I think they are. > Does anyone have that data at hand? William? You can get the statistics in graphic mode at the following URL : http://www.opencsw.org/get-it/package-statistics/ The raw data are stored in the spmtcsw database table pkg_stats_statistics. Here the data since opencsw creation (no track of blastwave era) +---------+-----------+------------+--------------------+---------------------+-------------------+ | ID_STAT | STAT_YEAR | STAT_MONTH | STAT_PACKAGE_COUNT | STAT_CREATION_COUNT | STAT_UPDATE_COUNT | +---------+-----------+------------+--------------------+---------------------+-------------------+ | 1 | 2008 | 5 | 1803 | 1803 | 0 | | 2 | 2008 | 10 | 1806 | 3 | 0 | | 3 | 2008 | 12 | 1835 | 29 | 24 | | 8 | 2009 | 1 | 1857 | 22 | 51 | | 9 | 2009 | 2 | 1871 | 14 | 209 | | 10 | 2009 | 3 | 1927 | 56 | 241 | | 11 | 2009 | 4 | 1945 | 18 | 183 | | 12 | 2009 | 5 | 1980 | 35 | 149 | | 13 | 2009 | 6 | 2036 | 56 | 123 | | 14 | 2009 | 7 | 2047 | 11 | 44 | | 15 | 2009 | 8 | 2081 | 34 | 248 | | 16 | 2009 | 9 | 2102 | 21 | 203 | | 17 | 2009 | 10 | 2151 | 49 | 96 | | 18 | 2009 | 11 | 2193 | 42 | 126 | | 19 | 2009 | 12 | 2212 | 19 | 329 | | 20 | 2010 | 1 | 2254 | 42 | 97 | | 21 | 2010 | 2 | 2386 | 132 | 148 | | 22 | 2010 | 3 | 2487 | 101 | 249 | | 23 | 2010 | 4 | 2531 | 44 | 133 | | 24 | 2010 | 5 | 2502 | 12 | 58 | | 25 | 2010 | 6 | 2559 | 69 | 106 | | 26 | 2010 | 7 | 2575 | 16 | 77 | | 27 | 2010 | 8 | 2588 | 13 | 54 | | 28 | 2010 | 9 | 2594 | 6 | 112 | | 29 | 2010 | 10 | 2626 | 32 | 63 | | 30 | 2010 | 11 | 2662 | 36 | 47 | | 31 | 2010 | 12 | 2700 | 38 | 95 | | 32 | 2011 | 1 | 2724 | 24 | 24 | +---------+-----------+------------+--------------------+---------------------+-------------------+ -- William BONNET CTO ON-X Technologies tel: 01 40 99 29 03 / 06 89 37 69 77 mailto:wbonnet at on-x.com http://www.on-x.com From dam at opencsw.org Fri Jan 14 12:48:58 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 14 Jan 2011 12:48:58 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] Mirror push needed In-Reply-To: References: <34ED0509-96A0-4C2A-BCF0-51CE4093332C@opencsw.org> Message-ID: Hi Phil, Am 12.01.2011 um 18:41 schrieb Philip Brown: > On 1/12/11, Dagobert Michelsen wrote: >> Am 11.01.2011 um 22:20 schrieb Philip Brown: >>> Drat. push aborted, problem with catalog. >>> Bug Dago to update: >>> >>> ERROR! Dependency CSWlibicu42 of package CSWlibicu is missing. >>> >>> should be 46, not 42, I believe. >> >> No, that is the legacy .co where libicu is depending on to keep >> legacy applications happy. > > oh right, whoops. > thanks for the recopy. Ping? I need the updated libicu to release a new version xerces-c required by other packages. Best regards -- Dago From bwalton at opencsw.org Fri Jan 14 14:06:30 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 14 Jan 2011 08:06:30 -0500 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: <1294973391-sup-5061@pinkfloyd.chass.utoronto.ca> References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> <1294668925-sup-4890@pinkfloyd.chas s.utoronto.ca> <1294973391-sup-5061@pinkfloyd.chass.utoronto.ca> Message-ID: <1295010351-sup-948@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Thu Jan 13 21:50:17 -0500 2011: > Excerpts from Peter FELECAN's message of Mon Jan 10 14:56:23 -0500 2011: > > > Which makes quite clear which is the optimal choice for "*users*". > > Agreed. Phil, are you releasing this package to remove the cups > blockade? I should rephrase this. I realize that cups isn't "blockaded" but the ability to deliver a consistently clean user experience for a cups installation is. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Jan 14 14:21:24 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 14 Jan 2011 08:21:24 -0500 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> Message-ID: <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sat Jan 08 16:54:57 -0500 2011: > The vote is open from the 9th - 13th inclusive. As with the board > vote, I have no indication of time zone handling for this, so I made > it a 4 day window that includes weekend and weekday times. The results are in: Files and directories are allowed to be delivered to /var/opt/csw directly by the prototype of a package. => 8 votes (57%) Directories may be delivered to /var/opt/csw by the prototype of a package, but files may not. => 4 votes (28%) Neither files nor directories may be delivered to /var/opt/csw by the prototype of a package. => 2 votes (14%) Phil: please adjust your scripts to allow packages delivering directories and/or files via the prototype to be allowed through. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Fri Jan 14 14:30:09 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 14 Jan 2011 14:30:09 +0100 Subject: [csw-maintainers] Unifying cvs and cvs_feature? Message-ID: <1119428C-2FE1-462B-8F30-9D2A60A2D6F2@opencsw.org> Hi, at the moment we have two CVS packages: cvs 1.11.23 in /opt/csw cvs_feature 1.12.13 in /opt/csw/cvs_feature I did a brief search on the web if there is a compelling reason to ship those two different version but have found no real indication. As I am no hardcode user I would like to ask if anyone has a strong opinion on keeping these two separate. I have already respun cvs packages at http://buildfarm.opencsw.org/experimental.html#cvs where cvs will be updated to 1.12.13 and /opt/csw/cvs_feature is a link to "." making sure 3rd party scripts depending on CSWcvs-feature won't break. Best regards -- Dago From pfelecan at opencsw.org Fri Jan 14 15:06:15 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 14 Jan 2011 15:06:15 +0100 Subject: [csw-maintainers] Unifying cvs and cvs_feature? In-Reply-To: <1119428C-2FE1-462B-8F30-9D2A60A2D6F2@opencsw.org> (Dagobert Michelsen's message of "Fri, 14 Jan 2011 14:30:09 +0100") References: <1119428C-2FE1-462B-8F30-9D2A60A2D6F2@opencsw.org> Message-ID: Dagobert Michelsen writes: > I would like to ask if anyone has a strong opinion on keeping these > two separate. On the contrary: unify them. -- Peter From phil at bolthole.com Fri Jan 14 18:51:58 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 14 Jan 2011 09:51:58 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/14/11, Ben Walton wrote: > Excerpts from Ben Walton's message of Sat Jan 08 16:54:57 -0500 2011: > >> The vote is open from the 9th - 13th inclusive. As with the board >> vote, I have no indication of time zone handling for this, so I made >> it a 4 day window that includes weekend and weekday times. > > The results are in: > > Files and directories are allowed to be delivered to /var/opt/csw > directly by the prototype of a package. => 8 votes (57%) > > Directories may be delivered to /var/opt/csw by the prototype of a > package, but files may not. => 4 votes (28%) > > Neither files nor directories may be delivered to /var/opt/csw by the > prototype of a package. => 2 votes (14%) > > Phil: please adjust your scripts to allow packages delivering > directories and/or files via the prototype to be allowed through. I will for now. However, I have a complaint. As I mentioned previously, your voting writeup unfairly biased the vote. Because you sent a global vote invite to all active maintainers, but you included NOTHING about potential reasons why people might consider each option. This leaves people who have not read this thread, yet are *still voting*, in essentially the following situation: "Please vote for one of the following: a) Put files whereever you please b) Disallow files in this location, for no particular reason at all" The choice in that situation is obviously always going to be 'a'. From phil at bolthole.com Fri Jan 14 19:01:42 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 14 Jan 2011 10:01:42 -0800 Subject: [csw-maintainers] [csw-pkgsubmissions] Mirror push needed In-Reply-To: References: <34ED0509-96A0-4C2A-BCF0-51CE4093332C@opencsw.org> Message-ID: On 1/14/11, Dagobert Michelsen wrote: > > Ping? I need the updated libicu to release a new version xerces-c > required by other packages. > Hm.. sorry, the batched push quit early for some reason. Normally, things would get refreshed with the newpkgs today, but I'll run the push now, as opposed to later. From phil at bolthole.com Fri Jan 14 19:07:35 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 14 Jan 2011 10:07:35 -0800 Subject: [csw-maintainers] [website] Front page update In-Reply-To: <1294971173-sup-6856@pinkfloyd.chass.utoronto.ca> References: <4D2CEF3D.7030900@wbonnet.net> <20110112221848.GE4011@sebastiankayser.de> <4D2F63CB.7000207@wbonnet.net> <1294971173-sup-6856@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/13/11, Ben Walton wrote: > > I'm on the fence about which I prefer. A clean homepage is nice, thus > I'd be inclined to at least move news to a non-frontpage location. On > the other hand, we don't normally have enough news items to warrant a > whole page for it. > we have an "about us" page or something, though From phil at bolthole.com Fri Jan 14 19:14:36 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 14 Jan 2011 10:14:36 -0800 Subject: [csw-maintainers] Unifying cvs and cvs_feature? In-Reply-To: <1119428C-2FE1-462B-8F30-9D2A60A2D6F2@opencsw.org> References: <1119428C-2FE1-462B-8F30-9D2A60A2D6F2@opencsw.org> Message-ID: On 1/14/11, Dagobert Michelsen wrote: > Hi, > > at the moment we have two CVS packages: > > cvs 1.11.23 in /opt/csw > cvs_feature 1.12.13 in /opt/csw/cvs_feature > > I did a brief search on the web if there is a compelling reason to > ship those two different version but have found no real indication. > As I am no hardcode user I would like to ask if anyone has a strong > opinion on keeping these two separate. I have already respun cvs > packages at > http://buildfarm.opencsw.org/experimental.html#cvs > where cvs will be updated to 1.12.13 and /opt/csw/cvs_feature is > a link to "." making sure 3rd party scripts depending on > CSWcvs-feature won't break. > > ermm.. would you post more details on how you plan to unify them please? I for one, dont understand the ramifications of what you wrote above. what is the significance of the symlink? And what if any, is "lost"? one would presume that "cvs_feature".. has more features. Is this no longer true? You said no "compelling" reason. but you dont say they are identical, either. From phil at bolthole.com Fri Jan 14 21:47:49 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 14 Jan 2011 12:47:49 -0800 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: <1294615492-sup-8652@pinkfloyd.chass.utoronto.ca> References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> <1294615492-sup-8652@pinkfloyd.chass.utoronto.ca> Message-ID: Sorry, this thread got buried in my mailbox. Dredging out a "draft" reply I was previously working on... On Sun, Jan 9, 2011 at 3:41 PM, Ben Walton wrote: > >...[I noted your later reply, this is from original...] > ?I think that ultimately, depending on the SUNW > package is the nicest solution, but it's been shown that this is not a > stable choice for the long term as names can and have changed. Some things, yes. I think in this *specific* case, there is a very low risk of this though. > Depending on our own libslp package gives all of these benefits. ?The > downside is that there are now two libslp's on the system. ?Someone > please correct me if I'm wrong here, but the slp provided by SUNWslpu > is the Sun implementation of this protocol, correct? ?The package > Maciej has provided is of OpenSLP. ?This means that it's only > providing slp functionality, not the same library. ?(There very well > might still be a naming if the parent paths are ignored...) ah, interesting point. But same SONAME, right?(yup, confirmed same) That is potentially a problem. > Interestingly, this issue has been around for a _long_ time now: > http://osdir.com/ml/solaris.blastwave.user/2004-09/msg00010.html interesting indeed. What is of additional interest, is that the user did not reply with, "hey why dont you guys just provide slp yourselves?" It's rather sad that we've never declared the slp dependency wen we've needed it this long though :( > In my opinion, making the admin dig up a package file from a > potentially inconvenient location (and only after they've found a > non-working cups) is worse than simply delivering the functionality > ourselves. And I have a different opinion on it. So what makes one opinion better or worse than another? Neither is particularly based on "this is technically better", but really, personal preference. >3. Some of the toolchain needs modification to handle this nicely. Why? We already do it. I havent heard big complaints about how we need to modify the toolchain on what we already do: we already have SUNW depends. Reguarding Maciej's http://buildfarm.opencsw.org/~maciej/slp-discuss/ yes, that is a very nicely laid out page.. preselected with all the reasons that favor CSWopenslp, and none that go against it. Bias in "voting" presentation again, one might say. Two of the non-favourable ones being: 1. Same SONAME brings up potential for bad conflicts 2. Some users will be very against this needless duplication. "interestingly", the chart obliquely mentions we are "Shipping functionality already available in one of Solaris packages", but does not indicate in any way that this can be considered a BAD thing for an openslp package. The existing column format doesnt mesh well with that row. From phil at bolthole.com Fri Jan 14 21:53:37 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 14 Jan 2011 12:53:37 -0800 Subject: [csw-maintainers] Dependencies on SUNW packages (was: newpkgs libslp1, openslp_devel) In-Reply-To: References: <1292951698-sup-9981@pinkfloyd.chass.utoronto.ca> <1293145971-sup-4029@pinkfloyd.chass.utoronto.ca> <1293151231-sup-8062@pinkfloyd.chass.utoronto.ca> <1293196250-sup-5345@pinkfloyd.chass.utoronto.ca> <1294588350-sup-2392@pinkfloyd.chass.utoronto.ca> <1294615492-sup-8652@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/14/11, Philip Brown wrote: > ... > "interestingly", the chart obliquely mentions we are "Shipping > functionality already available in one of Solaris packages", but does > not indicate in any way that this can be considered a BAD thing for an > openslp package. Oops. correction, yes it does. sorry about that. Just not in a way that underscores why this is "bad". From pfelecan at opencsw.org Sat Jan 15 12:24:39 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 15 Jan 2011 12:24:39 +0100 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: (Philip Brown's message of "Fri, 14 Jan 2011 09:51:58 -0800") References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On 1/14/11, Ben Walton wrote: >> Excerpts from Ben Walton's message of Sat Jan 08 16:54:57 -0500 2011: >> >>> The vote is open from the 9th - 13th inclusive. As with the board >>> vote, I have no indication of time zone handling for this, so I made >>> it a 4 day window that includes weekend and weekday times. >> >> The results are in: >> >> Files and directories are allowed to be delivered to /var/opt/csw >> directly by the prototype of a package. => 8 votes (57%) >> >> Directories may be delivered to /var/opt/csw by the prototype of a >> package, but files may not. => 4 votes (28%) >> >> Neither files nor directories may be delivered to /var/opt/csw by the >> prototype of a package. => 2 votes (14%) >> >> Phil: please adjust your scripts to allow packages delivering >> directories and/or files via the prototype to be allowed through. > > > I will for now. However, I have a complaint. As I mentioned > previously, your voting writeup unfairly biased the vote. > Because you sent a global vote invite to all active maintainers, but > you included NOTHING about potential reasons why people might consider > each option. > This leaves people who have not read this thread, yet are *still > voting*, in essentially the following situation: There is no way to verify this assumption. I'd say: trust the voters to have done their due diligence and read the maintainers list. The chance that somebody votes "blindly" is idempotent for those reading or not. -- Peter From bwalton at opencsw.org Sat Jan 15 15:34:52 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 15 Jan 2011 09:34:52 -0500 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> Message-ID: <1295101813-sup-4451@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Jan 14 12:51:58 -0500 2011: Hi Phil, > This leaves people who have not read this thread, yet are *still > voting*, in essentially the following situation: If it were this simple to cure voter ignorance, Canada would not have it's current leadership. :) (Well, maybe we would, but it would hopefully be for different reasons...) Of the respondents, I recognize all but one as a regular contributor to the discussions we have here. I will in the future improve this to reference a mail thread, but for this specific vote, given the voter set, I think the result is fair. I will also ensure that both sides of an issue have time to review questions before future votes. That was an oversight on my part. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sat Jan 15 23:40:38 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 15 Jan 2011 14:40:38 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <1295101813-sup-4451@pinkfloyd.chass.utoronto.ca> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <1295101813-sup-4451@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jan 15, 2011 at 6:34 AM, Ben Walton wrote: > ... > > Of the respondents, I recognize all but one as a regular contributor > to the discussions we have here. that does not neccessarily mean they are informed about the *specific* issue. You can only know that if they contributed to the specific thread. I myself do not follow all threads on the maintainer list. Once I determine I'm not interested in a particular subject, I tend to delete the rest of that thread without reading it. I think that there were 14 people who voted, but only 5 (maybe 6?) actually contributed to the relevant thread. From phil at bolthole.com Sun Jan 16 00:09:20 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 15 Jan 2011 15:09:20 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jan 15, 2011 at 3:24 AM, Peter FELECAN wrote: > ... >> This leaves people who have not read this thread, yet are *still >> voting*, in essentially the following situation: > > There is no way to verify this assumption. It's certainly not true that there is "no way" to do so. It would be true that there is no way to verify if all we do is look at the data we have right now. This could have been "verified" beforehand, by posting the "vote now" bit only in the mail thread. then you have just ensured that only people who have read through the thread, will know to vote. But that goes rather against the principle that every maintainer has the right to vote on this sort of thing. So its important to have a proper summary, in the vote itself. Just giving a link to a potentially extremely lengthy "discussion thread" is not adequate. EVERY "real world" vote does this!! From pfelecan at opencsw.org Sun Jan 16 12:50:16 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 16 Jan 2011 12:50:16 +0100 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: (Philip Brown's message of "Sat, 15 Jan 2011 15:09:20 -0800") References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Sat, Jan 15, 2011 at 3:24 AM, Peter FELECAN wrote: >> ... >>> This leaves people who have not read this thread, yet are *still >>> voting*, in essentially the following situation: >> >> There is no way to verify this assumption. > > It's certainly not true that there is "no way" to do so. > It would be true that there is no way to verify if all we do is look > at the data we have right now. > > This could have been "verified" beforehand, by posting the "vote now" > bit only in the mail thread. then you have just ensured that only > people who have read through the thread, will know to vote. > But that goes rather against the principle that every maintainer has > the right to vote on this sort of thing. So its important to have a > proper summary, in the vote itself. Just giving a link to a > potentially extremely lengthy "discussion thread" is not adequate. > > EVERY "real world" vote does this!! What astonish me is that you're almost never satisfied. For example, the "lengthy thread" conveys all the information for all willing to have their due diligence. So what is your real complaint? -- Peter From pfelecan at opencsw.org Sun Jan 16 12:54:59 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 16 Jan 2011 12:54:59 +0100 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: (Philip Brown's message of "Sat, 15 Jan 2011 14:40:38 -0800") References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <1295101813-sup-4451@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Sat, Jan 15, 2011 at 6:34 AM, Ben Walton wrote: >> ... >> >> Of the respondents, I recognize all but one as a regular contributor >> to the discussions we have here. > > that does not neccessarily mean they are informed about the *specific* > issue. You can only know that if they contributed to the specific > thread. You doubt that people can read and make up their own mind? > I myself do not follow all threads on the maintainer list. Once I > determine I'm not interested in a particular subject, I tend to delete > the rest of that thread without reading it. This is your choice and whoever does that can later use the archives to have the information when there is a vote. > > I think that there were 14 people who voted, but only 5 (maybe 6?) > actually contributed to the relevant thread. Again, you doubt the intelligence of those who voted. Anyway, this is my last comment on this thread as vox populi was expressed. -- Peter From rupert at opencsw.org Sun Jan 16 13:03:32 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 16 Jan 2011 13:03:32 +0100 Subject: [csw-maintainers] ghc on buildserver? Message-ID: hi, do we have any ghc release which could be installed on the buildserver? i see a package in subversion, but it seems not have been released? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trygvis at opencsw.org Sun Jan 16 15:01:11 2011 From: trygvis at opencsw.org (=?UTF-8?B?VHJ5Z3ZlIExhdWdzdMO4bA==?=) Date: Sun, 16 Jan 2011 15:01:11 +0100 Subject: [csw-maintainers] ghc on buildserver? In-Reply-To: References: Message-ID: <4D32FA27.4030000@opencsw.org> On 01/16/2011 01:03 PM, rupert THURNER wrote: > hi, > > do we have any ghc release which could be installed on the buildserver? > i see a package in subversion, but it seems not have been released? I tried to build it but it is a bit of pain to build with it's multi-staged build setup. However it might be much easier now after one of the GHC guys got a t2000 box from sun a while back to improve the Solaris support for GHC. Feel free to take over GHC, I can help testing it with my Haskell software. -- Trygve From william at wbonnet.net Mon Jan 17 08:17:04 2011 From: william at wbonnet.net (William Bonnet) Date: Mon, 17 Jan 2011 08:17:04 +0100 Subject: [csw-maintainers] Duplicate packages in GAR Message-ID: <4D33ECF0.5010200@wbonnet.net> Hi This is one of the first result of uwatch2 testing on full GAR repository. The very first run detected 1315 distinct package having a build description. This number is a below the real number since some package do not have a valid UWATCH configuration or are still using GAR v1. This means a large number of packages from current are certainly available, it also means there are many packages in GAR which are not pushed yet to the catalog. Lists and web pages will follow soon now the database is populated. BTW we will have to discuss together what should be on the pages :) As stated by this email subject, I have detected several duplicated packages stored under different GAR svn path. Good news is that there is only 7 packages out of more than 1315 having a build description. Here is the list : PKG_CATALOGNAME PKG_NAME PKG_GAR_PATH evolution_webcal CSWevolutionexchange pkg/evolution-exchange/trunk evolution_webcal CSWevolutionwebcal pkg/evolution-webcal/trunk evolution_webcal_devel CSWevolutionwebcal-devel pkg/evolution-webcal/trunk evolution_webcal_devel CSWevolutionexchange-devel pkg/evolution-exchange/trunk evolution_webcal_doc CSWevolutionwebcal-doc pkg/evolution-webcal/trunk evolution_webcal_doc CSWevolutionexchange-doc pkg/evolution-exchange/trunk libsoup2 CSWlibsoup2 pkg/libsoup/trunk libsoup2 CSWlibsoup2 pkg/libsoup2/trunk pm_cryptcbc CSWpmcryptcbc pkg/cpan/Crypt-CBC/trunk pm_cryptcbc CSWpmcryptcbc pkg/cpan/Crypt-Random/trunk pm_unixsyslog CSWpmunixsyslog pkg/cpan/Unix-Syslog/trunk pm_unixsyslog CSWpmunixsyslog pkg/cpan/Syslog/trunk pm_xmllibxmlcom CSWpmxmllibxmlcom pkg/cpan/XML-LibXML/trunk pm_xmllibxmlcom CSWpmxmllibxmlcom pkg/cpan/XML-LibXML-Common/trunk Here is the list of the owners : evolution_webcal -> Ken Mays (Retired) evolution_webcal_devel -> Not released evolution_webcal_doc -> Not released libsoup2 -> Roger Hakansson pm_cryptcbc -> Dagobert Michelsen pm_unixsyslog -> Benny vonMossner pm_xmllibxmlcom -> Benny vonMossner I would like to kinow what is our policy regarding duplicated packages in GAR ? Should we allow this or not ? It would be much safer to have a single build description for a given package. Of course it is not possible to prevent from this at SVN level. But i can modify newpkgs-% target so it generates a warning if the package already exist in uwatch db, and cron a database test to send warning emails. cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at opencsw.org Mon Jan 17 12:02:13 2011 From: james at opencsw.org (James Lee) Date: Mon, 17 Jan 2011 11:02:13 GMT Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> Message-ID: <20110117.11021300.3105295734@gyor.oxdrove.co.uk> On 14/01/11, 13:21:24, Ben Walton wrote regarding Re: [csw-maintainers] [policy] files/dirs in /var/opt/csw: > The results are in: > Files and directories are allowed to be delivered to /var/opt/csw > directly by the prototype of a package. => 8 votes (57%) > Directories may be delivered to /var/opt/csw by the prototype of a > package, but files may not. => 4 votes (28%) > Neither files nor directories may be delivered to /var/opt/csw by the > prototype of a package. => 2 votes (14%) > Phil: please adjust your scripts to allow packages delivering > directories and/or files via the prototype to be allowed through. Also please can someone remove the references to supporting NFS share of /opt/csw (as we now don't), that is eg: http://www.opencsw.org/about/core-principles/ http://www.opencsw.org/use-it/sharing-optcsw/ http://www.opencsw.org/about/faq/ and probably some others. Further it would be good to add an additional note and make an announcement to explain the change in policy. James. From dam at opencsw.org Mon Jan 17 13:02:55 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 17 Jan 2011 13:02:55 +0100 Subject: [csw-maintainers] Unifying cvs and cvs_feature? In-Reply-To: References: <1119428C-2FE1-462B-8F30-9D2A60A2D6F2@opencsw.org> Message-ID: <0EDB236A-E3CD-48BC-8504-C160973C4269@opencsw.org> Hi Phil, Am 14.01.2011 um 19:14 schrieb Philip Brown: > On 1/14/11, Dagobert Michelsen wrote: >> Hi, >> >> at the moment we have two CVS packages: >> >> cvs 1.11.23 in /opt/csw >> cvs_feature 1.12.13 in /opt/csw/cvs_feature >> >> I did a brief search on the web if there is a compelling reason to >> ship those two different version but have found no real indication. >> As I am no hardcode user I would like to ask if anyone has a strong >> opinion on keeping these two separate. I have already respun cvs >> packages at >> http://buildfarm.opencsw.org/experimental.html#cvs >> where cvs will be updated to 1.12.13 and /opt/csw/cvs_feature is >> a link to "." making sure 3rd party scripts depending on >> CSWcvs-feature won't break. > > ermm.. would you post more details on how you plan to unify them please? Sure. > I for one, dont understand the ramifications of what you wrote above. Me neither, that's why I am asking. > what is the significance of the symlink? "cvs" is in /opt/csw, "cvs feature" is in /opt/csw/cvs-feature/. Unifying both in /opt/csw makes /opt/csw/cvs-feature obsolete and hence makes that one a link so /opt/csw/cvs-feature/bin/cvs will be /opt/csw/(cvs-features -> .)/bin/cvs > And what if any, is "lost"? "stable" would be no longer available. > one would presume that "cvs_feature".. has more features. Is this no > longer true? > You said no "compelling" reason. but you dont say they are identical, either. Yes. From the release notes of "feature": > Feature CVS 1.12.13 has been released. Feature releases contain new features as well as all the bug fixes from the stable releases. This version fixes two security vulnerabilities in the zlib compression libraries (see CERT vulnerabilities advisories #238678 & #680620 for more info), several issues involving potential data-loss on heavily loaded systems, some minor potential crashes, hangs, and several minor annoyances in CVS client and server behavior. > > This release also adds a handful of new features, mostly providing expanded server configurability, but including repair of a major Windows client issue that has prevented the Windows client from accessing remote repositories for several feature releases and fixes for some minor cvs watch bugs. > > We recommend this upgrade for all CVS clients and servers already running the feature release and for those who simply like to stay on the cutting edge! It sounds to me that "cvs stable" is long outdated and of no practical use as all fixes go to "feature". Best regards -- Dago From dam at opencsw.org Mon Jan 17 13:06:19 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 17 Jan 2011 13:06:19 +0100 Subject: [csw-maintainers] libgmp In-Reply-To: References: <1271818780-sup-689@pinkfloyd.chass.utoronto.ca> <6AECC136-9E5F-4BE9-94D8-1CC321008EDF@opencsw.org> <1271945947-sup-8196@pinkfloyd.chass.utoronto.ca> Message-ID: <2BFC84F2-6845-4C92-857C-521387726225@opencsw.org> Hi Ben, Am 22.04.2010 um 18:06 schrieb Dagobert Michelsen: > Am 22.04.2010 um 16:22 schrieb Ben Walton: >> Excerpts from Dagobert Michelsen's message of Wed Apr 21 03:38:03 -0400 2010: >>> Well, I got no feedback on my last mail to maintainers@: >> >> It's unfortunate, but seemingly normal. I updated both testing9* >> boxes last night to your build. My libmpfr build passes tests on 9x >> but still fails three on 9s. So, from where I sit, your build looks >> fine to me as those are the same numbers I saw with the old version. >> >> I won't rebuild gmp until after gcc4 has been taken care of since gmp >> seems to want/need gcc4 to build it. :) Do you recall if it wouldn't >> build at all with SOS? Maybe I should give it a kick with SOS12 now? > > I think it was pretty difficult, but please give it a try :-) I rebuild gmp 4.3.2 with Sun Studio 12 and also build 5.0.1 with several optimizations. Both are available at http://buildfarm.opencsw.org/experimental.html#libgmp It would be cool if you could take a look. Best regards -- Dago From pfelecan at opencsw.org Mon Jan 17 15:10:08 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 17 Jan 2011 15:10:08 +0100 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <20110117.11021300.3105295734@gyor.oxdrove.co.uk> (James Lee's message of "Mon, 17 Jan 2011 11:02:13 GMT") References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 14/01/11, 13:21:24, Ben Walton wrote regarding Re: > [csw-maintainers] [policy] files/dirs in /var/opt/csw: > >> The results are in: > >> Files and directories are allowed to be delivered to /var/opt/csw >> directly by the prototype of a package. => 8 votes (57%) > >> Directories may be delivered to /var/opt/csw by the prototype of a >> package, but files may not. => 4 votes (28%) > >> Neither files nor directories may be delivered to /var/opt/csw by the >> prototype of a package. => 2 votes (14%) > >> Phil: please adjust your scripts to allow packages delivering >> directories and/or files via the prototype to be allowed through. > > Also please can someone remove the references to supporting NFS share > of /opt/csw (as we now don't), that is eg: > > http://www.opencsw.org/about/core-principles/ > http://www.opencsw.org/use-it/sharing-optcsw/ > http://www.opencsw.org/about/faq/ > > > and probably some others. Further it would be good to add an additional > note and make an announcement to explain the change in policy. I'm begging for a different opinion: we still support sharing /opt/csw through NFS for most of our packages but there are some which are not supported "from the shelf"; for those not supported without administrator intervention a caveat can be published in the README.CSW which also document how to do it if there is a way to. Consequently it's more about modifying the referenced documents than removing them and, for the announcement, there is no need to make a big fuss aside explaining this minor change in policies. There are also gray cats. -- Peter From james at opencsw.org Mon Jan 17 16:05:58 2011 From: james at opencsw.org (James Lee) Date: Mon, 17 Jan 2011 15:05:58 GMT Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> Message-ID: <20110117.15055800.2845944633@gyor.oxdrove.co.uk> On 17/01/11, 14:10:08, Peter FELECAN wrote regarding Re: [csw-maintainers] [policy] files/dirs in /var/opt/csw: > > Also please can someone remove the references to supporting NFS share > > of /opt/csw (as we now don't), that is eg: > > > > http://www.opencsw.org/about/core-principles/ > > http://www.opencsw.org/use-it/sharing-optcsw/ > > http://www.opencsw.org/about/faq/ > > > > > > and probably some others. Further it would be good to add an additional > > note and make an announcement to explain the change in policy. > I'm begging for a different opinion: we still support sharing /opt/csw > through NFS for most of our packages "most" isn't support. It's unsupported but if it works for the subset of package you chose then I'm not going to stop you - until my package breaks your system. > There are also gray cats. We've not made a rule about cats. James. From pfelecan at opencsw.org Mon Jan 17 16:48:33 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 17 Jan 2011 16:48:33 +0100 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <20110117.15055800.2845944633@gyor.oxdrove.co.uk> (James Lee's message of "Mon, 17 Jan 2011 15:05:58 GMT") References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> <20110117.15055800.2845944633@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 17/01/11, 14:10:08, Peter FELECAN wrote regarding > Re: [csw-maintainers] [policy] files/dirs in /var/opt/csw: > > >> > Also please can someone remove the references to supporting NFS share >> > of /opt/csw (as we now don't), that is eg: >> > >> > http://www.opencsw.org/about/core-principles/ >> > http://www.opencsw.org/use-it/sharing-optcsw/ >> > http://www.opencsw.org/about/faq/ >> > >> > >> > and probably some others. Further it would be good to add an additional >> > note and make an announcement to explain the change in policy. > >> I'm begging for a different opinion: we still support sharing /opt/csw >> through NFS for most of our packages > > "most" isn't support. It's unsupported but if it works for the subset > of package you chose then I'm not going to stop you - until my package > breaks your system. > >> There are also gray cats. > > We've not made a rule about cats. This is a way to say that a manichean attitude is a little bit rigid. Manichean is when you say "'most' isn't support". Non manichean is when 'most' is support with exceptions and corresponding documented warnings. With all due respect I think that this is a finicky discussion. Nobody talks here about ayatollish absolute support except if we wish to stay in the pure Persian tradition. -- Peter From james at opencsw.org Mon Jan 17 17:38:22 2011 From: james at opencsw.org (James Lee) Date: Mon, 17 Jan 2011 16:38:22 GMT Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> <20110117.15055800.2845944633@gyor.oxdrove.co.uk> Message-ID: <20110117.16382200.1352170974@gyor.oxdrove.co.uk> On 17/01/11, 15:48:33, Peter FELECAN wrote regarding Re: [csw-maintainers] [policy] files/dirs in /var/opt/csw: > > "most" isn't support. It's unsupported but if it works for the subset > > of package you chose then I'm not going to stop you - until my package > > breaks your system. > > > >> There are also gray cats. > > > > We've not made a rule about cats. > This is a way to say that a manichean attitude is a little bit > rigid. Manichean is when you say "'most' isn't support". Non manichean > is when 'most' is support with exceptions and corresponding documented > warnings. With all due respect I think that this is a finicky > discussion. Nobody talks here about ayatollish absolute support except > if we wish to stay in the pure Persian tradition. You in particular have been complaining about discretion in the CSW process. If you don't like a rule don't make it. I do hope those that drove the democratic decision actually understood the issues, else, in the best tradition of referenda, we'd better try again until we get the right answer. I'm completely at ease with not supporting NFS, but don't pretend it's supported when we have policies that contradict it. James. From phil at bolthole.com Mon Jan 17 19:28:21 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 17 Jan 2011 10:28:21 -0800 Subject: [csw-maintainers] Unifying cvs and cvs_feature? In-Reply-To: <0EDB236A-E3CD-48BC-8504-C160973C4269@opencsw.org> References: <1119428C-2FE1-462B-8F30-9D2A60A2D6F2@opencsw.org> <0EDB236A-E3CD-48BC-8504-C160973C4269@opencsw.org> Message-ID: Okay, sounds like good reason for unifying. Looks like main original cvs hasnt been updated for over two years. That being said, I'd like to suggest one change. Rather than forcing the cvs_feature symlink into the cvs package, I'd suggest you update the cvs_feature package, to depend on new CVS, and deliver the symlink. That way the "cvs" package is more clean. On Mon, Jan 17, 2011 at 4:02 AM, Dagobert Michelsen wrote: > .... > It sounds to me that "cvs stable" is long outdated and of no practical > use as all fixes go to "feature". > > From phil at bolthole.com Mon Jan 17 19:54:39 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 17 Jan 2011 10:54:39 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <20110117.11021300.3105295734@gyor.oxdrove.co.uk> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> Message-ID: On Mon, Jan 17, 2011 at 3:02 AM, James Lee wrote: > ... > > Also please can someone remove the references to supporting NFS share > of /opt/csw (as we now don't), that is eg: > > http://www.opencsw.org/about/core-principles/ > http://www.opencsw.org/use-it/sharing-optcsw/ > http://www.opencsw.org/about/faq/ > > > and probably some others. ?Further it would be good to add an additional > note and make an announcement to explain the change in policy. > Are you referring to some explicit "we dont support this any more" decision that I missed, or are you saying, "the recent vote about /var, implies that we dont support it any more" ? If the latter, I believe that our president said before the most recent vote, that the "sharing /opt/csw" issue would be decided later, by a separate, explicit vote. If so, it would be premature to adjust documentation to remove "we support sharing /opt/csw" From bwalton at opencsw.org Tue Jan 18 02:02:28 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 17 Jan 2011 20:02:28 -0500 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <20110117.11021300.3105295734@gyor.oxdrove.co.uk> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> Message-ID: <1295312161-sup-9478@pinkfloyd.chass.utoronto.ca> Excerpts from James Lee's message of Mon Jan 17 06:02:13 -0500 2011: Hi James, > Also please can someone remove the references to supporting NFS > share of /opt/csw (as we now don't), that is eg: I don't think this vote changes our current support for NFS shared /opt/csw. The official var/ location is unchanged and regardless of this outcome, admins still need to jump through hoops to share /opt/csw and have a working var/. I did just update http://wiki.opencsw.org/shared-opt-csw-setup to reflect the results of the vote though. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Jan 18 02:13:35 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 17 Jan 2011 20:13:35 -0500 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> Message-ID: <1295312551-sup-8728@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jan 17 13:54:39 -0500 2011: Hi Phil, > If the latter, I believe that our president said before the most > recent vote, that the "sharing /opt/csw" issue would be decided > later, by a separate, explicit vote. If so, it would be premature > to adjust documentation to remove "we support sharing /opt/csw" Well, I think it was closer to "lets assume we support sharing /opt/csw and look at the var/ issue through that lens" without saying anything about a looming vote. One of the discussion topics for the winter camp is: Clearly define the goals of the project which in turn will be used to set package policy. I imagine that NFS sharing will be brought up as part of this. The winter camp won't actually be setting new policies directly[1], but it may spur on the call for voting on various topics. Dago has requested a discussion about "Freeze of package relevant changes (package naming, file locations, etc.)" as a topic too. I agree that this is a good idea. We've had a lot of things up in the air lately and not enough time to get packages catch up. It's good that we're active and discussing things like this, but if we're constantly architecting, we're not actually building. Thanks -Ben [1] Policy setting means voting which means more time required. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Tue Jan 18 10:54:07 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 18 Jan 2011 10:54:07 +0100 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <20110117.16382200.1352170974@gyor.oxdrove.co.uk> (James Lee's message of "Mon, 17 Jan 2011 16:38:22 GMT") References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> <20110117.15055800.2845944633@gyor.oxdrove.co.uk> <20110117.16382200.1352170974@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 17/01/11, 15:48:33, Peter FELECAN wrote regarding > Re: [csw-maintainers] [policy] files/dirs in /var/opt/csw: > >> > "most" isn't support. It's unsupported but if it works for the subset >> > of package you chose then I'm not going to stop you - until my package >> > breaks your system. >> > >> >> There are also gray cats. >> > >> > We've not made a rule about cats. > >> This is a way to say that a manichean attitude is a little bit >> rigid. Manichean is when you say "'most' isn't support". Non manichean >> is when 'most' is support with exceptions and corresponding documented >> warnings. With all due respect I think that this is a finicky >> discussion. Nobody talks here about ayatollish absolute support except >> if we wish to stay in the pure Persian tradition. > > You in particular have been complaining about discretion in the CSW > process. If you don't like a rule don't make it. I do hope those that > drove the democratic decision actually understood the issues, else, in > the best tradition of referenda, we'd better try again until we get the > right answer. This is non sense because: - I was complaining about *past* opacity and obscurity - I like the rule and proud to participate in it's making - people making up our community have the required intelligence to understand the issues at stake - the tradition to which you refer was anti-democratic, e.g. European Constitution and all, i.e. referendum says no and parliament says yes, in France, Netherlands and Ireland at least. > I'm completely at ease with not supporting NFS, but don't pretend it's > supported when we have policies that contradict it. This discussion being hopeless I let you have as many "last words" as you wish and ending my contribution to this thread. -- Peter From james at opencsw.org Tue Jan 18 11:30:05 2011 From: james at opencsw.org (James Lee) Date: Tue, 18 Jan 2011 10:30:05 GMT Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> Message-ID: <20110118.10300500.188748523@gyor.oxdrove.co.uk> On 17/01/11, 18:54:39, Philip Brown wrote regarding Re: [csw-maintainers] [policy] files/dirs in /var/opt/csw: > On Mon, Jan 17, 2011 at 3:02 AM, James Lee wrote: > > ... > > > > Also please can someone remove the references to supporting NFS share > > of /opt/csw (as we now don't), that is eg: > > > > http://www.opencsw.org/about/core-principles/ > > http://www.opencsw.org/use-it/sharing-optcsw/ > > http://www.opencsw.org/about/faq/ > > > > > > and probably some others. ?Further it would be good to add an additional > > note and make an announcement to explain the change in policy. > > > Are you referring to some explicit "we dont support this any more" > decision that I missed, or are you saying, > "the recent vote about /var, implies that we dont support it any more" > ? > If the latter, The latter. > I believe that our president said before the most > recent vote, that the "sharing /opt/csw" issue would be decided later, > by a separate, explicit vote. But it's already decided. In fact the /var/ issue was previously set by the reverse. The previous policy was to support NFS, this already implied no /var files via prototypes, so I'm unsure why the issue was revisited from the /var end. James. From james at opencsw.org Tue Jan 18 12:28:21 2011 From: james at opencsw.org (James Lee) Date: Tue, 18 Jan 2011 11:28:21 GMT Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> <20110117.15055800.2845944633@gyor.oxdrove.co.uk> <20110117.16382200.1352170974@gyor.oxdrove.co.uk> Message-ID: <20110118.11282100.2917088313@gyor.oxdrove.co.uk> On 18/01/11, 09:54:07, Peter FELECAN wrote regarding Re: [csw-maintainers] [policy] files/dirs in /var/opt/csw: > James Lee writes: > > On 17/01/11, 15:48:33, Peter FELECAN wrote regarding > > Re: [csw-maintainers] [policy] files/dirs in /var/opt/csw: > > > >> > "most" isn't support. It's unsupported but if it works for the subset > >> > of package you chose then I'm not going to stop you - until my package > >> > breaks your system. > >> > > >> >> There are also gray cats. > >> > > >> > We've not made a rule about cats. > > > >> This is a way to say that a manichean attitude is a little bit > >> rigid. Manichean is when you say "'most' isn't support". Non manichean > >> is when 'most' is support with exceptions and corresponding documented > >> warnings. With all due respect I think that this is a finicky > >> discussion. Nobody talks here about ayatollish absolute support except > >> if we wish to stay in the pure Persian tradition. > > > > You in particular have been complaining about discretion in the CSW > > process. If you don't like a rule don't make it. I do hope those that > > drove the democratic decision actually understood the issues, else, in > > the best tradition of referenda, we'd better try again until we get the > > right answer. > This is non sense because: > - I was complaining about *past* opacity and obscurity Your liking for discretion appears to be grey. > - I like the rule and proud to participate in it's making No one is questioning the ruling. > - the tradition to which you refer was anti-democratic, e.g. European > Constitution and all, i.e. referendum says no and parliament says yes, > in France, Netherlands and Ireland at least. No, I mean the repeats, in general repeat votes happen often. > This discussion being hopeless I let you have as many "last words" as you > wish and ending my contribution to this thread. Peter's teddy has exited the cot. James. From bonivart at opencsw.org Tue Jan 18 13:49:25 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 18 Jan 2011 13:49:25 +0100 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <20110118.10300500.188748523@gyor.oxdrove.co.uk> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> <20110118.10300500.188748523@gyor.oxdrove.co.uk> Message-ID: On Tue, Jan 18, 2011 at 11:30 AM, James Lee wrote: > But it's already decided. ?In fact the /var/ issue was previously set > by the reverse. ?The previous policy was to support NFS, this already > implied no /var files via prototypes, so I'm unsure why the issue was > revisited from the /var end. Maybe it implied no files in /var but it sure wasn't enforced, even pkg-get from Phil himself delivers files to /var. /peter From dam at opencsw.org Tue Jan 18 13:53:33 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 18 Jan 2011 13:53:33 +0100 Subject: [csw-maintainers] Unifying cvs and cvs_feature? In-Reply-To: References: <1119428C-2FE1-462B-8F30-9D2A60A2D6F2@opencsw.org> <0EDB236A-E3CD-48BC-8504-C160973C4269@opencsw.org> Message-ID: Hi Phil, Am 17.01.2011 um 19:28 schrieb Philip Brown: > Okay, sounds like good reason for unifying. Looks like main original > cvs hasnt been updated for over two years. > > That being said, I'd like to suggest one change. > Rather than forcing the cvs_feature symlink into the cvs package, I'd > suggest you update the cvs_feature package, to depend on new CVS, and > deliver the symlink. > That way the "cvs" package is more clean. I already implemented it exactly this way :-) Submitting it then. Best regards -- Dago > > > > On Mon, Jan 17, 2011 at 4:02 AM, Dagobert Michelsen wrote: >> .... >> It sounds to me that "cvs stable" is long outdated and of no practical >> use as all fixes go to "feature". >> >> > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From maciej at opencsw.org Tue Jan 18 14:01:46 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 18 Jan 2011 13:01:46 +0000 Subject: [csw-maintainers] When a shared library needs a data file Message-ID: I'm working on an update to libmagic, and an interesting issue has appeared. The shared library is not enough to use libmagic; a data file is required too (magic.mgc). You could argue that it's not the shared library per se that needs that file, but if you use the libmagic API, you need to initialize your magic cookie with data, and you assume that the data is already there. Here's an example usage: magic_cookie = magic.open() magic_cookie.load() magic_cookie.setflags(magic.MAGIC_MIME) mime = magic_cookie.file(full_path) In the packaging context, I would like to ensure that Current layout: CSWlibmagic: contains libmagic.so.1 and the magic.mgc file How to split it up? Version 1: CSWlibmagic: Contains magic.mgc, depends on CSWlibmagic1 CSWlibmagic1: Contains libmagic.so.1 CSWlibmagic (data) --> CSWlibmagic1 Advantages: minimal changes to the catalog (new packages, renames, etc) Disadvantages: Applications need to depend on both libmagic and libmagic1 in order to achieve working setup. Dependencies declared don't match the actual dependencies. Version 2: CSWlibmagic: Empty transitional package, depends on CSWlibmagic1 CSWlibmagic1: Contains libmagic.so.1, depends on CSWlibmagic-common CSWlibmagic-common: Contains magic.mgc Here, CSWlibmagic1 always pulls in CSWlibmagic-common, and has the database. The downside is that there is one package more. CSWlibmagic (legacy) --> CSWlibmagic1 (shared lib) --> CSWlibmagic-common (data) Advantages: When CSWlibmagic2 comes along, we'll declare the dependency CSWlibmagic-common, and CSWlibmagic1 will use the new shared data. Disadvantages: Now we have not two, but three packages (until CSWlibmagic goes away). Thoughts? From maciej at opencsw.org Tue Jan 18 14:02:59 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 18 Jan 2011 13:02:59 +0000 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: References: Message-ID: No dia 18 de Janeiro de 2011 13:01, Maciej (Matchek) Blizinski escreveu: > In the packaging context, I would like to ensure that ...dependencies are detected by checkpkg, and what checkpkg suggests matches reality, i.e.: you include dependencies that checkpkg suggested and the resulting package works. From pfelecan at opencsw.org Tue Jan 18 14:42:46 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 18 Jan 2011 14:42:46 +0100 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: (Maciej Blizinski's message of "Tue, 18 Jan 2011 13:01:46 +0000") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > I'm working on an update to libmagic, and an interesting issue has > appeared. The shared library is not enough to use libmagic; a data > file is required too (magic.mgc). You could argue that it's not the > shared library per se that needs that file, but if you use the > libmagic API, you need to initialize your magic cookie with data, and > you assume that the data is already there. Here's an example usage: > > magic_cookie = magic.open() > magic_cookie.load() > magic_cookie.setflags(magic.MAGIC_MIME) > mime = magic_cookie.file(full_path) > > In the packaging context, I would like to ensure that > > Current layout: > > CSWlibmagic: contains libmagic.so.1 and the magic.mgc file > > How to split it up? > > Version 1: > > CSWlibmagic: Contains magic.mgc, depends on CSWlibmagic1 > CSWlibmagic1: Contains libmagic.so.1 > > CSWlibmagic (data) --> CSWlibmagic1 > > Advantages: minimal changes to the catalog (new packages, renames, etc) > Disadvantages: Applications need to depend on both libmagic and > libmagic1 in order to achieve working setup. Dependencies declared > don't match the actual dependencies. > > Version 2: > > CSWlibmagic: Empty transitional package, depends on CSWlibmagic1 > CSWlibmagic1: Contains libmagic.so.1, depends on CSWlibmagic-common > CSWlibmagic-common: Contains magic.mgc > > Here, CSWlibmagic1 always pulls in CSWlibmagic-common, and has the > database. The downside is that there is one package more. > > CSWlibmagic (legacy) --> CSWlibmagic1 (shared lib) --> CSWlibmagic-common (data) > > Advantages: When CSWlibmagic2 comes along, we'll declare the > dependency CSWlibmagic-common, and CSWlibmagic1 will use the new > shared data. > Disadvantages: Now we have not two, but three packages (until > CSWlibmagic goes away). I'm leaning toward 2 as for me the advantages overweight the inconveniences. IMO, increasing the number of packages is not an obstacle to whatever. -- Peter From dam at opencsw.org Tue Jan 18 14:46:24 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 18 Jan 2011 14:46:24 +0100 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: References: Message-ID: <422AABC2-BA04-4DED-9907-A34B2092259B@opencsw.org> Hi, Am 18.01.2011 um 14:42 schrieb Peter FELECAN: > "Maciej (Matchek) Blizinski" writes: > >> I'm working on an update to libmagic, and an interesting issue has >> appeared. The shared library is not enough to use libmagic; a data >> file is required too (magic.mgc). You could argue that it's not the >> shared library per se that needs that file, but if you use the >> libmagic API, you need to initialize your magic cookie with data, and >> you assume that the data is already there. Here's an example usage: >> >> magic_cookie = magic.open() >> magic_cookie.load() >> magic_cookie.setflags(magic.MAGIC_MIME) >> mime = magic_cookie.file(full_path) >> >> In the packaging context, I would like to ensure that >> >> Current layout: >> >> CSWlibmagic: contains libmagic.so.1 and the magic.mgc file >> >> How to split it up? >> >> Version 1: >> >> CSWlibmagic: Contains magic.mgc, depends on CSWlibmagic1 >> CSWlibmagic1: Contains libmagic.so.1 >> >> CSWlibmagic (data) --> CSWlibmagic1 >> >> Advantages: minimal changes to the catalog (new packages, renames, etc) >> Disadvantages: Applications need to depend on both libmagic and >> libmagic1 in order to achieve working setup. Dependencies declared >> don't match the actual dependencies. >> >> Version 2: >> >> CSWlibmagic: Empty transitional package, depends on CSWlibmagic1 >> CSWlibmagic1: Contains libmagic.so.1, depends on CSWlibmagic-common >> CSWlibmagic-common: Contains magic.mgc >> >> Here, CSWlibmagic1 always pulls in CSWlibmagic-common, and has the >> database. The downside is that there is one package more. >> >> CSWlibmagic (legacy) --> CSWlibmagic1 (shared lib) --> CSWlibmagic-common (data) >> >> Advantages: When CSWlibmagic2 comes along, we'll declare the >> dependency CSWlibmagic-common, and CSWlibmagic1 will use the new >> shared data. >> Disadvantages: Now we have not two, but three packages (until >> CSWlibmagic goes away). > > I'm leaning toward 2 as for me the advantages overweight the > inconveniences. IMO, increasing the number of packages is not an > obstacle to whatever. I agree with Peter. And you can also not check dependencies properly in version 1. Also it is more consistent as the library really *needs* the file, so there logically should be this dependency as in version 2. Best regards -- Dago From james at opencsw.org Tue Jan 18 17:45:42 2011 From: james at opencsw.org (James Lee) Date: Tue, 18 Jan 2011 16:45:42 GMT Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> <20110118.10300500.188748523@gyor.oxdrove.co.uk> Message-ID: <20110118.16454200.2833481343@gyor.oxdrove.co.uk> On 18/01/11, 12:49:25, Peter Bonivart wrote regarding Re: [csw-maintainers] [policy] files/dirs in /var/opt/csw: > On Tue, Jan 18, 2011 at 11:30 AM, James Lee wrote: > > But it's already decided. ?In fact the /var/ issue was previously set > > by the reverse. ?The previous policy was to support NFS, this already > > implied no /var files via prototypes, so I'm unsure why the issue was > > revisited from the /var end. > Maybe it implied no files in /var but it sure wasn't enforced, Lack of enforcement doesn't make it correct. It does show no one cares or no one bothered to complain. > even > pkg-get from Phil himself delivers files to /var. Even Phil could have it wrong. [Note, it's /var/pkg-get not /var/opt/csw] James. From phil at bolthole.com Tue Jan 18 18:34:28 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 Jan 2011 09:34:28 -0800 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: References: Message-ID: it's interesting that you dont seem to suggest another variant, "ship the magic text file, with the shared lib package, since it is useless without it". the designation of "libmagic_common" is also odd in naming: "common" denotes "information shared 'in common' across multiple packages". What other packages would it be sharing it with? I didnt see indication of that. From maciej at opencsw.org Tue Jan 18 20:18:45 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 18 Jan 2011 19:18:45 +0000 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: References: Message-ID: No dia 18 de Janeiro de 2011 17:34, Philip Brown escreveu: > it's interesting that you dont seem to suggest another variant, > "ship the magic text file, with the shared lib package, since it is > useless without it". The lack of that option was intentional. If the data file was bundled with the library, it would be impossible to phase out the shared library by removing a package. It would be another form of bundling multiple shared libraries in one package - something we want to stop doing. > the designation of "libmagic_common" is also odd in naming: > "common" denotes "information shared 'in common' across multiple packages". > What other packages would it be sharing it with? I didnt see indication of that. The indication was in the e-mail. Quoting from my previous e-mail: "When CSWlibmagic2 comes along, we'll declare the dependency CSWlibmagic-common, and CSWlibmagic1 will use the new shared data." CSWlibmagic1 and CSWlibmagic2 would/could both be clients of shared data. Before CSWlibmagic2: CSWlibmagic1 ? magic.mgc via CSWlibmagic_common After: Variant in which libmagic.so.2 uses the same magic.mgc file: CSWlibmagic1 ? magic.mgc via CSWlibmagic-common CSWlibmagic2 ? magic.mgc via CSWlibmagic-common Varian in which libmagic.so.1 doesn't need magic.mgc but a different file: CSWlibmagic1 ? magic.mgc via CSWlibmagic-common CSWlibmagic2 ? future-data-file.mgc via CSWlibmagic-xxx Your question about naming brings up an interesting point. Perhaps the with magic.mgc shouldn't be named CSW-common, but CSW-, which in our case would be CSWlibmagic-magic. Potential options for naming: CSWlibmagic-common CSWlibmagic-magic CSWlibmagic-magicmgc CSWmagic CSWmagic-mgc I'm not convinced whether it's better to provide magic.mgc in an isolated file. We would still need a package for /opt/csw/share/man/man3/libmagic.3 and /opt/csw/share/man/man4/magic.4. It should be neither CSWgfile, nor CSWlibmagic (deprecated), nor CSWlibmagic1 (libmagic.so.1 only), nor CSWlibmagic-magic (magic.mgc only). Maciej From maciej at opencsw.org Tue Jan 18 20:41:09 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 18 Jan 2011 19:41:09 +0000 Subject: [csw-maintainers] Private shared libraries Message-ID: I've just added the following bit of text to our wiki page about shared libraries[1]. It explains how to create a directory for private shared libraries. [1] http://wiki.opencsw.org/packaging-shared-libraries#toc10 +++ Private shared libraries Some software projects install private (non-linkable) shared libraries into libdir (e.g. {{/opt/csw/lib}}) by default. To ensure that they are private, they need to be moved to a subdirectory, e.g. {{/opt/csw/lib/}}. To create a private library and install 32 and 64-bit libraries, they need to be laid out as follows: On sparc: [[code]] /opt/csw/lib/foo /opt/csw/lib/foo/32 --> . /opt/csw/lib/foo/64 --> sparcv9 [[/code]] On i386: [[code]] /opt/csw/lib/foo /opt/csw/lib/foo/32 --> . /opt/csw/lib/foo/64 --> amd64 [[/code]] In GAR, it can be simplified by symlinking: * 32 to {{$(ISA_DEFAULT)}} * 64 to {{$(ISA_DEFAULT64)}} The runpath needs to be set to {{/opt/csw/lib/foo/64}}, e.g. {{-R/opt/csw/lib/foo/64}}. From phil at bolthole.com Tue Jan 18 20:56:27 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 Jan 2011 11:56:27 -0800 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: References: Message-ID: On 1/18/11, Maciej (Matchek) Blizinski wrote: > > Your question about naming brings up an interesting point. Perhaps > the with magic.mgc shouldn't be named CSW-common, but > CSW-, which in our case would be > CSWlibmagic-magic. Potential options for naming: > > CSWlibmagic-common > CSWlibmagic-magic libmagic_magic gets my vote. > I'm not convinced whether it's better to provide magic.mgc in an > isolated file. We would still need a package for > /opt/csw/share/man/man3/libmagic.3 and > /opt/csw/share/man/man4/magic.4. It should be neither CSWgfile, nor > CSWlibmagic (deprecated), nor CSWlibmagic1 (libmagic.so.1 only), nor > CSWlibmagic-magic (magic.mgc only). I think we have a fairly clear existing "standard" on that already. libmagic_doc From dam at opencsw.org Tue Jan 18 21:39:05 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 18 Jan 2011 21:39:05 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] yaz In-Reply-To: References: Message-ID: Hi Phil, Am 18.01.2011 um 19:05 schrieb Philip Brown: > On 1/18/11, Dagobert Michelsen wrote: >> Hi Phil, >> >> Am 07.01.2011 um 16:34 schrieb Dagobert Michelsen: >>> Am 07.01.2011 um 16:28 schrieb Philip Brown: >>>> Errrr.... Almost all of the listed packages, are missing from newpkgs. >>> >>> Strange, pushed again. >> >> "yaz" has still not been released. I repushed again. Please verify >> that it reaches the mirrors. > > Sorry, I had set yaz aside, and forgotten about it. I THOUGHT I had > emailed the list, but dont see it. maybe I forgot to send :-( > > There's a whole bunch of incorrect references to /usr/local in the > manpages, etc. > I think these are not trivial examples, but "this is where you > configure yaz" type docs. > How about cleaning them up? Phil, your constant nagging about documentation is a real PITA. Fixing these takes an amount of time (probably on every release) which has no resemblance to the main package. We have A TON of really outdated, not packaged PRIO-1 stuff. Do you really think we should focus on documentation instead of having e.g. an updated Kerberos or PHP? Fixing doc issues in all packages takes a regular amount of time in terms of *hours* I don't have for version bumps. For a 100% package we should fix it, right. But we are not at 99%. Or 95%. Or even 90%. We are more at 75%. Focusing on docs is IMHO the wrong priority. Best regards -- Dago From dam at opencsw.org Tue Jan 18 21:43:02 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 18 Jan 2011 21:43:02 +0100 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: References: Message-ID: <2BF10BA5-4EAD-41CF-8947-9C55CC8C04A8@opencsw.org> Hi Phil, Am 18.01.2011 um 20:56 schrieb Philip Brown: >> I'm not convinced whether it's better to provide magic.mgc in an >> isolated file. We would still need a package for >> /opt/csw/share/man/man3/libmagic.3 and >> /opt/csw/share/man/man4/magic.4. It should be neither CSWgfile, nor >> CSWlibmagic (deprecated), nor CSWlibmagic1 (libmagic.so.1 only), nor >> CSWlibmagic-magic (magic.mgc only). > > I think we have a fairly clear existing "standard" on that already. > libmagic_doc IIRC it is different. section 3 stuff goes into *-dev and section 4 stuff should be in the packages with the containing files *unless* we have a documentation package which should only be made if the documentation is really large (like qt). Best regards -- Dago From phil at bolthole.com Tue Jan 18 22:09:58 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 Jan 2011 13:09:58 -0800 Subject: [csw-maintainers] [csw-pkgsubmissions] yaz In-Reply-To: References: Message-ID: On 1/18/11, Dagobert Michelsen wrote: > > Phil, your constant nagging about documentation is a real PITA. > Fixing these takes an amount of time (probably on every release) > which has no resemblance to the main package. We have A TON of > really outdated, not packaged PRIO-1 stuff. Do you really think > we should focus on documentation instead of having e.g. an updated > Kerberos or PHP? Fixing doc issues in all packages takes a regular > amount of time in terms of *hours* I don't have for version > bumps. I think you are rather exaggerating. For the most recent email I sent off about.. oh whatever it was.. editing the info file, and doing the gar "make a patch" thing, should be much much less than "hours". it should in fact, be less than a single hour. More like 20 minutes,tops. Wasnt the whole point of having the auto-git stuff in gar, to make small patches like that trivial? > For a 100% package we should fix it, right. But we are not > at 99%. Or 95%. Or even 90%. We are more at 75%. Focusing on > docs is IMHO the wrong priority. So, in your opinion, it's better to have 100 packages at 80% "correctness", than 80 packages at 100% "correctness". I happen to have the opposite opinion. Because if we dont fix up those packages now, they probably never will get fixed. But if we fix up "the 80" *now*, then we have our hands clean to get the other 20 clean later on. If all this is "too much work for you right now", Dago, why dont you just slow down, and do fewer packages at a time? From bonivart at opencsw.org Tue Jan 18 22:10:45 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 18 Jan 2011 22:10:45 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] yaz In-Reply-To: References: Message-ID: On Tue, Jan 18, 2011 at 9:39 PM, Dagobert Michelsen wrote: > Phil, your constant nagging about documentation is a real PITA. > Fixing these takes an amount of time (probably on every release) > which has no resemblance to the main package. We have A TON of > really outdated, not packaged PRIO-1 stuff. Do you really think > we should focus on documentation instead of having e.g. an updated > Kerberos or PHP? Fixing doc issues in all packages takes a regular > amount of time in terms of *hours* I don't have for version > bumps. For a 100% package we should fix it, right. But we are not > at 99%. Or 95%. Or even 90%. We are more at 75%. Focusing on > docs is IMHO the wrong priority. +1 From phil at bolthole.com Tue Jan 18 22:11:52 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 Jan 2011 13:11:52 -0800 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: <2BF10BA5-4EAD-41CF-8947-9C55CC8C04A8@opencsw.org> References: <2BF10BA5-4EAD-41CF-8947-9C55CC8C04A8@opencsw.org> Message-ID: On 1/18/11, Dagobert Michelsen wrote: > Hi Phil, > > Am 18.01.2011 um 20:56 schrieb Philip Brown: >>> I'm not convinced whether it's better to provide magic.mgc in an >>> isolated file. We would still need a package for >>> /opt/csw/share/man/man3/libmagic.3 and >>> /opt/csw/share/man/man4/magic.4. It should be neither CSWgfile, nor >>> CSWlibmagic (deprecated), nor CSWlibmagic1 (libmagic.so.1 only), nor >>> CSWlibmagic-magic (magic.mgc only). >> >> I think we have a fairly clear existing "standard" on that already. >> libmagic_doc > > IIRC it is different. section 3 stuff goes into *-dev and > section 4 stuff should be in the packages with the containing > files *unless* we have a documentation package which should > only be made if the documentation is really large (like qt). What do you base those statements on? I dont recall ever reading something like the above in our standards. If people want to put ALL the doc files in _doc, including development related documentation, there is nothing stopping them that I am aware of. _devel, is at minimum, for files *required* for developing/compiling. Technically speaking, man pages and other docs are not "required" there. From dam at opencsw.org Tue Jan 18 22:25:20 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 18 Jan 2011 22:25:20 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] yaz In-Reply-To: References: Message-ID: <6AE22001-DEF4-4FCC-9F68-51DBCEB651C9@opencsw.org> Hi Phil, Am 18.01.2011 um 22:09 schrieb Philip Brown: > On 1/18/11, Dagobert Michelsen wrote: >> >> Phil, your constant nagging about documentation is a real PITA. >> Fixing these takes an amount of time (probably on every release) >> which has no resemblance to the main package. We have A TON of >> really outdated, not packaged PRIO-1 stuff. Do you really think >> we should focus on documentation instead of having e.g. an updated >> Kerberos or PHP? Fixing doc issues in all packages takes a regular >> amount of time in terms of *hours* I don't have for version >> bumps. > > I think you are rather exaggerating. > For the most recent email I sent off about.. oh whatever it was.. > editing the info file, and doing the gar "make a patch" thing, should > be much much less than "hours". > it should in fact, be less than a single hour. More like 20 minutes,tops. > > Wasnt the whole point of having the auto-git stuff in gar, to make > small patches like that trivial? I won't make this kind of patch. If I fix it I do it right. That means moving the documentation to autoconf substitution. There are already too many patches I have to take care of on upstream bumps. If upstream not already has done the autoconf-integration my patches probably won't get accepted anyway. The GIT patch integration is mainly there to allow compilation at all and provide patches to upstream. >> For a 100% package we should fix it, right. But we are not >> at 99%. Or 95%. Or even 90%. We are more at 75%. Focusing on >> docs is IMHO the wrong priority. > > So, in your opinion, it's better to have 100 packages at 80% > "correctness", than 80 packages at 100% "correctness". In my opinion it is better to have 100 packages at current versions with some incorrect docs than allowing 20 important outdated packages and correct docs for the rest. > I happen to have the opposite opinion. Because if we dont fix up those > packages now, they probably never will get fixed. > But if we fix up "the 80" *now*, then we have our hands clean to get > the other 20 clean later on. > > If all this is "too much work for you right now", Dago, why dont you > just slow down, and do fewer packages at a time? Because I don't *want* to spend the effort in the package. For most people (including me) it is good enough if the package works at all (and that is already hard enough). We are far (*far*) from this kind of quality you are envisioning. My pace is driven about 75% by customer demands and 25% by fun. Updating docs is in neither of the two categories. I have 0% bugs files for wrong documentation, but some for functional defects, version bumps, missing SMF integration, AUX library support, pending upstream work on SE Toolkit, reenabling automatic builds and a ton of other stuff. I will not squander my time by fixing documentation details for prio-3 packages where upstream is too lazy to do so. Don't get me wrong: If I had 50 packages to maintain instead of 500 I would probably enjoy making 100% packages and tweak every little bit of it. But having the maintainer power we have it is IMHO really important to focus on the important things and allow to have some fun on the rest. Best regards -- Dago From dam at opencsw.org Tue Jan 18 22:29:51 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 18 Jan 2011 22:29:51 +0100 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: References: <2BF10BA5-4EAD-41CF-8947-9C55CC8C04A8@opencsw.org> Message-ID: <50CE9AFB-D4BF-4128-96A4-DFD2E73FCCEE@opencsw.org> Hi Phil, Am 18.01.2011 um 22:11 schrieb Philip Brown: > On 1/18/11, Dagobert Michelsen wrote: >> Am 18.01.2011 um 20:56 schrieb Philip Brown: >>>> I'm not convinced whether it's better to provide magic.mgc in an >>>> isolated file. We would still need a package for >>>> /opt/csw/share/man/man3/libmagic.3 and >>>> /opt/csw/share/man/man4/magic.4. It should be neither CSWgfile, nor >>>> CSWlibmagic (deprecated), nor CSWlibmagic1 (libmagic.so.1 only), nor >>>> CSWlibmagic-magic (magic.mgc only). >>> >>> I think we have a fairly clear existing "standard" on that already. >>> libmagic_doc >> >> IIRC it is different. section 3 stuff goes into *-dev and >> section 4 stuff should be in the packages with the containing >> files *unless* we have a documentation package which should >> only be made if the documentation is really large (like qt). > > What do you base those statements on? > I dont recall ever reading something like the above in our standards. > If people want to put ALL the doc files in _doc, including development > related documentation, there is nothing stopping them that I am aware > of. No problem to put all docs in *-doc (as said for big packages like QT). If there is no doc package section 3 belongs to *-dev. At least this is the default in GAR and IMHO it makes sense to do so. > _devel, is at minimum, for files *required* for developing/compiling. > Technically speaking, man pages and other docs are not "required" there. ...but neither are they associated with the normal package containing binaries. API documentation (which is (3)) is pretty much related to development I would say, maybe section 5 (standards) is also. In addition to that I would minimize footprint for regular use and put everything only valuable to a developer in *-devel. Best regards -- Dago From phil at bolthole.com Tue Jan 18 23:21:08 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 Jan 2011 14:21:08 -0800 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: <50CE9AFB-D4BF-4128-96A4-DFD2E73FCCEE@opencsw.org> References: <2BF10BA5-4EAD-41CF-8947-9C55CC8C04A8@opencsw.org> <50CE9AFB-D4BF-4128-96A4-DFD2E73FCCEE@opencsw.org> Message-ID: On 1/18/11, Dagobert Michelsen wrote: > Hi Phil, > > Am 18.01.2011 um 22:11 schrieb Philip Brown: >... > > No problem to put all docs in *-doc (as said for big packages like QT). > If there is no doc package section 3 belongs to *-dev. At least this is > the default in GAR and IMHO it makes sense to do so. I agree >> _devel, is at minimum, for files *required* for developing/compiling. >> Technically speaking, man pages and other docs are not "required" there. > > ...but neither are they associated with the normal package containing > binaries. API documentation (which is (3)) is pretty much related to > development I would say, maybe section 5 (standards) is also. In > addition to that I would minimize footprint for regular use and put > everything only valuable to a developer in *-devel. Sorry, for some reason I was not thinking that there is already a devel. I had the impression you were talking about a devel package, consisting solely of those man pages :-} yes, when there is a devel package already, I agree that *small* development-specific documentation can fit in there. However, I think that "large" dev docs, usually belong in a _docs package. Depending on whether the _devel package itself is small. If it's large anyway... then large docs arent so important. to split. From phil at bolthole.com Tue Jan 18 23:28:44 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 Jan 2011 14:28:44 -0800 Subject: [csw-maintainers] [csw-pkgsubmissions] yaz In-Reply-To: <6AE22001-DEF4-4FCC-9F68-51DBCEB651C9@opencsw.org> References: <6AE22001-DEF4-4FCC-9F68-51DBCEB651C9@opencsw.org> Message-ID: On 1/18/11, Dagobert Michelsen wrote: >.... >> Wasnt the whole point of having the auto-git stuff in gar, to make >> small patches like that trivial? > > I won't make this kind of patch. If I fix it I do it right. That means > moving the documentation to autoconf substitution. There are already > too many patches I have to take care of on upstream bumps. If upstream > not already has done the autoconf-integration my patches probably > won't get accepted anyway. > Do you not see rather large irony there? "[I care strongly about making the best quality packages! Why is why I'm not going to improve the quality of my packages!]" There's nothing particularly "wrong" about doing a file-specific patch for this sort of thing. (quickie substitution of /opt/csw for /usr/local, in .info files) Yes, it would be "nice" for the open software community at large, if someone were to fully patch the autoconf stuff to update docs based on --prefix cleanly. But OUR community of users, should be more important than the global community of open software. If there's a choice between making *our* users happy Right Now, even if the larger community is left out, vs "well, Someone will do a Nice fix, Someday".... That becomes a choice between making our users happy, or making noone happy. Please spend the extra 5 minutes to make *our* users happier? From bonivart at opencsw.org Tue Jan 18 23:48:17 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 18 Jan 2011 23:48:17 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] yaz In-Reply-To: References: <6AE22001-DEF4-4FCC-9F68-51DBCEB651C9@opencsw.org> Message-ID: On Tue, Jan 18, 2011 at 11:28 PM, Philip Brown wrote: > Please spend the extra 5 minutes to make *our* users happier? You can not just make up rules as you go along. Stop demanding extra work from us while blocking our packages. You have no right to do that. From phil at bolthole.com Wed Jan 19 00:00:57 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 Jan 2011 15:00:57 -0800 Subject: [csw-maintainers] [csw-pkgsubmissions] yaz In-Reply-To: References: <6AE22001-DEF4-4FCC-9F68-51DBCEB651C9@opencsw.org> Message-ID: On 1/18/11, Peter Bonivart wrote: > On Tue, Jan 18, 2011 at 11:28 PM, Philip Brown wrote: >> Please spend the extra 5 minutes to make *our* users happier? > > You can not just make up rules as you go along. Stop demanding extra > work from us while blocking our packages. You have no right to do > that. I'm not "demanding" anything. I'm having a discussion with a maintainer, while the packages are currently sitting in pending. "Stop turning everything into a rant about blocking packages, especially when they aren't even YOUR packages. You have no right to do that". From bonivart at opencsw.org Wed Jan 19 00:10:12 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 19 Jan 2011 00:10:12 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] yaz In-Reply-To: References: <6AE22001-DEF4-4FCC-9F68-51DBCEB651C9@opencsw.org> Message-ID: On Wed, Jan 19, 2011 at 12:00 AM, Philip Brown wrote: > I'm not "demanding" anything. I'm having a discussion with a > maintainer, while the packages are currently sitting in pending. You're trying to gain leverage since we all know that you can keep our packages pending indefinitely to prove a point. You need to learn to separate policy making and enforcing. If you think this /usr/local-thing is worthwhile to do something about then do so, round up the packages concerned and start a project to fix it but stop prolonging the release process, this is not an agreed upon standard. From bwalton at opencsw.org Wed Jan 19 01:25:12 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 18 Jan 2011 19:25:12 -0500 Subject: [csw-maintainers] [csw-pkgsubmissions] yaz In-Reply-To: References: <6AE22001-DEF4-4FCC-9F68-51DBCEB651C9@opencsw.org> Message-ID: <1295396355-sup-2554@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Tue Jan 18 18:10:12 -0500 2011: Hi Phil, > If you think this /usr/local-thing is worthwhile to do something > about then do so, round up the packages concerned and start a > project to fix it but stop prolonging the release process, this is > not an agreed upon standard. Peter is right in that you shouldn't enforce a non-existent standard like this. His suggestion is both good and useful. I'd suggest going one step further: propose that it become policy and see if everyone (at least the majority) agrees with you. If so, you've got a reason to block packages...otherwise you don't. It's easier for everyone. I don't think people are disagreeing that removing /usr/local references is a bad thing, just that they don't like being blocked at the gate for something that until recently hasn't been an issue. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Wed Jan 19 01:41:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 18 Jan 2011 19:41:20 -0500 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: References: Message-ID: <1295397496-sup-3624@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Tue Jan 18 08:42:46 -0500 2011: Hi Maciej, > I'm leaning toward 2 as for me the advantages overweight the > inconveniences. IMO, increasing the number of packages is not an > obstacle to whatever. I agree with Peter and Dago here. An extra package is a small price to pay for the granularity that will pay off later. I'd never shy away from an extra split if there is potential for long term win. I I prefer -common to -magic (as per later discussion) as it's clearer that the files provided are somehow shared. If you prefer -magic though, I wouldn't object too strenuously as it should be a libmagic-x.y.z shared entity only, no? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Jan 19 09:34:17 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 19 Jan 2011 08:34:17 +0000 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: <1295397496-sup-3624@pinkfloyd.chass.utoronto.ca> References: <1295397496-sup-3624@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 19 de Janeiro de 2011 00:41, Ben Walton escreveu: > Excerpts from Peter FELECAN's message of Tue Jan 18 08:42:46 -0500 2011: > > Hi Maciej, > >> I'm leaning toward 2 as for me the advantages overweight the >> inconveniences. IMO, increasing the number of packages is not an >> obstacle to whatever. > > I agree with Peter and Dago here. ?An extra package is a small price > to pay for the granularity that will pay off later. ?I'd never shy > away from an extra split if there is potential for long term win. Agreed. > I prefer -common to -magic (as per later discussion) as it's clearer > that the files provided are somehow shared. ?If you prefer -magic > though, I wouldn't object too strenuously as it should be a > libmagic-x.y.z shared entity only, no? Yes, it could be shared between libmagic{1,2}, although it's only a speculation. The reason I prefer CSWlibmagic-somethingspecific is that it's more informative. The "-common" suffix suggests that this is a base package for libmagic, which is fine, but not very informative. I thought about -magic, because it designates one specific file that can be later phased out by removing a package - the same idea that is behind shared libraries. From pfelecan at opencsw.org Wed Jan 19 11:15:46 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 19 Jan 2011 11:15:46 +0100 Subject: [csw-maintainers] deleting a bug report Message-ID: I've made a mistake reporting an issue for the wrong package: gdb instead of gettext. The second mistake was to close it instead of moving it to the correct package. Now I want to delete it but I receive the following error: 0004669: installation error You did not have appropriate permissions to perform that action. Is there something that I can do? Not that is very important but I prefer a clean cot. -- Peter From dam at opencsw.org Wed Jan 19 11:20:17 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 19 Jan 2011 11:20:17 +0100 Subject: [csw-maintainers] deleting a bug report In-Reply-To: References: Message-ID: <6C16EAFA-6943-4600-B034-F393791D5D60@opencsw.org> Hi Peter, Am 19.01.2011 um 11:15 schrieb Peter FELECAN: > I've made a mistake reporting an issue for the wrong package: gdb > instead of gettext. The second mistake was to close it instead of moving > it to the correct package. Now I want to delete it but I receive the > following error: > > 0004669: installation error You did not have appropriate permissions to > perform that action. > > Is there something that I can do? Not that is very important but I > prefer a clean cot. Done. Best regards -- Dago From bwalton at opencsw.org Wed Jan 19 16:10:12 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 19 Jan 2011 10:10:12 -0500 Subject: [csw-maintainers] Duplicate packages in GAR In-Reply-To: <4D33ECF0.5010200@wbonnet.net> References: <4D33ECF0.5010200@wbonnet.net> Message-ID: <1295449736-sup-4629@pinkfloyd.chass.utoronto.ca> Excerpts from William Bonnet's message of Mon Jan 17 02:17:04 -0500 2011: Hi William, > Should we allow this or not ? It would be much safer to have a > single build description for a given package. Of course it is not > possible to prevent from this at SVN level. But i can modify > newpkgs-% target so it generates a warning if the package already > exist in uwatch db, and cron a database test to send warning emails. As much as possible, this should be avoided. I'm sure that the duplication that exists is accidental. The descriptions should be merged (or one side discarded, depending). That would be a job for the people that added them though (or the current maintainer). Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Jan 19 16:45:03 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 19 Jan 2011 16:45:03 +0100 Subject: [csw-maintainers] Duplicate packages in GAR In-Reply-To: <4D33ECF0.5010200@wbonnet.net> References: <4D33ECF0.5010200@wbonnet.net> Message-ID: Hi William, Am 17.01.2011 um 08:17 schrieb William Bonnet: > Here is the list : > > PKG_CATALOGNAME PKG_NAME PKG_GAR_PATH > evolution_webcal CSWevolutionexchange pkg/evolution-exchange/trunk > evolution_webcal CSWevolutionwebcal pkg/evolution-webcal/trunk > evolution_webcal_devel CSWevolutionwebcal-devel pkg/evolution-webcal/trunk > evolution_webcal_devel CSWevolutionexchange-devel pkg/evolution-exchange/trunk > evolution_webcal_doc CSWevolutionwebcal-doc pkg/evolution-webcal/trunk > evolution_webcal_doc CSWevolutionexchange-doc pkg/evolution-exchange/trunk > libsoup2 CSWlibsoup2 pkg/libsoup/trunk > libsoup2 CSWlibsoup2 pkg/libsoup2/trunk > pm_cryptcbc CSWpmcryptcbc pkg/cpan/Crypt-CBC/trunk > pm_cryptcbc CSWpmcryptcbc pkg/cpan/Crypt-Random/trunk > pm_unixsyslog CSWpmunixsyslog pkg/cpan/Unix-Syslog/trunk > pm_unixsyslog CSWpmunixsyslog pkg/cpan/Syslog/trunk > pm_xmllibxmlcom CSWpmxmllibxmlcom pkg/cpan/XML-LibXML/trunk > pm_xmllibxmlcom CSWpmxmllibxmlcom pkg/cpan/XML-LibXML-Common/trunk > Here is the list of the owners : > > evolution_webcal -> Ken Mays (Retired) > evolution_webcal_devel -> Not released > evolution_webcal_doc -> Not released > libsoup2 -> > Roger Hakansson > > pm_cryptcbc -> Dagobert Michelsen I removed the outdated cpan/Crypt-Random and kept cpan/Crypt-CBC. > pm_unixsyslog -> Benny vonMossner I removed the outdated cpan/Syslog and kept cpan/Unix-Syslog. > pm_xmllibxmlcom -> > Benny vonMossner I removed the outdated XML-LibXML-Common and kept cpan/XML-LibXML. > I would like to kinow what is our policy regarding duplicated packages in GAR ? They should not be allowed. Best regards -- Dago From phil at bolthole.com Wed Jan 19 18:48:57 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 19 Jan 2011 09:48:57 -0800 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: References: <1295397496-sup-3624@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/19/11, Maciej (Matchek) Blizinski wrote: > ... The reason I prefer CSWlibmagic-somethingspecific is > that it's more informative. The "-common" suffix suggests that this > is a base package for libmagic, which is fine, but not very > informative. I thought about -magic, because it designates one > specific file that can be later phased out by removing a package - the > same idea that is behind shared libraries. > to me, -common strongly implies that there are multiple functional (user facing) components to a single piece of software, within a single version. If I saw "libmagic", and "libmagic-common", I would be wondering where "libmagic-somethingelse" is, that I may be missing. (-devel doesnt count) If you are looking for something more generic than -magic, there would seem to be multiple other choices. For example, -data seems to be often used elsewhere. libmagic-data seems fairly clear, yet at the same time, somewhat generic and standardized. From bwalton at opencsw.org Wed Jan 19 18:52:10 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 19 Jan 2011 12:52:10 -0500 Subject: [csw-maintainers] When a shared library needs a data file In-Reply-To: References: <1295397496-sup-3624@pinkfloyd.chass.utoronto.ca> Message-ID: <1295459460-sup-9712@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Jan 19 12:48:57 -0500 2011: Hi Phil, > If you are looking for something more generic than -magic, there > would seem to be multiple other choices. For example, -data seems to > be often used elsewhere. libmagic-data seems fairly clear, yet at > the same time, somewhat generic and standardized. I agree that -data is a better choice for this. It's generic but doesn't carry the -common connotations. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Wed Jan 19 19:39:08 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 19 Jan 2011 10:39:08 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> <20110118.10300500.188748523@gyor.oxdrove.co.uk> Message-ID: On 1/18/11, Peter Bonivart wrote: > On Tue, Jan 18, 2011 at 11:30 AM, James Lee wrote: >> But it's already decided. In fact the /var/ issue was previously set >> by the reverse. The previous policy was to support NFS, this already >> implied no /var files via prototypes, so I'm unsure why the issue was >> revisited from the /var end. > > Maybe it implied no files in /var but it sure wasn't enforced, even > pkg-get from Phil himself delivers files to /var. > That's a good point, and something I had completely forgotten. "forgotten about", does not mean "its okay", though I havent made a new release in pkg-get for a long time. Certainly not since any discussions about delivering files under /var. On my next update to it, I intend to fix that issue. Thanks for bringing that problem to my attention. From phil at bolthole.com Wed Jan 19 19:41:12 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 19 Jan 2011 10:41:12 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <20110118.16454200.2833481343@gyor.oxdrove.co.uk> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> <20110118.10300500.188748523@gyor.oxdrove.co.uk> <20110118.16454200.2833481343@gyor.oxdrove.co.uk> Message-ID: On 1/18/11, James Lee wrote: > >> even >> pkg-get from Phil himself delivers files to /var. > > Even Phil could have it wrong. > > [Note, it's /var/pkg-get not /var/opt/csw] > yes.. so if I wanted to be lazy, I could claim, "hey, I'm not going against what was said previously.. I'm not delivering files into /var/opt/csw !" But that would violate the real principle behind the idea of limiting /var/opt/csw: facilitating shared /opt/csw. So I'm not going to play that game. From phil at bolthole.com Wed Jan 19 19:46:38 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 19 Jan 2011 10:46:38 -0800 Subject: [csw-maintainers] [policy] files/dirs in /var/opt/csw In-Reply-To: <1295312551-sup-8728@pinkfloyd.chass.utoronto.ca> References: <1293903086-sup-5326@pinkfloyd.chass.utoronto.ca> <1293979611-sup-4562@pinkfloyd.chass.utoronto.ca> <1294197300-sup-3374@pinkfloyd.chass.utoronto.ca> <1294523567-sup-7416@pinkfloyd.chass.utoronto.ca> <1295011155-sup-1564@pinkfloyd.chass.utoronto.ca> <20110117.11021300.3105295734@gyor.oxdrove.co.uk> <1295312551-sup-8728@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/17/11, Ben Walton wrote: > ... > One of the discussion topics for the winter camp is: Clearly define > the goals of the project which in turn will be used to set package > policy. I imagine that NFS sharing will be brought up as part of > this. The winter camp won't actually be setting new policies > directly[1], but it may spur on the call for voting on various topics. > Thank you for explicitly stating, that winter camp is about discussion, but does not in itself set policy. That being said, I would like to remind people ahead of time for that discussion, that it is not _only_ "NFS sharing" here. There are other cases in play as well. It just happens that we can support all of the other cases, if we just focus on 'lets support the case where /opt/csw is NFS shared'". It's just the easiest method to describe, for discussion purposes. From william at wbonnet.net Wed Jan 19 20:33:31 2011 From: william at wbonnet.net (William Bonnet) Date: Wed, 19 Jan 2011 20:33:31 +0100 Subject: [csw-maintainers] Duplicate packages in GAR In-Reply-To: <4D373C66.1000007@on-x.com> References: <4D33ECF0.5010200@wbonnet.net> <4D373C66.1000007@on-x.com> Message-ID: <4D373C8B.4070306@wbonnet.net> Hi Thanks for removing duplicated stuff > > I would like to kinow what is our policy regarding duplicated packages in GAR ? > They should not be allowed. Ok, i will add this check cheers W. From maciej at opencsw.org Sun Jan 23 17:02:34 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 23 Jan 2011 16:02:34 +0000 Subject: [csw-maintainers] Group registration on Freenode Message-ID: I recently learned (from a podcast) that Freenode does group registrations. It gives better protection of the channel, because it binds our channel with a specific person, authenticated by a GPG key. It also establishes an official OpenCSW presence on Freenode[1]. I've just sent the registration form, and I'm waiting for reply from Freenode admins. [1] http://freenode.net/primary_groups.shtml From jcraig at opencsw.org Sun Jan 23 22:41:40 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Sun, 23 Jan 2011 16:41:40 -0500 Subject: [csw-maintainers] ntop ... In-Reply-To: References: <3ACA07E9-DE64-4147-BF13-E4A686BA8958@opencsw.org> Message-ID: Dago, I'm interested is getting this package updated. If you can pass me what you have so far I'll try to finish the last 10%. Thanks, Jon On Thu, Nov 11, 2010 at 1:09 PM, Dagobert Michelsen wrote: > Hi, > > Am 11.11.2010 um 09:18 schrieb Dagobert Michelsen: >> >> Am 11.11.2010 um 07:03 schrieb Philip Brown: >>> >>> the nice folks at w.l. gore. ?are requesting a newer version of ntop. >>> (they give us a fallback build machine to use) >>> >>> anyone willing to take this on? >> >> Roger took a good shot at 3.3.10 some time ago. Roger: was it >> releasable? Have you submitted the autoconf-changes back >> upstream? >> >> I'll try to bump to 4.0.1 in the meantime. As I vaguely remember >> ntop was pretty hard to build I would really love some help. >> Of course I'll commit often and early. > > I have made the first 90% so it compiles cleanly and made a > package, everything is committed. What is missing now are > the second 90% finetuning the start scripts etc. I won't > have much time to work on this for the next two weeks, so > maybe someone wants to jump in and earn the merits of release? > > > Best regards > > ?-- Dago > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From dam at opencsw.org Mon Jan 24 09:40:51 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 24 Jan 2011 09:40:51 +0100 Subject: [csw-maintainers] ntop ... In-Reply-To: References: <3ACA07E9-DE64-4147-BF13-E4A686BA8958@opencsw.org> Message-ID: <66B79710-D78A-45DE-B157-68C7949EA5FE@opencsw.org> Hi Jon, Am 23.01.2011 um 22:41 schrieb Jonathan Craig: > I'm interested is getting this package updated. If you can pass me > what you have so far I'll try to finish the last 10%. I have everything committed. You may want to look at the existing package for runtime scripts, special user, etc. The binaries should be fine, but mainly anything else is missing. Best regards -- Dago From ihsan at opencsw.org Mon Jan 24 16:21:01 2011 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Mon, 24 Jan 2011 16:21:01 +0100 Subject: [csw-maintainers] mail delay Message-ID: <4D3D98DD.8000309@opencsw.org> Hello, Due broken bayes databases, the mail delivery was disturbed for the last 6 hours. I've restored the database from Sunday and everything is working as expected. There were no mails lost and the queued mails are now delivered. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Mon Jan 24 16:30:02 2011 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Mon, 24 Jan 2011 16:30:02 +0100 Subject: [csw-maintainers] mail delay In-Reply-To: <4D3D98DD.8000309@opencsw.org> References: <4D3D98DD.8000309@opencsw.org> Message-ID: <4D3D9AFA.50907@opencsw.org> On 01/24/11 04:21 PM, ?hsan Do?an wrote: > There were no mails lost and the queued mails are now delivered. I have to correct: Certain e-mails might be delivered twice. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Mon Jan 24 16:34:10 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 24 Jan 2011 15:34:10 +0000 Subject: [csw-maintainers] mail delay In-Reply-To: <4D3D9AFA.50907@opencsw.org> References: <4D3D98DD.8000309@opencsw.org> <4D3D9AFA.50907@opencsw.org> Message-ID: No dia 24 de Janeiro de 2011 15:30, ?hsan Do?an escreveu: > On 01/24/11 04:21 PM, ?hsan Do?an wrote: > >> There were no mails lost and the queued mails are now delivered. > > I have to correct: > Certain e-mails might be delivered twice. This is the better kind of a problem than mails delivered less than once. Thanks for handling it! From phil at bolthole.com Mon Jan 24 23:51:01 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 24 Jan 2011 14:51:01 -0800 Subject: [csw-maintainers] /usr/local references, and packages Message-ID: [changing subject lines, both to be more clear, and also because gmail is very bad sometimes at showing there is new email, in an old thread :( ] On 1/18/11, Ben Walton wrote: > Excerpts from Peter Bonivart's message of Tue Jan 18 18:10:12 -0500 2011: > > Hi Phil, > >> If you think this /usr/local-thing is worthwhile to do something >> about then do so, round up the packages concerned and start a >> project to fix it but stop prolonging the release process, this is >> not an agreed upon standard. > > Peter is right in that you shouldn't enforce a non-existent standard > like this. His suggestion is both good and useful. I'd suggest going > one step further: propose that it become policy and see if everyone > (at least the majority) agrees with you. If so, you've got a reason > to block packages...otherwise you don't. It's easier for everyone. > > I don't think people are disagreeing that removing /usr/local > references is a bad thing, just that they don't like being blocked at > the gate for something that until recently hasn't been an issue. Ben, what you said is incorrect. This is not some "new policy". It has **always** been an issue. From day one. And I have always enforced it, whenever it came to my attention. With the understood exception of "oh this is just documentation examples, so can be ignored". The only thing that has changed, is that now I guess the pre-release examination tools have gotten better at picking it up. Or perhaps more at discriminating between [this is in a doc file, but That is not]. The principle is so glaringly obvious, that it has never needed much explicit "writing up" until now. "When reconfiguring software that defaults to /usr/local, to instead run under /opt/csw, replace all occurrences of '/usr/local' with '/opt/csw' " Claiming that I am enforcing a "non-existent standard", is unfathomable. This is not "new". From maciej at opencsw.org Wed Jan 26 10:35:20 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 26 Jan 2011 09:35:20 +0000 Subject: [csw-maintainers] E-mail notifications on catalog updates Message-ID: I would like there to be a bit of automation which would do the following: - poll a designated location over HTTP (e.g. http://mirror.opencsw.org/opencsw) - download all the catalog files - notice which package have been removed and which have been added (or updated) - when a package removal/addition/upgrade is noticed, it would send an e-mail to the maintainer of that package: "on date and hour such and such, your package such and such (version ...) has been removed/added/updated." The idea is to send the notifications only when the updated package is available externally, meaning that mirror will sync from it, and that the buildfarm can be updated with the new catalog state. It would be very useful when building a chain of dependencies. Does such a thing exist? If not, does anyone have code that does something close to that? From james at opencsw.org Wed Jan 26 11:08:03 2011 From: james at opencsw.org (James Lee) Date: Wed, 26 Jan 2011 10:08:03 GMT Subject: [csw-maintainers] E-mail notifications on catalog updates In-Reply-To: References: Message-ID: <20110126.10080300.737465909@gyor.oxdrove.co.uk> On 26/01/11, 09:35:20, =?UTF-8?Q?Maciej_Blizi=C5=84ski?= wrote regarding [csw-maintainers] E-mail notifications on catalog updates: > - poll a designated location over HTTP (e.g. http://mirror.opencsw.org/opencsw) > - download all the catalog files > - notice which package have been removed and which have been added (or updated) > - when a package removal/addition/upgrade is noticed, it would send an > e-mail to the maintainer of that package: "on date and hour such and > such, your package such and such (version ...) has been > removed/added/updated." > The idea is to send the notifications only when the updated package is > available externally, meaning that mirror will sync from it, and that > the buildfarm can be updated with the new catalog state. It would be > very useful when building a chain of dependencies. > Does such a thing exist? If not, does anyone have code that does > something close to that? I already poll active catalogues and could add email notifications but there exists an RSS feed of all updates that might provide what you want (and more, other people's, which you might not): http://www.canoedissent.org.uk/packages/unstable/sparc/5.10/rss.xml James. From skayser at opencsw.org Wed Jan 26 18:08:48 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 26 Jan 2011 18:08:48 +0100 Subject: [csw-maintainers] E-mail notifications on catalog updates In-Reply-To: References: Message-ID: <20110126170848.GD21610@sebastiankayser.de> * Maciej Blizi??ski wrote: > I would like there to be a bit of automation which would do the following: > > - poll a designated location over HTTP (e.g. http://mirror.opencsw.org/opencsw) > - download all the catalog files > - notice which package have been removed and which have been added (or updated) > - when a package removal/addition/upgrade is noticed, it would send an > e-mail to the maintainer of that package: "on date and hour such and > such, your package such and such (version ...) has been > removed/added/updated." Good idea. Please add to that a notifier when package ownership changes (to the old and the new maintainer). Ideally, with the list of open bugs for the package so to raise awareness for the new maintainer. Jake just took over dovecot (good!) and I only noticed by chance that his new package version was published. Didn't even pop up on pkgsubmissions. Sebastian From bwalton at opencsw.org Thu Jan 27 04:17:52 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 26 Jan 2011 22:17:52 -0500 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: References: Message-ID: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jan 24 17:51:01 -0500 2011: > Ben, what you said is incorrect. This is not some "new policy". It > has **always** been an issue. From day one. And I have always > enforced it, whenever it came to my attention. With the understood > exception of "oh this is just documentation examples, so can be > ignored". Ok, it at least _feels_ new. I don't recall seeing packages rejected for this until very recently. More strictly enforced? I don't disagree that in some cases references to things like /usr/local are bad. I do think that there are cases where it doesn't detract from package quality. > The only thing that has changed, is that now I guess the pre-release > examination tools have gotten better at picking it up. Or perhaps > more at discriminating between [this is in a doc file, but That is > not]. Did you change this recently then? Are you using new tools? > The principle is so glaringly obvious, that it has never needed much > explicit "writing up" until now. "When reconfiguring software that > defaults to /usr/local, to instead run under /opt/csw, replace all > occurrences of '/usr/local' with '/opt/csw' " Claiming that I am > enforcing a "non-existent standard", is unfathomable. This is not > "new". Again, I don't think the point of this is that what you're saying is wrong, although I think you could argue that anything in share/doc is fair game for an exclusion at the maintainers discretion. What I'm hearing is that people perceive this as a 'new rule' whether or not you feel that it's new. In the interest of turning this into productive discussion, lets lay down the ground rules for this. How do people feel about: Files that contain references to /usr/local and are _not_ under /opt/csw/share/doc must have a valid rationale for why they're ok or the package must be altered to remove it. Using the recent perl release as an example, it turned out to be a harmless reference. A note to this effect is, imo, sufficient to make the exception. If we later see /usr/local turn up in other .h files the package could have a packaging bug filed against it and it would be barred from batch until it's fixed or explained. We can vote on this if people disagree with it. Maciej, what is checkpkg doing in this regard currently? Does it check for this string at all? If so, does it check every file or only certain areas? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Jan 27 09:07:16 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 27 Jan 2011 08:07:16 +0000 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> References: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/1/27 Ben Walton : > Maciej, what is checkpkg doing in this regard currently? ?Does it > check for this string at all? ?If so, does it check every file or only > certain areas? When I noticed that packages are rejected because of /usr/local references, I added the "/usr/local" string to the content blacklist. The change was made in r13006[1]. Previously, checkpkg has been checking for /export/medusa and /opt/build. I started working on the version of checkpkg checked into gar tree, updated by comand in revision 1841. Currently, there is no distinction between paths in checkpkg. If a file contains the string, an error is thrown. We could add more logic to alter the behavior depending on whether files with bad content are in docdir or elsewhere, but there are also other options: - if the offending string is found in the doc directory, and the files in question are text/html/xml files, it's safe to sed to replace all paths - if the maintainer does not wish to run sed, the error can be overridden Maciej [1] http://sf.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/package_stats.py?annotate=blame [2] http://sf.net/apps/trac/gar/browser/csw/trunk/bin/checkpkg?rev=1841 From ihsan at opencsw.org Thu Jan 27 13:06:44 2011 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Thu, 27 Jan 2011 13:06:44 +0100 Subject: [csw-maintainers] mail delay In-Reply-To: <4D3D98DD.8000309@opencsw.org> References: <4D3D98DD.8000309@opencsw.org> Message-ID: <4D415FD4.5010209@opencsw.org> On 01/24/11 04:21 PM, ?hsan Do?an wrote: > Due broken bayes databases, the mail delivery was disturbed for the last > 6 hours. I've restored the database from Sunday and everything is > working as expected. Unfortunately I've had again problems with the bayes database. I've cleaned up things again I hope it works now better. Sorry for the delay. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Thu Jan 27 04:17:52 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 26 Jan 2011 22:17:52 -0500 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: References: Message-ID: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jan 24 17:51:01 -0500 2011: > Ben, what you said is incorrect. This is not some "new policy". It > has **always** been an issue. From day one. And I have always > enforced it, whenever it came to my attention. With the understood > exception of "oh this is just documentation examples, so can be > ignored". Ok, it at least _feels_ new. I don't recall seeing packages rejected for this until very recently. More strictly enforced? I don't disagree that in some cases references to things like /usr/local are bad. I do think that there are cases where it doesn't detract from package quality. > The only thing that has changed, is that now I guess the pre-release > examination tools have gotten better at picking it up. Or perhaps > more at discriminating between [this is in a doc file, but That is > not]. Did you change this recently then? Are you using new tools? > The principle is so glaringly obvious, that it has never needed much > explicit "writing up" until now. "When reconfiguring software that > defaults to /usr/local, to instead run under /opt/csw, replace all > occurrences of '/usr/local' with '/opt/csw' " Claiming that I am > enforcing a "non-existent standard", is unfathomable. This is not > "new". Again, I don't think the point of this is that what you're saying is wrong, although I think you could argue that anything in share/doc is fair game for an exclusion at the maintainers discretion. What I'm hearing is that people perceive this as a 'new rule' whether or not you feel that it's new. In the interest of turning this into productive discussion, lets lay down the ground rules for this. How do people feel about: Files that contain references to /usr/local and are _not_ under /opt/csw/share/doc must have a valid rationale for why they're ok or the package must be altered to remove it. Using the recent perl release as an example, it turned out to be a harmless reference. A note to this effect is, imo, sufficient to make the exception. If we later see /usr/local turn up in other .h files the package could have a packaging bug filed against it and it would be barred from batch until it's fixed or explained. We can vote on this if people disagree with it. Maciej, what is checkpkg doing in this regard currently? Does it check for this string at all? If so, does it check every file or only certain areas? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From skayser at opencsw.org Wed Jan 26 18:08:48 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 26 Jan 2011 18:08:48 +0100 Subject: [csw-maintainers] E-mail notifications on catalog updates In-Reply-To: References: Message-ID: <20110126170848.GD21610@sebastiankayser.de> * Maciej Blizi??ski wrote: > I would like there to be a bit of automation which would do the following: > > - poll a designated location over HTTP (e.g. http://mirror.opencsw.org/opencsw) > - download all the catalog files > - notice which package have been removed and which have been added (or updated) > - when a package removal/addition/upgrade is noticed, it would send an > e-mail to the maintainer of that package: "on date and hour such and > such, your package such and such (version ...) has been > removed/added/updated." Good idea. Please add to that a notifier when package ownership changes (to the old and the new maintainer). Ideally, with the list of open bugs for the package so to raise awareness for the new maintainer. Jake just took over dovecot (good!) and I only noticed by chance that his new package version was published. Didn't even pop up on pkgsubmissions. Sebastian From skayser at opencsw.org Wed Jan 26 22:55:30 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 26 Jan 2011 22:55:30 +0100 Subject: [csw-maintainers] GAR wiki feedback footer Message-ID: <20110126215530.GE21610@sebastiankayser.de> Hi, our GAR wiki was missing contact information for feedback purposes up until now. I just included a footer on the front page [1,2] which tells people where they can turn to (in particular beginners might have valuable thoughts). What do you think? I'd like to roll it out to all pages on the GAR wiki and while doing so go over the page contents too. Sebastian [1] https://sourceforge.net/apps/trac/gar/wiki [2] http://sourceforge.net/apps/trac/gar/wiki/FeedbackFooter From bwalton at opencsw.org Thu Jan 27 14:04:11 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 27 Jan 2011 08:04:11 -0500 Subject: [csw-maintainers] GAR wiki feedback footer In-Reply-To: <20110126215530.GE21610@sebastiankayser.de> References: <20110126215530.GE21610@sebastiankayser.de> Message-ID: <28757e3c-6a23-4690-9626-b6e511c364d3@email.android.com> Hi Sebastian, I think this is a nice addition. It requires a sourceforge login to use though...not a deal breaker in my eyes, but it may deter some people... Thanks -Ben Thanks -Ben From opk at opencsw.org Thu Jan 27 14:44:15 2011 From: opk at opencsw.org (Oliver Kiddle) Date: Thu, 27 Jan 2011 14:44:15 +0100 Subject: [csw-maintainers] gar problem building zsh Message-ID: <10830.1296135855@thecus> I get the following error building zsh in gar: /bin/sh: syntax error at line 3: `;' unexpected This is coming from this line in gar.lib.mk: ( for i in $(filter %/$*,$(URLS)); do \ URLS does not contain anything matching %/CSWzsh.gspec so the for loop is being passed an empty list. Any idea what broke this and how to fix it. I'd like to update zsh to 4.3.11. Oliver From skayser at opencsw.org Thu Jan 27 15:25:46 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 27 Jan 2011 15:25:46 +0100 Subject: [csw-maintainers] GAR wiki feedback footer In-Reply-To: <28757e3c-6a23-4690-9626-b6e511c364d3@email.android.com> References: <20110126215530.GE21610@sebastiankayser.de> <28757e3c-6a23-4690-9626-b6e511c364d3@email.android.com> Message-ID: <20110127142546.GF21610@sebastiankayser.de> * Ben Walton wrote: > I think this is a nice addition. It requires a sourceforge login to use though...not a deal breaker in my eyes, but it may deter some people... True, I thought the same. Where would you direct feedback to? Sebastian From skayser at opencsw.org Thu Jan 27 15:30:25 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 27 Jan 2011 15:30:25 +0100 Subject: [csw-maintainers] gar problem building zsh In-Reply-To: <10830.1296135855@thecus> References: <10830.1296135855@thecus> Message-ID: <20110127143025.GG21610@sebastiankayser.de> * Oliver Kiddle wrote: > I get the following error building zsh in gar: > /bin/sh: syntax error at line 3: `;' unexpected > > This is coming from this line in gar.lib.mk: > ( for i in $(filter %/$*,$(URLS)); do \ > URLS does not contain anything matching %/CSWzsh.gspec so the for loop > is being passed an empty list. > > Any idea what broke this and how to fix it. I'd like to update zsh > to 4.3.11. Have you been building with SHELL=/bin/sh all the time? The empty list shouldn't pose a problem for bash. Sebastian From bwalton at opencsw.org Thu Jan 27 16:22:25 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 27 Jan 2011 10:22:25 -0500 Subject: [csw-maintainers] GAR wiki feedback footer In-Reply-To: <20110127142546.GF21610@sebastiankayser.de> References: <20110126215530.GE21610@sebastiankayser.de> <28757e3c-6a23-4690-9626-b6e511c364d3@email.android.com> <20110127142546.GF21610@sebastiankayser.de> Message-ID: <1296141666-sup-5724@pinkfloyd.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Thu Jan 27 09:25:46 -0500 2011: > * Ben Walton wrote: > I think this is a nice > addition. It requires a sourceforge login to use though...not a > deal breaker in my eyes, but it may deter some people... > > True, I thought the same. Where would you direct feedback to? I don't have a better idea and I'm personally ok with the requirement. It's a spam barrier and really, anyone that is developing with GAR and wants to file a bug most likely won't mind the impediment either. If they do and they are bothered enough to file a bug, they'll find us via other means. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Thu Jan 27 16:24:27 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 27 Jan 2011 16:24:27 +0100 Subject: [csw-maintainers] gar problem building zsh In-Reply-To: <10830.1296135855@thecus> References: <10830.1296135855@thecus> Message-ID: <3DFAA12B-3E4D-42B8-9BDC-9DF8167B9968@opencsw.org> Hi Oliver, Am 27.01.2011 um 14:44 schrieb Oliver Kiddle: > I get the following error building zsh in gar: > /bin/sh: syntax error at line 3: `;' unexpected > > This is coming from this line in gar.lib.mk: > ( for i in $(filter %/$*,$(URLS)); do \ > URLS does not contain anything matching %/CSWzsh.gspec so the for loop > is being passed an empty list. > > Any idea what broke this and how to fix it. I'd like to update zsh > to 4.3.11. I just compiled pkg/zsh/trunk from the repository and it works fine. Do you have any local modifications? I would like to reproduce the problem so I can fix it. Btw, I removed CSWzsh.gspec as static gspecs are no longer supported in GAR, also I added _pkgutil to DISTFILES, this will be necessary when we make source packages in the future among some minor tweaks. Best regards -- Dago From maciej at opencsw.org Thu Jan 27 17:10:58 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 27 Jan 2011 16:10:58 +0000 Subject: [csw-maintainers] GAR wiki feedback footer In-Reply-To: <1296141666-sup-5724@pinkfloyd.chass.utoronto.ca> References: <20110126215530.GE21610@sebastiankayser.de> <28757e3c-6a23-4690-9626-b6e511c364d3@email.android.com> <20110127142546.GF21610@sebastiankayser.de> <1296141666-sup-5724@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/1/27 Ben Walton : > Excerpts from Sebastian Kayser's message of Thu Jan 27 09:25:46 -0500 2011: > >> * Ben Walton wrote: > I think this is a nice >> addition. ?It requires a sourceforge login to use though...not a >> deal breaker in my eyes, but it may deter some people... >> >> True, I thought the same. Where would you direct feedback to? > > I don't have a better idea and I'm personally ok with the > requirement. The footer could announce that you need to be logged into SourceForge in order to leave feedback. From skayser at opencsw.org Thu Jan 27 17:24:07 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 27 Jan 2011 17:24:07 +0100 Subject: [csw-maintainers] GAR wiki feedback footer In-Reply-To: References: <20110126215530.GE21610@sebastiankayser.de> <28757e3c-6a23-4690-9626-b6e511c364d3@email.android.com> <20110127142546.GF21610@sebastiankayser.de> <1296141666-sup-5724@pinkfloyd.chass.utoronto.ca> Message-ID: <20110127162407.GH21610@sebastiankayser.de> * Maciej Blizi??ski wrote: > 2011/1/27 Ben Walton : > > Excerpts from Sebastian Kayser's message of Thu Jan 27 09:25:46 -0500 2011: > > > >> * Ben Walton wrote: > I think this is a nice > >> addition. ?It requires a sourceforge login to use though...not a > >> deal breaker in my eyes, but it may deter some people... > >> > >> True, I thought the same. Where would you direct feedback to? > > > > I don't have a better idea and I'm personally ok with the > > requirement. > > The footer could announce that you need to be logged into SourceForge > in order to leave feedback. Righteo, thanks! Added. Sebastian From phil at bolthole.com Thu Jan 27 20:17:23 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 27 Jan 2011 11:17:23 -0800 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> References: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Jan 26, 2011 at 7:17 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Jan 24 17:51:01 -0500 2011: > >> Ben, what you said is incorrect. This is not some "new policy". ?It >> has **always** been an issue. From day one. And I have always >> enforced it, whenever it came to my attention. ?With the understood >> exception of "oh this is just documentation examples, so can be >> ignored". > > Ok, it at least _feels_ new. ?I don't recall seeing packages rejected > for this until very recently. ?More strictly enforced? If one were to analyze the packages submitted in the last 6 months (SUBMITTED, not only accepted), one might find an odd peak in the frequency of things containing /usr/local in the last month or so. Dont know why, it just happens sometimes >> The only thing that has changed, is that now I guess the pre-release >> examination tools have gotten better at picking it up. Or perhaps >> more at discriminating between [this is in a doc file, but That is >> not]. > > Did you change this recently then? ?Are you using new tools? The only real change I made in my (cswutils version) checkpkg, was by maintainer request; to have it call out which files have /usr/local in them. However, it still detects "does this package have /usr/local in it?" the exact same way it's been doing for quite a few years now. > Again, I don't think the point of this is that what you're saying is > wrong, although I think you could argue that anything in share/doc is > fair game for an exclusion at the maintainers discretion. ?What I'm > hearing is that people perceive this as a 'new rule' whether or not > you feel that it's new. This should not be about "feelings". It is really inappropriate to say, "well, some people *feel* like this is new, so even though facts say it's not new at all, lets ignore facts and go with peoples *feelings*" This goes back to blastwave days, for goodness's sake. > Using the recent perl release as an example, it turned out to be a > harmless reference. but it isnt "harmless". its just "very very rarely used". If someone were to actually use that functionality, it would be fatal to the compile(I think), if no change was made. That is not "harmless". From bwalton at opencsw.org Fri Jan 28 02:19:25 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 27 Jan 2011 20:19:25 -0500 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: References: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> Message-ID: <1296176778-sup-6893@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Jan 27 14:17:23 -0500 2011: > > Ok, it at least _feels_ new. ?I don't recall seeing packages > > rejected for this until very recently. ?More strictly enforced? > > > If one were to analyze the packages submitted in the last 6 months > (SUBMITTED, not only accepted), one might find an odd peak in the > frequency of things containing /usr/local in the last month or so. > Dont know why, it just happens sometimes Well, this indicates a problem in the way the release process is currently operating then, even when looking at this 6 month window. The original 5.10 release wasn't flagged for this but you indicate the tools have not changed. This means that your process is not being applied routinely. > > Again, I don't think the point of this is that what you're saying > > is wrong, although I think you could argue that anything in > > share/doc is fair game for an exclusion at the maintainers > > discretion. ?What I'm hearing is that people perceive this as a > > 'new rule' whether or not you feel that it's new. > > This should not be about "feelings". It is really inappropriate to > say, "well, some people *feel* like this is new, so even though > facts say it's not new at all, lets ignore facts and go with peoples > *feelings*" Well, the facts aren't solid either, but that aside... If a large enough number of people are being hit by this and wondering why packages are being rejected, then there is a problem. Lets fix the problem. Things to fix: 1. This check needs to be applied to every package, every time, consistently. That's not happening now or the original 5.10 release would have been snagged too...and the 5.8 before that, etc. 2. Maintainers need to understand what the policy is. If someone like Peter who's been around for a long time is being caught off guard by this, the policy is not understood widely enough. Again, I'm not arguing that blocking things with /usr/local is wrong. I'm just saying that it needs to be fully qualified. You mentioned that "it's so completely obvious it hasn't needed definition," so that should mean it's very simple to lay down the policy, including things that are valid exceptions. Please do and then let maintainers comment on it. Revise if necessary. My hunch is that you won't need to, but let's see. We can vote on it if there is enough variance in opinion. At the end of the day, this makes _your_ life easier. > but it isnt "harmless". its just "very very rarely used". If > someone were to actually use that functionality, it would be fatal > to the compile(I think), if no change was made. That is not > "harmless". No, it is harmless. Go read the docs in the perl distribution. It's not something that is accidentally going to C++ your leg. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Jan 28 02:27:43 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 27 Jan 2011 20:27:43 -0500 Subject: [csw-maintainers] policy discussions Message-ID: <1296177816-sup-2919@pinkfloyd.chass.utoronto.ca> Hi All, Sorry to be so tardy with a follow-up to this discussion... Going forward, please prefix the subject line of any discussion about OpenCSW policy with [policy] so that it's easily search-able visible in the inboxes of those that received it. It should be directed to maintainers@ just like this message. The board is in full agreement that discussing policy in the open is acceptable. If this needs to change for some future reason, a separate list will be created at that point. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Jan 28 05:14:21 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 27 Jan 2011 20:14:21 -0800 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: <1296176778-sup-6893@pinkfloyd.chass.utoronto.ca> References: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> <1296176778-sup-6893@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Jan 27, 2011 at 5:19 PM, Ben Walton wrote: > >> >> If one were to analyze the packages submitted in the last 6 months >> (SUBMITTED, not only accepted), one might find an odd peak in the >> frequency of things containing /usr/local in the last month or so. >> Dont know why, it just happens sometimes > > Well, this indicates a problem in the way the release process is > currently operating then, even when looking at this 6 month window. > The original 5.10 release wasn't flagged for this but you indicate the > tools have not changed. ?This means that your process is not being > applied routinely. Yes. I have to apologise for this. Sometimes I make the "mistake" of "trusting maintainers" :-} Bad release manager, bad! I need to stop doing that! :-D I did not apply checkpkg and pore over the results for that release. If memory serves, it was released as part of a mass dump of packages. I did not have the time to peruse the output fully for checkpkg for all the packages. But Peter said he had done a lot of checking on it, and I think Dago and someone else had been assisting, so I thought "okay, multiple eyes have been on it, I dont know much about perl, so I'll just pass it through". For that sort of reason, I usually have left the perl package without deep scrutiny. Particularly since there are a mess of non-critical "/usr/local" flags in it. But, now that the tool lets me more easily separate ignorable warnings, from potentially more important ones, I took a closer look. From opk at opencsw.org Fri Jan 28 11:13:29 2011 From: opk at opencsw.org (Oliver Kiddle) Date: Fri, 28 Jan 2011 11:13:29 +0100 Subject: [csw-maintainers] gar problem building zsh In-Reply-To: <20110127143025.GG21610@sebastiankayser.de> References: <10830.1296135855@thecus> <20110127143025.GG21610@sebastiankayser.de> Message-ID: <14256.1296209609@thecus> Sebastian Kayser wrote: > Have you been building with SHELL=/bin/sh all the time? The empty list > shouldn't pose a problem for bash. I have the SHELL environment variable set to /bin/zsh. Normally make ignores the setting of SHELL in the environment and uses /bin/sh. Is that not the case for gar? If so, that would seem a bit broken. Thanks. Also, thanks to Dago for his improvements to the zsh package Makefile. Oliver From maciej at opencsw.org Fri Jan 28 13:00:46 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 28 Jan 2011 12:00:46 +0000 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: References: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> <1296176778-sup-6893@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/1/28 Philip Brown : > (...) now that the tool lets me more easily separate ignorable > warnings (...) Is the tool visible to maintainers? Is it possible for maintainers to track changes made to it? From phil at bolthole.com Fri Jan 28 17:32:47 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 28 Jan 2011 08:32:47 -0800 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: References: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> <1296176778-sup-6893@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/28/11, Maciej Blizi?ski wrote: > 2011/1/28 Philip Brown : >> (...) now that the tool lets me more easily separate ignorable >> warnings (...) > > Is the tool visible to maintainers? Is it possible for maintainers to > track changes made to it? > As mentioned earlier in the thread, I use my checkpkg. which is part of cswutils. From maciej at opencsw.org Fri Jan 28 17:37:32 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 28 Jan 2011 16:37:32 +0000 Subject: [csw-maintainers] E-mail notifications on catalog updates In-Reply-To: <20110126170848.GD21610@sebastiankayser.de> References: <20110126170848.GD21610@sebastiankayser.de> Message-ID: 2011/1/26 Sebastian Kayser : > Good idea. Please add to that a notifier when package ownership changes > (to the old and the new maintainer). Ideally, with the list of open bugs > for the package so to raise awareness for the new maintainer. Speaking about the list of open bugs - in order to do that, we'd need some sort of interface to poll mantis. Does anything like it exist already? I remember that it had some sort of XMLRPC interface. Can you give me any pointers? > Jake just took over dovecot (good!) and I only noticed by chance that > his new package version was published. Didn't even pop up on > pkgsubmissions. Perhaps the devel@ mailing list could receive global summaries? (for all packages) From maciej at opencsw.org Fri Jan 28 17:44:00 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 28 Jan 2011 16:44:00 +0000 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: References: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> <1296176778-sup-6893@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/1/28 Philip Brown : > On 1/28/11, Maciej Blizi?ski wrote: >> 2011/1/28 Philip Brown : >>> (...) now that the tool lets me more easily separate ignorable >>> warnings (...) >> >> Is the tool visible to maintainers? ?Is it possible for maintainers to >> track changes made to it? >> > > As mentioned earlier in the thread, I use my checkpkg. which is part > of cswutils. Alright, so the change introducing /usr/local checks was made 7 months ago in r10400. For those interested in changes to it, our trac offers a revision history view at [2]. [1] http://sourceforge.net/apps/trac/gar/changeset/10400/csw/mgar/pkg/cswutils/trunk/files/checkpkg [2] http://sourceforge.net/apps/trac/gar/log/csw/mgar/pkg/cswutils/trunk/files/checkpkg From phil at bolthole.com Fri Jan 28 18:00:43 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 28 Jan 2011 09:00:43 -0800 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: References: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> <1296176778-sup-6893@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/28/11, Maciej Blizi?ski wrote: > > Alright, so the change introducing /usr/local checks was made 7 months > ago in r10400. Correction: it was checked in, 7 months ago. I was using a local copy for quite a long while. From maciej at opencsw.org Sat Jan 29 08:56:40 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 29 Jan 2011 07:56:40 +0000 Subject: [csw-maintainers] SourceForge resets all passwords after an attack Message-ID: https://sourceforge.net/blog/sourceforge-net-global-password-reset/ "We recently experienced a directed attack on SourceForge infrastructure (http://sourceforge.net/blog/sourceforge-net-attack/) and so we are resetting all passwords in the sf.net database ? just in case." "(...) So, we?ve invalidated all sourceforge.net account passwords, and to access the site again, everyone will need to go through the email recovery process and choose a shiny new password: https://sourceforge.net/account/registration/recover.php " Maciej From bwalton at opencsw.org Sat Jan 29 14:25:53 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 29 Jan 2011 08:25:53 -0500 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: References: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> <1296176778-sup-6893@pinkfloyd.chass.utoronto.ca> Message-ID: <1296307303-sup-4973@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Jan 28 12:00:43 -0500 2011: > > Alright, so the change introducing /usr/local checks was made 7 months > > ago in r10400. > > Correction: it was checked in, 7 months ago. > I was using a local copy for quite a long while. A few points on this: 1. The commit of this changes seems to coincide with the uptick of blocked packages for this issue. 2. You should not be subjecting packages to checks with tools that are not fully visible to all maintainers. In the future, please commit (to a public opencsw repo) any change to any script you use prior to blocking a package based on said change. You're welcome to test changes locally, but this should not impede the release of anything before it's public 3. Any reason you've not adopted Maciej's checkpkg? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jan 31 02:06:18 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 30 Jan 2011 20:06:18 -0500 Subject: [csw-maintainers] [ITP] gdb 7.2 In-Reply-To: References: <1294407750-sup-7734@pinkfloyd.chass.utoronto.ca> <881332CF-A1CC-4B28-B191-14D854265DBD@opencsw.org> Message-ID: <1296435919-sup-8729@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Mon Jan 10 06:18:23 -0500 2011: Hi Peter, > Here are the patches, to apply on the 0.18.1 release of gettext, and the > report that I made to the upstream project > http://savannah.gnu.org/bugs/?32087 > > Summary: libpthread linkage detection on Solaris > Project: GNU gettext > Submitted by: pfelecan > Submitted on: Mon 10 Jan 2011 11:31:30 AM CET > Category: None > Severity: 3 - Normal > Item Group: None > Status: None > Privacy: Public > Assigned to: None > Open/Closed: Open > Discussion Lock: Any > > _______________________________________________________ > I've cleaned up the gettext package to the point where I'm now going to integrate these patches. Thanks for providing them. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Jan 31 19:00:32 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 31 Jan 2011 10:00:32 -0800 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: <1296307303-sup-4973@pinkfloyd.chass.utoronto.ca> References: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> <1296176778-sup-6893@pinkfloyd.chass.utoronto.ca> <1296307303-sup-4973@pinkfloyd.chass.utoronto.ca> Message-ID: On 1/29/11, Ben Walton wrote: > > 3. Any reason you've not adopted Maciej's checkpkg? multiple. - It's good to have multiple methods of checking for packages issues, when "what we are checking for" is agreed upon between the two methods (and it is); in case there's a bug in one method, the other way might catch an issue. - I dont speak python. So when I need to add bender-specific customizations, or experiment with new checks (such as, "go look at the local pre-released catalog for cross-checking"), it's easier for me to do so in the more widespread language of sh) From phil at bolthole.com Mon Jan 31 19:03:54 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 31 Jan 2011 10:03:54 -0800 Subject: [csw-maintainers] /usr/local references, and packages In-Reply-To: <1296307303-sup-4973@pinkfloyd.chass.utoronto.ca> References: <1296079091-sup-6070@pinkfloyd.chass.utoronto.ca> <1296176778-sup-6893@pinkfloyd.chass.utoronto.ca> <1296307303-sup-4973@pinkfloyd.chass.utoronto.ca> Message-ID: PS: On 1/29/11, Ben Walton wrote: > > A few points on this: > > 1. The commit of this changes seems to coincide with the uptick of > blocked packages for this issue. I may have misremembered the timing of the automated check on this. The principle was always there, but the automated check may have been only implemented around then