From william at wbonnet.net Tue Feb 1 00:22:36 2011 From: william at wbonnet.net (William Bonnet) Date: Tue, 01 Feb 2011 00:22:36 +0100 Subject: [csw-maintainers] Introducing the QA pages mockup Message-ID: <4D47443C.8060401@wbonnet.net> Hi, Over the last weeks some work has been done to create prototypes of QA pages. These pages are aimed to be available publicly from our web site. Even if during development stage, they are only accessible from the mockup site ( http://www-mockup.opencsw.org ). QA pages will display both summaries and detailed information for maintainers and packages, such as number of opened issues in mantis, available upstream version, checkpkg results, automatic build results, etc. Current set of pages display the following : . List of orphaned packages : http://www-mockup.opencsw.org/qa/packages/orphaned . List of retired maintainers still owing packages : http://www-mockup.opencsw.org/qa/maintainers/retired . Detailed information about a maintainer : http://www-mockup.opencsw.org/qa/maintainer/YOURLOGIN (example : http://www-mockup.opencsw.org/qa/maintainer/wbonnet ) . Detailed information about a package : http://www-mockup.opencsw.org/qa/package/CATALOGNAME (example : http://www-mockup.opencsw.org/qa/package/firefox ) Please note that these pages are still drafts. The first three ones are close to be finished. I still have a few comments from the first set of tester to take in account. The last one is in its very very early stage. I choose to make it public for maintainers since it carries information about uWatch configuration that might be helpful for some of you. But please don't treat this one as a possible release candidate. It's really alpha. I would like to submit these pages to your review, critics, comments, and everything :) The QA pages will be discussed during the coming winter camp, and some hacking sessions will focus on improving these pages. Since only a few of us will be in Dublin, i'm pushing the pages towards you all now. So you will have some time to make some feedbacks before the camp and push new requirements. Anyways the page will not be frozen during the camp ! But the sooner the review comes, the better it is. QA pages are using a database backend. It is feed by catalog updates (automatically processed every day) and by uWatch (automatically looking for upstream version every day). On the mockup web server the catalog processing is enabled daily, but uWatch are pushed manually several time per week (time for me to merge uwatch2 branch to gar v2 trunk). The two summaries pages will help us all to track orphaned packages. Actually there are 593 packages. A large part of these packages are kde, perl and php stuff. Hopefully our Perl maintainers are very active. It's not the same for php nor kde. The maintainer page will help each of us to have a simple access to the list of things to be done for each package. The first columns display the number of bugs per severity for each package. The second set of colums displays version information. Version under stable testing and unstable will appear in different cells if they are different, or in a merged cell if they are the same in the different catalog. GAR and upstream version will be merged if they are the same. A gar version is bold if it can be released to upgrade unstable catalog. Lutefisk, uBuild and checkpkg are not yet activated. Feedbacks comments ands new requirements are welcome :) A wiki page is setup here : http://wiki.opencsw.org/qa-pages-comments Cheers W. PS : The number of orphaned packages are different on both summaries pages because in the database there exist a ghost maintainer called "No maintainer" which owns one package... It will be fixed soon :) PS2: CSS are broken in some cases. They will be fixed once page will be a bit more stable... -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From phil at bolthole.com Tue Feb 1 00:59:00 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 31 Jan 2011 15:59:00 -0800 Subject: [csw-maintainers] Introducing the QA pages mockup In-Reply-To: <4D47443C.8060401@wbonnet.net> References: <4D47443C.8060401@wbonnet.net> Message-ID: On 1/31/11, William Bonnet wrote: > > . List of orphaned packages : > http://www-mockup.opencsw.org/qa/packages/orphaned >>... Looks very nice! only thing I might suggest, is a one liner at the top of that page, explaining something like, "orphaned packages, are packages whose maintainer has retired. The maintainer may or may not be available to answer questions about it". From bwalton at opencsw.org Tue Feb 1 02:35:07 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 31 Jan 2011 20:35:07 -0500 Subject: [csw-maintainers] sourceforge attack Message-ID: <1296524068-sup-9512@pinkfloyd.chass.utoronto.ca> Hi All, For those interested, SF.net has posted full disclosure report of the recent attack: http://sourceforge.net/blog/sourceforge-attack-full-report/ Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From Joerg.Schilling at fokus.fraunhofer.de Tue Feb 1 10:41:39 2011 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 01 Feb 2011 10:41:39 +0100 Subject: [csw-maintainers] sourceforge attack In-Reply-To: <1296524068-sup-9512@pinkfloyd.chass.utoronto.ca> References: <1296524068-sup-9512@pinkfloyd.chass.utoronto.ca> Message-ID: <4d47d553.sYxpB2XMYu031RWr%Joerg.Schilling@fokus.fraunhofer.de> Ben Walton wrote: > For those interested, SF.net has posted full disclosure report of the > recent attack: > http://sourceforge.net/blog/sourceforge-attack-full-report/ They do not explain how the attack could be successful, so this is not a real help for users but a PR action to quiet down users. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From phil at bolthole.com Tue Feb 1 19:56:37 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 1 Feb 2011 10:56:37 -0800 Subject: [csw-maintainers] Anyone like to use graphics proggies? (gimp) Message-ID: Hi folks, Our current gimp was compiled by me. It was really mostly a quickie "do our new gtk libs work" test. I'm not a regular user of the thing. As such, is anyone willing to take it over and compile the latest? We have an "upgrade" request, and I dont really have time to deal with it properly at the moment. From jeff at cjsa.com Wed Feb 2 02:04:26 2011 From: jeff at cjsa.com (Jeffery Small) Date: Wed, 2 Feb 2011 01:04:26 GMT Subject: [csw-maintainers] Anyone like to use graphics proggies? (gimp) References: Message-ID: Philip Brown writes: >Hi folks, >Our current gimp was compiled by me. It was really mostly a quickie >"do our new gtk libs work" test. I'm not a regular user of the thing. >As such, is anyone willing to take it over and compile the latest? >We have an "upgrade" request, and I dont really have time to deal with >it properly at the moment. Unfortunately, I don't have the time to take over this. However, if anyone else does work on recompiling this, please take a look at any optimization that can be performed. The current 2.6.8 version is quite a bit slower in many operations than the previous 2.4 version. But the real killer is with the Color->Curves command. It take around 20 seconds for the Adjust Color Curves menu to display the first time on my SPARC V250 and takes around 8-10 seconds to display after that. After adjusting the curves, it again take 20+ seconds to apply the adjustment to a small photograph. This is probably five times slower than the previous version of the program and this is really slowing down editing work dramatically. There is something seriously wrong here that might be able to be isolated if monitored in a debugger. Long ago I posted info. regarding this on gimp forums/mailing lists asking for experience by others and tips for optimization, but received no useful replies. It doesn't look like there are many Solaris users who are willing to share their experience. I also tried to contact Ken Mays, the previous maintainer, but heard nothing back from him. Regards, -- Jeff jeff at cjsa.com From phil at bolthole.com Wed Feb 2 03:52:31 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 1 Feb 2011 18:52:31 -0800 Subject: [csw-maintainers] Anyone like to use graphics proggies? (gimp) In-Reply-To: References: Message-ID: if the problem is time for menus to appear, it is likely the optimization levels of the gtk libraries, etc rather than Gimp itself. but that's not definite. On Tuesday, February 1, 2011, Jeffery Small wrote: > Philip Brown writes: > >>Hi folks, > >>Our current gimp was compiled by me. It was really mostly a quickie >>"do our new gtk libs work" test. I'm not a regular user of the thing. >>As such, is anyone willing to take it over and compile the latest? > >>We have an "upgrade" request, and I dont really have time to deal with >>it properly at the moment. > > Unfortunately, I don't have the time to take over this. ?However, if anyone > else does work on recompiling this, please take a look at any optimization > that can be performed. ?The current 2.6.8 version is quite a bit slower in > many operations than the previous 2.4 version. ?But the real killer is with > the Color->Curves command. ?It take around 20 seconds for the Adjust Color > Curves menu to display the first time on my SPARC V250 and takes around > 8-10 seconds to display after that. ?After adjusting the curves, it again > take 20+ seconds to apply the adjustment to a small photograph. ?This is > probably five times slower than the previous version of the program and > this is really slowing down editing work dramatically. ?There is something > seriously wrong here that might be able to be isolated if monitored in a > debugger. > > Long ago I posted info. regarding this on gimp forums/mailing lists asking > for experience by others and tips for optimization, but received no useful > replies. ?It doesn't look like there are many Solaris users who are willing > to share their experience. ?I also tried to contact Ken Mays, the previous > maintainer, but heard nothing back from him. > > Regards, > -- > Jeff > > jeff at cjsa.com > > _______________________________________________ > 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 Wed Feb 2 08:25:42 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Feb 2011 08:25:42 +0100 Subject: [csw-maintainers] Anyone like to use graphics proggies? (gimp) In-Reply-To: References: Message-ID: <60288847-C871-4AF2-9CF6-04A803771AD1@opencsw.org> Hi, Am 01.02.2011 um 19:56 schrieb Philip Brown: > Our current gimp was compiled by me. It was really mostly a quickie > "do our new gtk libs work" test. I'm not a regular user of the thing. > As such, is anyone willing to take it over and compile the latest? > > We have an "upgrade" request, and I dont really have time to deal with > it properly at the moment. Roger, it would also be cool if we could release imagemagick64. Is there something missing? Best regards -- Dago From maciej at opencsw.org Wed Feb 2 18:59:54 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 2 Feb 2011 17:59:54 +0000 Subject: [csw-maintainers] Mirror update notifications Message-ID: Hello maintainers, Do you remember the times when you sent an e-mail to the buildfarm admins asking to install a package, and the response was that the package is not yet available for installation? There has been historically an issue that we never knew when our released packages hit the mirror[1]. It was a typical scenario when building a chain of dependencies, that after a package has been accepted, we had to keep on manually checking the mirror and searching through the catalog file to find out whether our package is already available to the world - and the buildfarm. I've automated this. I've set up a script, which periodically polls the mirror over HTTP and sends notifications when there are package updates. The two typical cases are packages added and packages updated. There are also the cases of package takeovers and deletions. In the case of takeovers, both the former and the new package maintainer get a notification. As usual, notifier's source code[2] is available for the curious. When you can expect notifications? That depends on the times the catalog is pushed, and cron. The latter runs four times a day in regular intervals. What does notification look like? The subject line is: "OpenCSW catalog update report". The body contains the list of package files and catalogs that contain them. Feedback is welcome! Maciej [1] http://mirror.opencsw.org/opencsw/ [2] http://sf.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/catalog_notifier.py http://sf.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/catalog.py From james at opencsw.org Wed Feb 2 19:54:50 2011 From: james at opencsw.org (James Lee) Date: Wed, 02 Feb 2011 18:54:50 GMT Subject: [csw-maintainers] Mirror update notifications In-Reply-To: References: Message-ID: <20110202.18545000.997843832@gyor.oxdrove.co.uk> On 02/02/11, 17:59:54, =?UTF-8?Q?Maciej_Blizi=C5=84ski?= wrote regarding [csw-maintainers] Mirror update notifications: > There has been historically an issue that we never knew when our > released packages hit the mirror[1]. It was a typical scenario when > building a chain of dependencies, that after a package has been > accepted, we had to keep on manually checking the mirror and searching > through the catalog file to find out whether our package is already > available to the world - and the buildfarm. No, just set -I and -L appropriately. James. From bwalton at opencsw.org Thu Feb 3 03:10:02 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 02 Feb 2011 21:10:02 -0500 Subject: [csw-maintainers] Aliased names vs dummy packages [Was [csw-pkgsubmissions] newpkgs py_webpy] Message-ID: <1296698900-sup-2331@pinkfloyd.chass.utoronto.ca> Moving this existing discussion to maintainers@ so people not following pkgsubmissions can chime in... --- Begin forwarded message from Philip Brown --- From: Philip Brown To: pkgsubmissions Date: Mon, 24 Jan 2011 09:14:49 -0500 Subject: Re: [csw-pkgsubmissions] newpkgs py_webpy On Sun, Jan 23, 2011 at 8:09 PM, Philip Brown wrote: > On Sun, Jan 23, 2011 at 8:04 PM, Ben Walton wrote: >... >> My point here is that if you want both naming consistency (good) and >> installation by friendly name (also good), you can have that by >> packaging under the standardized format and providing stub packages >> with the friendly name. ?I don't see a problem with stub packages but >> I do see a gain from using them where appropriate. ?To my eye, this is >> an appropriate use. > > > Mmmm... but from my perspective, having a view of the entire system > from all layers, it feels... wrong. > Might almost be better to support some kind of proper 'aliases' > mechanism for the catalog instead. dunno. > Needs to be pondered on. well, I've slept a bit, and pondered a bit, and I'm liking the package idea a bit better than mucking with the catalog format. In its own way, a virtual package can serve well as an "alias in the catalog" To articulate the "wrongness", the following are my areas of concern with it: 1. having it registered in mantis. I'm thinking it would be nice to NOT register it 2. having another file almost needlessly sitting in our archives 3. having a "fake package" being actually installed on the user side when thats not what they really need #2, I think I might just have to live with #1, perhaps if it is agreed we dont want to register it, we can come up with some kind of agreed naming/pkginfo trigger that says "do not autoregister", this is just an alias #3... I'm thinking we might write it to deliberately NOT install. a very elegant solution, in a way: it would still pull in dependencies, but yet not needlessly install itself Only problem with that is, it would then potentially stop pkg-get/pkgutil from proceeding further. This MIGHT be seen as a good thing; it alerts the user "hey you did something you shouldnt really be doing". On the other hand, this would stop "pkg-get install all" from working ... Unless we updated pkg-get and pkgutil to also recognise the same magic for #1, and not fuss if that package bombed. Or, just not really pkgadd in the first place. Well, maybe we should still do that, so that the package gets to put out a special message? Dunno, there's a few ways we could go, there. This probably deserves a fresh thread in maintainers, if you're really serious about it. --- End forwarded message --- -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Feb 3 03:12:34 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 02 Feb 2011 21:12:34 -0500 Subject: [csw-maintainers] Aliased names vs dummy packages [Was [csw-pkgsubmissions] newpkgs py_webpy] In-Reply-To: <1296699033-sup-5971@pinkfloyd.chass.utoronto.ca> References: <1296698900-sup-2331@pinkfloyd.chass.utoronto.ca> <1296699033-sup-5971@pinkfloyd.chass.utoronto.ca> Message-ID: <1296699106-sup-8446@pinkfloyd.chass.utoronto.ca> And, Phil's follow up... On 1/27/11, Ben Walton wrote: > > 3. A mismatch between requested packages and installed packages on the > system. The opposite of your #3 above. > > - This is harmless, but possibly confusing for an admin. "Hey, I > installed webpy, where is it..." > mmm, thats nasty too. Sounds like you should start a fresh thread on maintainers. If you do, please summarize the points I made, as well as your new points. Also, I'm thinking to propose webpy|CSWwebpy-alias => py_webpy|CSWpywebpy as a naming strategy. Slightly "breaks" our soft|CSWsoft 1-to-1 correlation, but seems nicest compromise. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Feb 3 03:11:14 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 02 Feb 2011 21:11:14 -0500 Subject: [csw-maintainers] Aliased names vs dummy packages [Was [csw-pkgsubmissions] newpkgs py_webpy] In-Reply-To: <1296698900-sup-2331@pinkfloyd.chass.utoronto.ca> References: <1296698900-sup-2331@pinkfloyd.chass.utoronto.ca> Message-ID: <1296699033-sup-5971@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jan 24 09:14:49 -0500 2011: > 1. having it registered in mantis. I'm thinking it would be nice to > NOT register it This isn't a bad idea, but it would complicate a process that is seemingly already fragile. Bugs can be moved in the DB. If it's a real package, although only a stub, treat it as such. A GAR-built stub will contain a license file at a minimum. The fewer special cases we have, the better. > 2. having another file almost needlessly sitting in our archives Yes, it's hard to avoid this if a real package file is used. You're correct in saying that it's a survivable artifact. > 3. having a "fake package" being actually installed on the user side > when thats not what they really need To this I'd say, use the postmsg CAS to inform the user that the package can be removed as it's just a stub. No need to jump through extra hoops to have it perform a non-installation. It is serving a valid purpose for the user that installed it, thus it's not hurting anything on that system. The opposite of using a package for this involves many things that are less desirable: 1. Catalog format modification or (and I think better), creation of a third file to reside with catalog and descriptions named aliases. Tools would need updates to take this into account either way it's done. - Updating tools to add functionality isn't a bad thing, but it is a lot of extra work and requires coordination among several tools/people. 2. Additional process creation for maintenance of these aliases. Eg: in the package submission mail, maintainers says "oh, hey, add this alias too..." and then some file manipulation happens, etc. - This is the real pita, I think. 3. A mismatch between requested packages and installed packages on the system. The opposite of your #3 above. - This is harmless, but possibly confusing for an admin. "Hey, I installed webpy, where is it..." Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Feb 3 03:19:01 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 02 Feb 2011 21:19:01 -0500 Subject: [csw-maintainers] Aliased names vs dummy packages [Was [csw-pkgsubmissions] newpkgs py_webpy] In-Reply-To: <1296699106-sup-8446@pinkfloyd.chass.utoronto.ca> References: <1296698900-sup-2331@pinkfloyd.chass.utoronto.ca> <1296699033-sup-5971@pinkfloyd.chass.utoronto.ca> <1296699106-sup-8446@pinkfloyd.chass.utoronto.ca> Message-ID: <1296699159-sup-730@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Wed Feb 02 21:12:34 -0500 2011: > Also, I'm thinking to propose webpy|CSWwebpy-alias => py_webpy|CSWpywebpy > as a naming strategy. > Slightly "breaks" our soft|CSWsoft 1-to-1 correlation, but seems > nicest compromise. I don't understand the advantage of breaking the consistency? It makes it more visible if skimming either the catalog or the /var/sadm/pkg directory, but otherwise it doesn't offer much. Are these common enough activities to warrant breaking the consistency? I don't do either of these very often, but maybe others do? I'm not against the idea though as it doesn't really hurt anything either. If we do make the break, I'd suggest going with CSWalias-webpy. That would at least have them sort together with any other 'alias' packages. Anyone else have thoughts on this? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Feb 3 03:24:57 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 02 Feb 2011 21:24:57 -0500 Subject: [csw-maintainers] Introducing the QA pages mockup In-Reply-To: <4D47443C.8060401@wbonnet.net> References: <4D47443C.8060401@wbonnet.net> Message-ID: <1296699765-sup-3051@pinkfloyd.chass.utoronto.ca> Excerpts from William Bonnet's message of Mon Jan 31 18:22:36 -0500 2011: Hi William, > I would like to submit these pages to your review, critics, comments, > and everything :) These look great and I think they'll prove quite useful. What do you think about adding a legend for the icons? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu Feb 3 06:14:05 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 2 Feb 2011 21:14:05 -0800 Subject: [csw-maintainers] Aliased names vs dummy packages [Was [csw-pkgsubmissions] newpkgs py_webpy] In-Reply-To: <1296699159-sup-730@pinkfloyd.chass.utoronto.ca> References: <1296698900-sup-2331@pinkfloyd.chass.utoronto.ca> <1296699033-sup-5971@pinkfloyd.chass.utoronto.ca> <1296699106-sup-8446@pinkfloyd.chass.utoronto.ca> <1296699159-sup-730@pinkfloyd.chass.utoronto.ca> Message-ID: On Wednesday, February 2, 2011, Ben Walton wrote: > Excerpts from Ben Walton's message of Wed Feb 02 21:12:34 -0500 > > If we do make the break, I'd suggest going with CSWalias-webpy. ?That > would at least have them sort together with any other 'alias' > packages. > that's a good idea. It also reminds me of what we do with CSWcas-xxx From pfelecan at opencsw.org Thu Feb 3 09:19:52 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 03 Feb 2011 09:19:52 +0100 Subject: [csw-maintainers] Mirror update notifications In-Reply-To: <20110202.18545000.997843832@gyor.oxdrove.co.uk> (James Lee's message of "Wed, 02 Feb 2011 18:54:50 GMT") References: <20110202.18545000.997843832@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 02/02/11, 17:59:54, =?UTF-8?Q?Maciej_Blizi=C5=84ski?= > wrote regarding [csw-maintainers] Mirror update > notifications: > >> There has been historically an issue that we never knew when our >> released packages hit the mirror[1]. It was a typical scenario when >> building a chain of dependencies, that after a package has been >> accepted, we had to keep on manually checking the mirror and searching >> through the catalog file to find out whether our package is already >> available to the world - and the buildfarm. > > No, just set -I and -L appropriately. What do you mean? -- Peter From pfelecan at opencsw.org Thu Feb 3 09:31:39 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 03 Feb 2011 09:31:39 +0100 Subject: [csw-maintainers] Aliased names vs dummy packages In-Reply-To: <1296699159-sup-730@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Wed, 02 Feb 2011 21:19:01 -0500") References: <1296698900-sup-2331@pinkfloyd.chass.utoronto.ca> <1296699033-sup-5971@pinkfloyd.chass.utoronto.ca> <1296699106-sup-8446@pinkfloyd.chass.utoronto.ca> <1296699159-sup-730@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Anyone else have thoughts on this? Well, all this is so useless as it exceeds my capacity of comprehension after reading and re-reading the thread. Remember, all started form an esthetically oriented discussion which was: webpy is not webpy. This is typical to the whimsical release managing that we have. What's the problem that release management wants to solve? Isn't the "solution" making things more complicated than leaving the problem alone, i.e. webpy is webpy? IMO, there are more important subjects without loosing our time on this kind of white noise and I'll not offense by providing a list. -- Peter From pfelecan at opencsw.org Thu Feb 3 09:34:00 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 03 Feb 2011 09:34:00 +0100 Subject: [csw-maintainers] Introducing the QA pages mockup In-Reply-To: <1296699765-sup-3051@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Wed, 02 Feb 2011 21:24:57 -0500") References: <4D47443C.8060401@wbonnet.net> <1296699765-sup-3051@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from William Bonnet's message of Mon Jan 31 18:22:36 -0500 2011: > > Hi William, > >> I would like to submit these pages to your review, critics, comments, >> and everything :) > > These look great and I think they'll prove quite useful. What do you > think about adding a legend for the icons? The icons have alternative text which appears as tips when the mouse hovers on them, isn't it? However, I agree that a legend is more obvious. -- Peter From bonivart at opencsw.org Thu Feb 3 10:20:27 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 3 Feb 2011 10:20:27 +0100 Subject: [csw-maintainers] Aliased names vs dummy packages [Was [csw-pkgsubmissions] newpkgs py_webpy] In-Reply-To: <1296699159-sup-730@pinkfloyd.chass.utoronto.ca> References: <1296698900-sup-2331@pinkfloyd.chass.utoronto.ca> <1296699033-sup-5971@pinkfloyd.chass.utoronto.ca> <1296699106-sup-8446@pinkfloyd.chass.utoronto.ca> <1296699159-sup-730@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Feb 3, 2011 at 3:19 AM, Ben Walton wrote: > Excerpts from Ben Walton's message of Wed Feb 02 21:12:34 -0500 2011: > >> Also, I'm thinking to propose ? webpy|CSWwebpy-alias => ?py_webpy|CSWpywebpy >> as a naming strategy. >> Slightly "breaks" our ? ? soft|CSWsoft 1-to-1 correlation, but seems >> nicest compromise. > > I don't understand the advantage of breaking the consistency? ?It > makes it more visible if skimming either the catalog or the > /var/sadm/pkg directory, but otherwise it doesn't offer much. ?Are > these common enough activities to warrant breaking the consistency? ?I > don't do either of these very often, but maybe others do? > > I'm not against the idea though as it doesn't really hurt anything > either. > > If we do make the break, I'd suggest going with CSWalias-webpy. ?That > would at least have them sort together with any other 'alias' > packages. > > Anyone else have thoughts on this? Is this really a problem worth solving? Being consistent with our own naming standard actually makes it easier for our users to find the right package as well. With the stub packages, they are something transitioning away when not needed but these aliases will stay forever because we will never know if anyone uses them. Also this inflates our package count without adding any real content. /peter From maciej at opencsw.org Thu Feb 3 10:25:22 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 3 Feb 2011 09:25:22 +0000 Subject: [csw-maintainers] Shared library placement proposal Message-ID: Continuing a topic started last month[1], I'd like to put forward a proposal[2] for shared library placement. Most of our package would not be affected by it; it's most of interest to the maintainers of packages which put shared libraries under custom prefixes. For details, please refer to the proposal. Maciej [1] http://lists.opencsw.org/pipermail/maintainers/2011-January/013595.html [2] http://wiki.opencsw.org/proposal:shared-library-placement From maciej at opencsw.org Thu Feb 3 10:45:36 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 3 Feb 2011 09:45:36 +0000 Subject: [csw-maintainers] Aliased names vs dummy packages In-Reply-To: References: <1296698900-sup-2331@pinkfloyd.chass.utoronto.ca> <1296699033-sup-5971@pinkfloyd.chass.utoronto.ca> <1296699106-sup-8446@pinkfloyd.chass.utoronto.ca> <1296699159-sup-730@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/3 Peter FELECAN : > Ben Walton writes: > >> Anyone else have thoughts on this? > > Well, all this is so useless as it exceeds my capacity of comprehension > after reading and re-reading the thread. Remember, all started form an > esthetically oriented discussion which was: webpy is not webpy. This is > typical to the whimsical release managing that we have. > > What's the problem that release management wants to solve? > > Isn't the "solution" making things more complicated than leaving the > problem alone, i.e. webpy is webpy? > > IMO, there are more important subjects without loosing our time on this > kind of white noise and I'll not offense by providing a list. I agree, this is not a good use of engineering time. From pfelecan at opencsw.org Thu Feb 3 11:11:56 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 03 Feb 2011 11:11:56 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 3 Feb 2011 09:25:22 +0000") References: Message-ID: Maciej Blizi?ski writes: > Continuing a topic started last month[1], I'd like to put forward a > proposal[2] for shared library placement. Most of our package would > not be affected by it; it's most of interest to the maintainers of > packages which put shared libraries under custom prefixes. For > details, please refer to the proposal. I globally agree with the exception of the handling of private shared libraries: it should be optional to put these in a specific directory with the exception of file name conflicts which, given the naming convention is very improbable. BTW, your phrasing is "should" which is alright for me vs. "must" which would be not. -- Peter From maciej at opencsw.org Thu Feb 3 12:00:12 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 3 Feb 2011 11:00:12 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: Message-ID: 2011/2/3 Peter FELECAN : > I globally agree with the exception of the handling of private shared > libraries: it should be optional to put these in a specific directory If you put a private shared library in /opt/csw/lib, wouldn't it effectively make it a public one? Once a library is in /opt/csw/lib, you can add a -l flag to the linker and link against it in the same way you link against public libraries. A private library in /opt/csw/lib sounds like an oxymoron to me. However, there's nothing that prevents you from putting any shared library of your choice into /opt/csw/lib, as long as it's packaged according to the standard - meaning, it's in a separate package. From pfelecan at opencsw.org Thu Feb 3 13:48:21 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 03 Feb 2011 13:48:21 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 3 Feb 2011 11:00:12 +0000") References: Message-ID: Maciej Blizi?ski writes: > 2011/2/3 Peter FELECAN : >> I globally agree with the exception of the handling of private shared >> libraries: it should be optional to put these in a specific directory > > If you put a private shared library in /opt/csw/lib, wouldn't it > effectively make it a public one? > > Once a library is in /opt/csw/lib, you can add a -l flag to the linker > and link against it in the same way you link against public libraries. > A private library in /opt/csw/lib sounds like an oxymoron to me. > > However, there's nothing that prevents you from putting any shared > library of your choice into /opt/csw/lib, as long as it's packaged > according to the standard - meaning, it's in a separate package. I see 2 reasons for which a private library can be let in /opt/csw/lib: 1. nothing precludes to use it if the API is public; if the provider considers it private he had put it in a private directory and not supply an API 2. making mandatory this kind of policy for private library unnecessarily complexify packaging vs Debian which doesn't have this kind of policy. -- Peter From bwalton at opencsw.org Thu Feb 3 13:55:58 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 03 Feb 2011 07:55:58 -0500 Subject: [csw-maintainers] Introducing the QA pages mockup In-Reply-To: References: <4D47443C.8060401@wbonnet.net> <1296699765-sup-3051@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Peter, I may have missed the tooltip text as chrome has some issues displaying them in a lot of cases... Thanks -Ben "Peter FELECAN" wrote: >Ben Walton writes: > >> Excerpts from William Bonnet's message of Mon Jan 31 18:22:36 -0500 >2011: >> >> Hi William, >> >>> I would like to submit these pages to your review, critics, >comments, >>> and everything :) >> >> These look great and I think they'll prove quite useful. What do you >> think about adding a legend for the icons? > >The icons have alternative text which appears as tips when the mouse >hovers on them, isn't it? However, I agree that a legend is more >obvious. >-- >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 Thu Feb 3 14:16:14 2011 From: william at wbonnet.net (William Bonnet) Date: Thu, 3 Feb 2011 14:16:14 +0100 Subject: [csw-maintainers] Introducing the QA pages mockup In-Reply-To: References: <4D47443C.8060401@wbonnet.net> <1296699765-sup-3051@pinkfloyd.chass.utoronto.ca> Message-ID: <7CA9F5DC-F93A-413A-8EB3-8C4312E17DFB@wbonnet.net> Hi I will add a legend describing the icons and some more "text" explaining what the page is about. cheers W. Le 3 f?vr. 2011 ? 13:55, Ben Walton a ?crit : > Hi Peter, > > I may have missed the tooltip text as chrome has some issues displaying them in a lot of cases... > > Thanks > -Ben > > "Peter FELECAN" wrote: > >> Ben Walton writes: >> >>> Excerpts from William Bonnet's message of Mon Jan 31 18:22:36 -0500 >> 2011: >>> >>> Hi William, >>> >>>> I would like to submit these pages to your review, critics, >> comments, >>>> and everything :) >>> >>> These look great and I think they'll prove quite useful. What do you >>> think about adding a legend for the icons? >> >> The icons have alternative text which appears as tips when the mouse >> hovers on them, isn't it? However, I agree that a legend is more >> obvious. >> -- >> 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. ::. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From bonivart at opencsw.org Thu Feb 3 14:25:05 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 3 Feb 2011 14:25:05 +0100 Subject: [csw-maintainers] sourceforge attack In-Reply-To: <1296524068-sup-9512@pinkfloyd.chass.utoronto.ca> References: <1296524068-sup-9512@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Feb 1, 2011 at 2:35 AM, Ben Walton wrote: > > Hi All, > > For those interested, SF.net has posted full disclosure report of the > recent attack: > http://sourceforge.net/blog/sourceforge-attack-full-report/ More here: http://ht.ly/3Psbo /peter From james at opencsw.org Thu Feb 3 15:17:58 2011 From: james at opencsw.org (James Lee) Date: Thu, 03 Feb 2011 14:17:58 GMT Subject: [csw-maintainers] Mirror update notifications In-Reply-To: References: <20110202.18545000.997843832@gyor.oxdrove.co.uk> Message-ID: <20110203.14175800.2527274271@gyor.oxdrove.co.uk> On 03/02/11, 08:19:52, Peter FELECAN wrote regarding Re: [csw-maintainers] Mirror update notifications: > >> There has been historically an issue that we never knew when our > >> released packages hit the mirror[1]. It was a typical scenario when > >> building a chain of dependencies, that after a package has been > >> accepted, we had to keep on manually checking the mirror and searching > >> through the catalog file to find out whether our package is already > >> available to the world - and the buildfarm. > > > > No, just set -I and -L appropriately. > What do you mean? Are you saying you don't recognise -I and -L? Or how to use them to build with a package that hasn't been installed? James. From pfelecan at opencsw.org Thu Feb 3 15:44:46 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 03 Feb 2011 15:44:46 +0100 Subject: [csw-maintainers] Mirror update notifications In-Reply-To: <20110203.14175800.2527274271@gyor.oxdrove.co.uk> (James Lee's message of "Thu, 03 Feb 2011 14:17:58 GMT") References: <20110202.18545000.997843832@gyor.oxdrove.co.uk> <20110203.14175800.2527274271@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 03/02/11, 08:19:52, Peter FELECAN wrote regarding > Re: [csw-maintainers] Mirror update notifications: > >> >> There has been historically an issue that we never knew when our >> >> released packages hit the mirror[1]. It was a typical scenario when >> >> building a chain of dependencies, that after a package has been >> >> accepted, we had to keep on manually checking the mirror and searching >> >> through the catalog file to find out whether our package is already >> >> available to the world - and the buildfarm. >> > >> > No, just set -I and -L appropriately. > >> What do you mean? > > Are you saying you don't recognise -I and -L? Or how to use them > to build with a package that hasn't been installed? Oh my. I'm not a compiler/linker. There are many utilities taking that options. And in the context of notification it was not clear. Whence my question. Anyway, thanks for the answer which now make more sense. -- Peter From james at opencsw.org Thu Feb 3 18:17:49 2011 From: james at opencsw.org (James Lee) Date: Thu, 03 Feb 2011 17:17:49 GMT Subject: [csw-maintainers] Mirror update notifications In-Reply-To: References: <20110202.18545000.997843832@gyor.oxdrove.co.uk> <20110203.14175800.2527274271@gyor.oxdrove.co.uk> Message-ID: <20110203.17174900.1731486754@gyor.oxdrove.co.uk> On 03/02/11, 14:44:46, Peter FELECAN wrote regarding Re: [csw-maintainers] Mirror update notifications: > >> >> There has been historically an issue that we never knew when our > >> >> released packages hit the mirror[1]. It was a typical scenario when > >> >> building a chain of dependencies, that after a package has been > >> >> accepted, we had to keep on manually checking the mirror and searching > >> >> through the catalog file to find out whether our package is already > >> >> available to the world - and the buildfarm. > >> > > >> > No, just set -I and -L appropriately. > > > >> What do you mean? > > > > Are you saying you don't recognise -I and -L? Or how to use them > > to build with a package that hasn't been installed? > Oh my. I'm not a compiler/linker. You've failed the Turing test. > There are many utilities taking that > options. And in the context of notification it was not clear. Whence my > question. Anyway, thanks for the answer which now make more sense. With the vast majority of packages being compiled C/C++ the context should be obvious, particularly as I regularly set these to local values to circumvent the very issue being touted. James. From phil at bolthole.com Thu Feb 3 18:48:03 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 3 Feb 2011 09:48:03 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: Message-ID: 2011/2/3 Maciej Blizi?ski : > Continuing a topic started last month[1], I'd like to put forward a > proposal[2] for shared library placement. ?Most of our package would > not be affected by it; it's most of interest to the maintainers of > packages which put shared libraries under custom prefixes. ?For > details, please refer to the proposal. > > Maciej > > [1] http://lists.opencsw.org/pipermail/maintainers/2011-January/013595.html > [2] http://wiki.opencsw.org/proposal:shared-library-placement I object to the proposal as it stands, and ask that the following paragraph, "Public shared libraries, the ones that other software projects can link to, should be put directly under /opt/csw/lib. If a project is compiled using a custom prefix and the installer puts shared libraries under /opt/csw/foo/lib, shared libraries need to be moved to /opt/csw/lib by the maintainer. " be rewritten to be, "Public shared libraries, the ones that other software projects can link to, should be put directly under /opt/csw/lib. If a project is compiled using a custom prefix and the installer puts shared libraries under /opt/csw/foo/lib, [change start here] a symlink /opt/csw/libXX -> /opt/csw/foo/lib/libXXX, should be created. Additionally, this symlink should be created IF and ONLY if, the SONAME and filename for the library are unique. If on the other hand, there is potential for multiple versions of the library to be installed at one time, under different prefixes (/opt/csw/foo3,4,5), and the SONAME is not unique, then no symlink in /opt/csw/lib should be created. " Rational for this has already been given in the above-referenced email thread. From pfelecan at opencsw.org Thu Feb 3 19:05:03 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 03 Feb 2011 19:05:03 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: (Philip Brown's message of "Thu, 3 Feb 2011 09:48:03 -0800") References: Message-ID: Philip Brown writes: > 2011/2/3 Maciej Blizi?ski : >> Continuing a topic started last month[1], I'd like to put forward a >> proposal[2] for shared library placement. ?Most of our package would >> not be affected by it; it's most of interest to the maintainers of >> packages which put shared libraries under custom prefixes. ?For >> details, please refer to the proposal. >> >> Maciej >> >> [1] http://lists.opencsw.org/pipermail/maintainers/2011-January/013595.html >> [2] http://wiki.opencsw.org/proposal:shared-library-placement > > > I object to the proposal as it stands, and ask that the following paragraph, > > "Public shared libraries, the ones that other software projects can > link to, should be put directly under /opt/csw/lib. If a project is > compiled using a custom prefix and the installer puts shared libraries > under /opt/csw/foo/lib, shared libraries need to be moved to > /opt/csw/lib by the maintainer. > " > > be rewritten to be, > > > "Public shared libraries, the ones that other software projects can > link to, should be put directly under /opt/csw/lib. > If a project is compiled using a custom prefix and the installer puts > shared libraries under /opt/csw/foo/lib, [change start here] > a symlink /opt/csw/libXX -> /opt/csw/foo/lib/libXXX, should be > created. Additionally, this symlink should be created IF and ONLY if, > the SONAME and filename for the library are unique. If on the other > hand, there is potential for multiple versions of the library to be > installed at one time, under different prefixes (/opt/csw/foo3,4,5), > and the SONAME is not unique, then no symlink in /opt/csw/lib should > be created. > " > > Rational for this has already been given in the above-referenced email thread. The rationale was re-read and I still don't get it. Can you develop in a more intelligible way please? -- Peter From pfelecan at opencsw.org Thu Feb 3 19:08:30 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 03 Feb 2011 19:08:30 +0100 Subject: [csw-maintainers] Mirror update notifications In-Reply-To: <20110203.17174900.1731486754@gyor.oxdrove.co.uk> (James Lee's message of "Thu, 03 Feb 2011 17:17:49 GMT") References: <20110202.18545000.997843832@gyor.oxdrove.co.uk> <20110203.14175800.2527274271@gyor.oxdrove.co.uk> <20110203.17174900.1731486754@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 03/02/11, 14:44:46, Peter FELECAN wrote regarding > Re: [csw-maintainers] Mirror update notifications: > >> >> >> There has been historically an issue that we never knew when our >> >> >> released packages hit the mirror[1]. It was a typical scenario when >> >> >> building a chain of dependencies, that after a package has been >> >> >> accepted, we had to keep on manually checking the mirror and searching >> >> >> through the catalog file to find out whether our package is already >> >> >> available to the world - and the buildfarm. >> >> > >> >> > No, just set -I and -L appropriately. >> > >> >> What do you mean? >> > >> > Are you saying you don't recognise -I and -L? Or how to use them >> > to build with a package that hasn't been installed? > >> Oh my. I'm not a compiler/linker. > > You've failed the Turing test. Still I eat apples. >> There are many utilities taking that >> options. And in the context of notification it was not clear. Whence my >> question. Anyway, thanks for the answer which now make more sense. > > With the vast majority of packages being compiled C/C++ the context > should be obvious, particularly as I regularly set these to local > values to circumvent the very issue being touted. Not being a divine I cannot see that. -- Peter From phil at bolthole.com Thu Feb 3 19:38:31 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 3 Feb 2011 10:38:31 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: Message-ID: On Thu, Feb 3, 2011 at 10:05 AM, Peter FELECAN wrote: > Philip Brown writes: > >> >> "Public shared libraries, the ones that other software projects can >> link to, should be put directly under /opt/csw/lib. >> If a project is compiled using a custom prefix and the installer puts >> shared libraries under /opt/csw/foo/lib, [change start here] >> a symlink /opt/csw/libXX -> /opt/csw/foo/lib/libXXX, should be >> created. Additionally, this symlink should be created IF and ONLY if, >> the SONAME and filename for the library are unique. If on the other >> hand, there is potential for multiple versions of the library to be >> installed at one time, under different prefixes (/opt/csw/foo3,4,5), >> and the SONAME is not unique, then no symlink in /opt/csw/lib should >> be created. >> " >> >> Rational for this has already been given in the above-referenced email thread. > > The rationale was re-read and I still don't get it. Can you develop in a > more intelligible way please? I'm not sure how I could make it any more clear. It seems pretty clear to me. So instead, let me put it to you another way: "it's less work". Just adding in a symlink from /opt/csw/lib to whereever, is less work than having to move a file from /opt/csw/prefix to /opt/csw/lib, and then also having to make a symlink from /opt/csw/prefix to the new location. One action, vs two. We need to have the library visible in both locations, to avoid confusion to both users, and potential auto-detect scripts. Ones that tend to have single flags like --use-libfoo=/prefix, rather than 3 separate flags for --usr-libfoo-lib, --use-libfoo-include, --use-libfoo-iforgettheotherthing And to reply in advance to Maciej, I dont think that "well we can just let GAR do the work, so 'more work' doesnt count", applies. We could inappropriately justify all kinds of nonsense with that attitude. Simpler, is better. From pfelecan at opencsw.org Thu Feb 3 20:24:12 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 03 Feb 2011 20:24:12 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: (Philip Brown's message of "Thu, 3 Feb 2011 10:38:31 -0800") References: Message-ID: Philip Brown writes: > On Thu, Feb 3, 2011 at 10:05 AM, Peter FELECAN wrote: >> Philip Brown writes: >> >>> >>> "Public shared libraries, the ones that other software projects can >>> link to, should be put directly under /opt/csw/lib. >>> If a project is compiled using a custom prefix and the installer puts >>> shared libraries under /opt/csw/foo/lib, [change start here] >>> a symlink /opt/csw/libXX -> /opt/csw/foo/lib/libXXX, should be >>> created. Additionally, this symlink should be created IF and ONLY if, >>> the SONAME and filename for the library are unique. If on the other >>> hand, there is potential for multiple versions of the library to be >>> installed at one time, under different prefixes (/opt/csw/foo3,4,5), >>> and the SONAME is not unique, then no symlink in /opt/csw/lib should >>> be created. >>> " >>> >>> Rational for this has already been given in the above-referenced email thread. >> >> The rationale was re-read and I still don't get it. Can you develop in a >> more intelligible way please? > > I'm not sure how I could make it any more clear. It seems pretty clear to me. > So instead, let me put it to you another way: This is exactly what I expected. Thanks. > "it's less work". > > Just adding in a symlink from /opt/csw/lib to whereever, is less work > than having to move a file from /opt/csw/prefix to /opt/csw/lib, and > then also having to make a symlink from /opt/csw/prefix to the new > location. One action, vs two. Well, you'll agree that the difference, in terms of effort, is quite insignificant, isn't it? > We need to have the library visible in both locations, to avoid > confusion to both users, and potential auto-detect scripts. Ones that > tend to have single flags like --use-libfoo=/prefix, rather than 3 > separate flags for --usr-libfoo-lib, --use-libfoo-include, > --use-libfoo-iforgettheotherthing I was quite opposed to this specific directories for different versions but lived with its inconveniences. Now that we have alternatives, it's really a PITA. Anyhow, what I wish is to not make it mandatory to separate different versions of the same project, which make sense to be installed simultaneously, in different directories but to be able to use alternatives and shared objects in /opt/csw/lib as a accepted solution. > And to reply in advance to Maciej, I dont think that "well we can just > let GAR do the work, so 'more work' doesnt count", applies. We could > inappropriately justify all kinds of nonsense with that attitude. I agree. -- Peter From phil at bolthole.com Thu Feb 3 20:37:16 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 3 Feb 2011 11:37:16 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: Message-ID: On 2/3/11, Peter FELECAN wrote: > >> We need to have the library visible in both locations, to avoid >> confusion to both users, and potential auto-detect scripts. Ones that >> tend to have single flags like --use-libfoo=/prefix, rather than 3 >> separate flags for --usr-libfoo-lib, --use-libfoo-include, >> --use-libfoo-iforgettheotherthing > > I was quite opposed to this specific directories for different > versions but lived with its inconveniences. Now that we have > alternatives, it's really a PITA. > > Anyhow, what I wish is to not make it mandatory to separate different > versions of the same project, which make sense to be installed > simultaneously, in different directories but to be able to use > alternatives and shared objects in /opt/csw/lib as a accepted solution. well, we may have different reasons for it, but seems like in that case, we both agree on something: Forcing the "actual file", rather than a symlink, into /opt/csw/lib, for *all* cases, is bad. Symlinks are more appropriate in some cases. Whether that symlink is done via "alternatives" or some other means, is not an immediate issue to me. The immediate concern to me is that the proposal as written, prohibits that sort of thing, and so needs to be changed. From bwalton at opencsw.org Fri Feb 4 01:31:25 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 03 Feb 2011 19:31:25 -0500 Subject: [csw-maintainers] Aliased names vs dummy packages In-Reply-To: References: <1296698900-sup-2331@pinkfloyd.chass.utoronto.ca> <1296699033-sup-5971@pinkfloyd.chass.utoronto.ca> <1296699106-sup-8446@pinkfloyd.chass.utoronto.ca> <1296699159-sup-730@pinkfloyd.chass.utoronto.ca> Message-ID: <1296779400-sup-5899@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Thu Feb 03 04:45:36 -0500 2011: > > IMO, there are more important subjects without loosing our time on > > this kind of white noise and I'll not offense by providing a list. > > I agree, this is not a good use of engineering time. Ok, fair enough. I don't think it's a bad idea and I don't think implementation has much cost at all, especially for GAR users. That being said, I don't care about it enough to push for it. Maciej, you'll release under py_webpy then? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri Feb 4 08:36:04 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 4 Feb 2011 07:36:04 +0000 Subject: [csw-maintainers] Aliased names vs dummy packages In-Reply-To: <1296779400-sup-5899@pinkfloyd.chass.utoronto.ca> References: <1296698900-sup-2331@pinkfloyd.chass.utoronto.ca> <1296699033-sup-5971@pinkfloyd.chass.utoronto.ca> <1296699106-sup-8446@pinkfloyd.chass.utoronto.ca> <1296699159-sup-730@pinkfloyd.chass.utoronto.ca> <1296779400-sup-5899@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/4 Ben Walton : > Excerpts from Maciej Blizi?ski's message of Thu Feb 03 04:45:36 -0500 2011: > >> > IMO, there are more important subjects without loosing our time on >> > this kind of white noise and I'll not offense by providing a list. >> >> I agree, this is not a good use of engineering time. > > Ok, fair enough. ?I don't think it's a bad idea and I don't think > implementation has much cost at all, especially for GAR users. ?That > being said, I don't care about it enough to push for it. > > Maciej, you'll release under py_webpy then? Yes, I'm happy with py_webpy. From maciej at opencsw.org Fri Feb 4 09:18:26 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 4 Feb 2011 08:18:26 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: Message-ID: 2011/2/3 Peter FELECAN : > Maciej Blizi?ski writes: > >> 2011/2/3 Peter FELECAN : >>> I globally agree with the exception of the handling of private shared >>> libraries: it should be optional to put these in a specific directory >> >> If you put a private shared library in /opt/csw/lib, wouldn't it >> effectively make it a public one? >> >> Once a library is in /opt/csw/lib, you can add a -l flag to the linker >> and link against it in the same way you link against public libraries. >> ?A private library in /opt/csw/lib sounds like an oxymoron to me. >> >> However, there's nothing that prevents you from putting any shared >> library of your choice into /opt/csw/lib, as long as it's packaged >> according to the standard - meaning, it's in a separate package. > > I see 2 reasons for which a private library can be let in /opt/csw/lib: > > 1. nothing precludes to use it if the API is public; if the provider > ? considers it private he had put it in a private directory and not > ? supply an API If a library has a public API, then by definition the library is public, I guess we both agree on that. Regarding the second part, I would not necessarily rely on the locations of libraries as installed by the upstream 'make install' target. I've seen projects that install private libraries into /opt/csw/lib, and vice versa, public libraries installed into /opt/csw/lib/foo. We can instead analyze the upstream project's code to determine which libraries are shared and which are public. Talking to upstream developers is also an option. > 2. making mandatory this kind of policy for private library > ? unnecessarily complexify packaging vs Debian which doesn't have > ? this kind of policy. It does add some complexity, I agree. But it does it for a good reason: we want to avoid other projects accidentally linking to a library which was thought to be private, because once this happens, you need to take the following steps to recover: 1. Move the once-thought-to-be-private library from CSWfoo to a separate package (e.g. CSWlibfoo1) 2. Make CSWfoo depend on CSWlibfoo1 (for backward compatibility) 3. Release CSWlibfoo1, re-release CSWfoo 4. File a bug with CSWbar (the package which accidentally linked to libfoo.so.1) 5. Wait for new CSWbar to be released 6. Remove the dependency on CSWlibfoo1 from CSWfoo 7. Re-release CSWfoo This kind of procedure is annoying, and I'm sure everyone would like to avoid it, if possible. The mistake in the other direction (putting a public library in a subdirectory), has less impact. To recover: 1. Move the library from CSWfoo to CSWlibfoo1 2. Make CSWfoo depend on CSWlibfoo1 (only if necessary, e.g. binaries from CSWfoo need libfoo.so.1) 3. Release CSWlibfoo1, re-release CSWfoo In the long run, this policy would be a time saver, for both maintainers: the maintainer of CSWfoo (+CSWlibfoo1), and the maintainer of CSWbar. Regarding Debian, if you read the "10.2 Libraries" section[1] of the Debian policy, you'll see the following paragraph: "Shared object files (often .so files) that are not public libraries, that is, they are not meant to be linked to by third party executables (binaries of other packages), should be installed in subdirectories of the /usr/lib directory. Such files are exempt from the rules that govern ordinary shared libraries, except that they must not be installed executable and should be stripped." [1] http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries From pfelecan at opencsw.org Fri Feb 4 09:22:32 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 04 Feb 2011 09:22:32 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: (Philip Brown's message of "Thu, 3 Feb 2011 11:37:16 -0800") References: Message-ID: Philip Brown writes: > On 2/3/11, Peter FELECAN wrote: >> >>> We need to have the library visible in both locations, to avoid >>> confusion to both users, and potential auto-detect scripts. Ones that >>> tend to have single flags like --use-libfoo=/prefix, rather than 3 >>> separate flags for --usr-libfoo-lib, --use-libfoo-include, >>> --use-libfoo-iforgettheotherthing >> >> I was quite opposed to this specific directories for different >> versions but lived with its inconveniences. Now that we have >> alternatives, it's really a PITA. >> >> Anyhow, what I wish is to not make it mandatory to separate different >> versions of the same project, which make sense to be installed >> simultaneously, in different directories but to be able to use >> alternatives and shared objects in /opt/csw/lib as a accepted solution. > > well, we may have different reasons for it, but seems like in that > case, we both agree on something: > > Forcing the "actual file", rather than a symlink, into /opt/csw/lib, > for *all* cases, is bad. Symlinks are more appropriate in some cases. > > Whether that symlink is done via "alternatives" or some other means, > is not an immediate issue to me. The immediate concern to me is that > the proposal as written, prohibits that sort of thing, and so needs to > be changed. Indeed, we cannot have a strict, mandatory policy on this, rather a recommendation which is still a policy. Consequently, your proposition of modification cannot be as strong as you proposed, i.e., imposing the symbolic links instead of the real files. As for using alternatives for shared libraries, I don't know what to think. I thought that alternatives are more appropriate to executables but I must confess that thoroughly exploring alternatives is one of my objectives. -- Peter From pfelecan at opencsw.org Fri Feb 4 09:48:09 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 04 Feb 2011 09:48:09 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 4 Feb 2011 08:18:26 +0000") References: Message-ID: Maciej Blizi?ski writes: > 2011/2/3 Peter FELECAN : >> Maciej Blizi?ski writes: >> >>> 2011/2/3 Peter FELECAN : >>>> I globally agree with the exception of the handling of private shared >>>> libraries: it should be optional to put these in a specific directory >>> >>> If you put a private shared library in /opt/csw/lib, wouldn't it >>> effectively make it a public one? >>> >>> Once a library is in /opt/csw/lib, you can add a -l flag to the linker >>> and link against it in the same way you link against public libraries. >>> ?A private library in /opt/csw/lib sounds like an oxymoron to me. >>> >>> However, there's nothing that prevents you from putting any shared >>> library of your choice into /opt/csw/lib, as long as it's packaged >>> according to the standard - meaning, it's in a separate package. >> >> I see 2 reasons for which a private library can be let in /opt/csw/lib: >> >> 1. nothing precludes to use it if the API is public; if the provider >> ? considers it private he had put it in a private directory and not >> ? supply an API > > If a library has a public API, then by definition the library is > public, I guess we both agree on that. Regarding the second part, I > would not necessarily rely on the locations of libraries as installed > by the upstream 'make install' target. I've seen projects that > install private libraries into /opt/csw/lib, and vice versa, public > libraries installed into /opt/csw/lib/foo. We can instead analyze the > upstream project's code to determine which libraries are shared and > which are public. Talking to upstream developers is also an option. > >> 2. making mandatory this kind of policy for private library >> ? unnecessarily complexify packaging vs Debian which doesn't have >> ? this kind of policy. > > It does add some complexity, I agree. But it does it for a good > reason: we want to avoid other projects accidentally linking to a > library which was thought to be private, because once this happens, > you need to take the following steps to recover: > > 1. Move the once-thought-to-be-private library from CSWfoo to a > separate package (e.g. CSWlibfoo1) > 2. Make CSWfoo depend on CSWlibfoo1 (for backward compatibility) > 3. Release CSWlibfoo1, re-release CSWfoo > 4. File a bug with CSWbar (the package which accidentally linked to libfoo.so.1) > 5. Wait for new CSWbar to be released > 6. Remove the dependency on CSWlibfoo1 from CSWfoo > 7. Re-release CSWfoo Have you, or anyone else encountered this case? In the affirmative please provide the example. > This kind of procedure is annoying, and I'm sure everyone would like > to avoid it, if possible. > > The mistake in the other direction (putting a public library in a > subdirectory), has less impact. To recover: > > 1. Move the library from CSWfoo to CSWlibfoo1 > 2. Make CSWfoo depend on CSWlibfoo1 (only if necessary, e.g. binaries > from CSWfoo need libfoo.so.1) > 3. Release CSWlibfoo1, re-release CSWfoo > > In the long run, this policy would be a time saver, for both > maintainers: the maintainer of CSWfoo (+CSWlibfoo1), and the > maintainer of CSWbar. > > Regarding Debian, if you read the "10.2 Libraries" section[1] of the > Debian policy, you'll see the following paragraph: > > "Shared object files (often .so files) that are not public libraries, > that is, they are not meant to be linked to by third party executables > (binaries of other packages), should be installed in subdirectories of > the /usr/lib directory. Such files are exempt from the rules that > govern ordinary shared libraries, except that they must not be > installed executable and should be stripped." I would like to emphasize the term *should* which is weaker than *must*. Again, if it's a should I agree. -- Peter From dam at opencsw.org Fri Feb 4 09:50:16 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Feb 2011 09:50:16 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: Message-ID: <032E4133-2DEE-478C-AD26-1F4C6C42FDC3@opencsw.org> Hi, Am 04.02.2011 um 09:22 schrieb Peter FELECAN: > Philip Brown writes: >> On 2/3/11, Peter FELECAN wrote: >>> >>>> We need to have the library visible in both locations, to avoid >>>> confusion to both users, and potential auto-detect scripts. Ones that >>>> tend to have single flags like --use-libfoo=/prefix, rather than 3 >>>> separate flags for --usr-libfoo-lib, --use-libfoo-include, >>>> --use-libfoo-iforgettheotherthing >>> >>> I was quite opposed to this specific directories for different >>> versions but lived with its inconveniences. Now that we have >>> alternatives, it's really a PITA. >>> >>> Anyhow, what I wish is to not make it mandatory to separate different >>> versions of the same project, which make sense to be installed >>> simultaneously, in different directories but to be able to use >>> alternatives and shared objects in /opt/csw/lib as a accepted solution. >> >> well, we may have different reasons for it, but seems like in that >> case, we both agree on something: >> >> Forcing the "actual file", rather than a symlink, into /opt/csw/lib, >> for *all* cases, is bad. Symlinks are more appropriate in some cases. >> >> Whether that symlink is done via "alternatives" or some other means, >> is not an immediate issue to me. The immediate concern to me is that >> the proposal as written, prohibits that sort of thing, and so needs to >> be changed. > > Indeed, we cannot have a strict, mandatory policy on this, rather a > recommendation which is still a policy. Consequently, your proposition > of modification cannot be as strong as you proposed, i.e., imposing the > symbolic links instead of the real files. > > As for using alternatives for shared libraries, I don't know what to > think. I thought that alternatives are more appropriate to executables > but I must confess that thoroughly exploring alternatives is one of my > objectives. I don't see the need for alternatvies on shared libraries. The existing use case for different levels of functionality can better be done by AUX linkage. Or are there other issues? Best regards -- Dago From maciej at opencsw.org Fri Feb 4 09:58:35 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 4 Feb 2011 08:58:35 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: Message-ID: 2011/2/4 Peter FELECAN : > Indeed, we cannot have a strict, mandatory policy on this, rather a > recommendation which is still a policy. Consequently, your proposition > of modification cannot be as strong as you proposed, i.e., imposing the > symbolic links instead of the real files. I agree that the policy regulating files vs symlinks should not be strict and mandatory. If a maintainer wants to have a specific layout of files and symlinks and has a good reason for it, they should be allowed to do this. In the typical case, if we have a library regular file and a symlink to it, it's a transitional state, in which the regular file is in the target location, and symlinks provide backward compatibility. If there is no transition necessary, putting a symlink where the file is needed, and hiding the regular file elsewhere sounds like a suboptimal practice. As far as the policy is concerned, we could find a wording which: - Recommends that regular files are put into /opt/csw/lib and that symlinks are not used without necessity - Allows symlinks to be used, if there is a reason for such use > As for using alternatives for shared libraries, I don't know what to > think. I thought that alternatives are more appropriate to executables > but I must confess that thoroughly exploring alternatives is one of my > objectives. As far as supporting multiple versions of the same software is concerned, shared libraries already have a mechanism for it: SONAMEs. It may happen that two different versions of the same software provide libraries with the same SONAME. For example, PostgreSQL 8.3, 8.4 and 9.0 provide libpq.so.5. In this case, we provide libpq.so.5 built from one of them, and we simply don't install other two. 8.3 client software will be happily using 9.0 libraries. There's no need for alternatives, at least in this case. Maciej From james at opencsw.org Fri Feb 4 10:20:37 2011 From: james at opencsw.org (James Lee) Date: Fri, 04 Feb 2011 09:20:37 GMT Subject: [csw-maintainers] Mirror update notifications In-Reply-To: References: <20110202.18545000.997843832@gyor.oxdrove.co.uk> <20110203.14175800.2527274271@gyor.oxdrove.co.uk> <20110203.17174900.1731486754@gyor.oxdrove.co.uk> Message-ID: <20110204.9203700.2985372275@gyor.oxdrove.co.uk> On 03/02/11, 18:08:30, Peter FELECAN wrote regarding Re: [csw-maintainers] Mirror update notifications: > >> There are many utilities taking that > >> options. And in the context of notification it was not clear. Whence my > >> question. Anyway, thanks for the answer which now make more sense. > > > > With the vast majority of packages being compiled C/C++ the context > > should be obvious, particularly as I regularly set these to local > > values to circumvent the very issue being touted. > Not being a divine I cannot see that. You don't need to be divine to read the mailing list, this has come up several times before. James. From phil at bolthole.com Fri Feb 4 19:03:13 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Feb 2011 10:03:13 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: Message-ID: 2011/2/4 Maciej Blizi?ski : > ... > It does add some complexity, I agree. ?But it does it for a good > reason: we want to avoid other projects accidentally linking to a > library which was thought to be private, ... In other words, to reserve namespace of shared libraries. I agree that this is a good thing, and that we should do "something" for it. However, putting symlinks in /opt/csw/lib to a prefixed library's location, is a perfectly valid 'something' for this purpose. From bonivart at opencsw.org Sat Feb 5 16:44:26 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 5 Feb 2011 16:44:26 +0100 Subject: [csw-maintainers] [policy] Re: [csw-pkgsubmissions] newpkgs rdesktop In-Reply-To: <1296916260-sup-4100@pinkfloyd.chass.utoronto.ca> References: <201102031642.p13GgSkJ021403@login.bo.opencsw.org> <00D243A4-2C18-4F39-9F9E-FA5D4AC18DD2@opencsw.org> <1296916260-sup-4100@pinkfloyd.chass.utoronto.ca> Message-ID: [Moved to maintainers since we're again discussing new policy at release time while packages are stuck] On Sat, Feb 5, 2011 at 3:38 PM, Ben Walton wrote: > The REV string is a good place to stick this info though. ?It's part > of the filename, which isn't really useful by itself, but it also > shows up in pkgparam output. ?It's completely trivial to add this > information to the REV string. I don't agree, the version string standard is not very well defined and if you look in the catalog we have some really ugly ones in there. Doing the compares solely on REV made it possible to get rid of the "_rev=foo"-uglyness and move it to the first part instead. Introducing new stuff there may break package tools as well. My suggestion is to make it clear that we NEVER have anything after the REV (any number of dot separated numerics) and make it up to the maintainer to add "p" to the first (version) part if he sees fit. That part is not used for version comparison so it's up to the maintainer what's in it. /peter From phil at bolthole.com Sat Feb 5 17:13:16 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 5 Feb 2011 08:13:16 -0800 Subject: [csw-maintainers] [policy] Re: feature patching, and naming Message-ID: Note: This thread is about how and when to indicate, "this package has been feature patched" (which is not the same as "this package has been patched to compile under solaris") On Sat, Feb 5, 2011 at 7:44 AM, Peter Bonivart wrote: > [Moved to maintainers since we're again discussing new policy at > release time while packages are stuck] > > On Sat, Feb 5, 2011 at 3:38 PM, Ben Walton wrote: >> The REV string is a good place to stick this info though. ?It's part >> of the filename, which isn't really useful by itself, but it also >> shows up in pkgparam output. ?It's completely trivial to add this >> information to the REV string. > > I don't agree, the version string standard is not very well defined > and if you look in the catalog we have some really ugly ones in there. > Doing the compares solely on REV made it possible to get rid of the > "_rev=foo"-uglyness and move it to the first part instead. Introducing > new stuff there may break package tools as well. > > My suggestion is to make it clear that we NEVER have anything after > the REV (any number of dot separated numerics) and make it up to the > maintainer to add "p" to the first (version) part if he sees fit. That > part is not used for version comparison so it's up to the maintainer > what's in it. Are you saying this only because you are concerned whether pkgutil will handle that condition properly? I'll remind folks, that one of the big reasons we went to soft-XXXX,REV=YYYY.MM.DD format, is that some people were up in arms that the part after the 'soft', and to the left of REV, "must match the upstream version string exactly". If we continue to respect that, then seems like the only place left in pkginfo VERSION string to put this, is at the end. soft-XXXX,REV=YYYY.MM.DD.p This should still be easy to parse by programs. The big issue here, is that whatever special format/offset we pick to tack on at the end of XXXX.. some software out there might choose to use the same delimiter. Case in point: we cant use soft-XXXXp, because openssh decided to use "p" in their standard version string. From bonivart at opencsw.org Sat Feb 5 17:25:43 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 5 Feb 2011 17:25:43 +0100 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: References: Message-ID: On Sat, Feb 5, 2011 at 5:13 PM, Philip Brown wrote: > Case in point: we cant use soft-XXXXp, because openssh decided to use > "p" in their standard version string. Why not? It doesn't have any technical functionality, it's just a marker. If Yann saw it necessary he could just tack on "patched" there to distinguish it from openssh's use of "p", like: 5.4p1patched,REV=2010.03.25 This would be harmless to both pkg-get and pkgutil but adding something after REV would open up to weirdness once again. We finally closed that, let's not open it again. /peter From phil at bolthole.com Sat Feb 5 17:51:26 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 5 Feb 2011 08:51:26 -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: FYI for the curious, or the pessimistic: I have just batched a new version of pkg-get. And yes I adjusted it to move the file out of /var. (the update was to fix a compatibility problem with sunfreeware.com packages) On Wed, Jan 19, 2011 at 10:39 AM, Philip Brown wrote: > On 1/18/11, Peter Bonivart wrote: >> >> 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 Sat Feb 5 17:57:08 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 5 Feb 2011 08:57:08 -0800 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: References: Message-ID: On Sat, Feb 5, 2011 at 8:25 AM, Peter Bonivart wrote: > On Sat, Feb 5, 2011 at 5:13 PM, Philip Brown wrote: >> Case in point: we cant use soft-XXXXp, because openssh decided to use >> "p" in their standard version string. > > Why not? It doesn't have any technical functionality, it's just a > marker. If Yann saw it necessary he could just tack on "patched" there > to distinguish it from openssh's use of "p", like: > > 5.4p1patched,REV=2010.03.25 1. using the full string "patched' is ugly 2. another software might choose to use "patched" there. The only way we can 100% safely put something to the left of REV, is if we use a separator that we choose to be illegal for upstream software revs. ",p" might work, if both pkgutil and pkg-get wont freak out about the extra ",". so, soft-XXXX,p,REV=YYYY.MM.DD ? (side comment: whatever we use, conceptually becomes "rev=" reborn. but at least using ",xx" is much less ugly than REV=xxxx,rev=yyy) From maciej at opencsw.org Sat Feb 5 18:04:20 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 5 Feb 2011 17:04:20 +0000 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: Message-ID: [I forgot to add the policy tag in the subject line of the original post. Apologies. --Maciej] 2011/2/4 Philip Brown : > 2011/2/4 Maciej Blizi?ski : >> ... >> It does add some complexity, I agree. ?But it does it for a good >> reason: we want to avoid other projects accidentally linking to a >> library which was thought to be private, ... > > In other words, to reserve namespace of shared libraries. > > I agree that this is a good thing, and that we should do "something" for it. > However, putting symlinks in /opt/csw/lib to a prefixed library's > location, is a perfectly valid 'something' for this purpose. Yes, I agree that using symlink can be a valid solution. However, using symlinks vs regular files is a tangential issue. Perhaps we should not include anything about files vs symlinks in the proposal. This can be covered by a separate proposal. If you care about this, would you like to put forward a proposal regarding the use of symlinks? Let's continue the shared library placement discussion. How about the following: --------------------8<--------------------- +++ Public shared libraries Public shared libraries, the ones that other software projects can link to, should be kept in /opt/csw/lib. 64-bit libraries should be kept under /opt/csw/lib/amd64 and /opt/csw/lib/sparcv9 on their respective platforms. --------------------8<--------------------- This phrasing is simple, and does not say anything about file types. Does it sound better? Maciej From bwalton at opencsw.org Sat Feb 5 18:11:38 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 05 Feb 2011 12:11:38 -0500 Subject: [csw-maintainers] [policy] Re: [csw-pkgsubmissions] newpkgs rdesktop In-Reply-To: References: <201102031642.p13GgSkJ021403@login.bo.opencsw.org> <00D243A4-2C18-4F39-9F9E-FA5D4AC18DD2@opencsw.org> <1296916260-sup-4100@pinkfloyd.chass.utoronto.ca> Message-ID: <1296925213-sup-4504@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Sat Feb 05 10:44:26 -0500 2011: Hi Peter, > [Moved to maintainers since we're again discussing new policy at > release time while packages are stuck] Thank you. > I don't agree, the version string standard is not very well defined > and if you look in the catalog we have some really ugly ones in > there. Doing the compares solely on REV made it possible to get rid > of the "_rev=foo"-uglyness and move it to the first part > instead. Introducing new stuff there may break package tools as > well. I'm sorry, I wasn't clear on this. I didn't mean specifically tacking it on to the end of the REV= portion, but just noting it as part of the whole version string, of which REV= is a prominent portion. Now that both tools use the date stamp in REV= as the primary version identifier, it would likely be better to place any additional info in the leading upstream version part. We could take a page from the RHEL book here and add a .csw.$localpatchlevel (they use .el5, .el4, etc) or something similar. That makes it more clear than just tacking on 'patched' to the existing version string. $localpatchlevel could monotonically increase for every local feature/bug patch applied that is not part of the upstream source and is not a simple portability patch. When the upstream version changes, this could (possibly) revert to 0 (drop the .csw.$localpatchlevel), etc. > My suggestion is to make it clear that we NEVER have anything after > the REV (any number of dot separated numerics) and make it up to the > maintainer to add "p" to the first (version) part if he sees > fit. That part is not used for version comparison so it's up to the > maintainer what's in it. Phil is right that the tools could be updated to handle this extra info, but I agree that keeping it simpler is better. Any new package that adds this info would also have the REV= string, so version compares would use that and ignore anything in the traditional version string. I believe that the comparison rules for this were such that if one package has REV= and the other doesn't the REV= won by fiat, so that should cleanly accommodate updating old packages 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 Feb 5 18:20:10 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 5 Feb 2011 09:20:10 -0800 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: Message-ID: 2011/2/5 Maciej Blizi?ski : >... > Yes, I agree that using symlink can be a valid solution. ?However, > using symlinks vs regular files is a tangential issue. >.... > > Let's continue the shared library placement discussion. ?How about the > following: > > --------------------8<--------------------- > > +++ Public shared libraries > > Public shared libraries, the ones that other software projects can > link to, should be kept in /opt/csw/lib. >... > --------------------8<--------------------- > > This phrasing is simple, and does not say anything about file types. > Does it sound better? To me, "libraries [..] should be kept in [...]" implies that "the actual library, ie: the file" should be kept in... That would need to be cleared up, to explicitly allow symlinks. From pfelecan at opencsw.org Sat Feb 5 18:40:14 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 05 Feb 2011 18:40:14 +0100 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 5 Feb 2011 17:04:20 +0000") References: Message-ID: Maciej Blizi?ski writes: > --------------------8<--------------------- > > +++ Public shared libraries > > Public shared libraries, the ones that other software projects can > link to, should be kept in /opt/csw/lib. > > 64-bit libraries should be kept under /opt/csw/lib/amd64 and > /opt/csw/lib/sparcv9 on their respective platforms. > > --------------------8<--------------------- > > This phrasing is simple, and does not say anything about file types. > Does it sound better? For me it's alright. -- Peter From maciej at opencsw.org Sat Feb 5 18:42:01 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 5 Feb 2011 17:42:01 +0000 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: Message-ID: 2011/2/5 Philip Brown : > To me, "libraries [..] should be kept in [...]" implies that "the > actual library, ie: the file" should be kept in... > > That would need to be cleared up, to explicitly allow symlinks. Doesn't the word "should" imply that in well-grounded cases a different approach can be used? From bonivart at opencsw.org Sat Feb 5 18:42:24 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 5 Feb 2011 18:42:24 +0100 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: References: Message-ID: On Sat, Feb 5, 2011 at 5:57 PM, Philip Brown wrote: > (side comment: whatever we use, conceptually becomes "rev=" reborn. > but at least using ",xx" is much less ugly than > ? REV=xxxx,rev=yyy) The main problem is all the variants that have existed over the years since the policy is not clear on this. Here's some examples from the current catalog not counting all ugly ones with "_rev=foo": autossh 1.4,REV=2009.06.25_b boincclient 6.7.4,REV=2009.02.05_r17141 mlterm 2.9.3,REV=2007.01.08_i386only mplayer 1.0.0,REV=2007.09.22.rc1try3 radiance 3.8,REV=2008.02.11,i386only squid 2.7,REV=2010.10.05_STABLE9 Let's take this opportunity to set this policy clearly and not be up to interpretation formatting wise. I would like to see some freedom for the content left of REV but the formatting of all parts should be strict. I like "1.2,p,REV=1234.56.78" much better than "1.2,REV=1234.56.78_rev=p", I agree with you there. A quick glance through the pkgutil code didn't reveal any negatives but I would like to set up some tests and get back to you on that. Looking at what's written now at http://www.opencsw.org/extend-it/contribute-packages/build-standards/#versioning, I think it should be allowed (but not to be used unless needed) for more numeric fields than YYYY.MM.DD since that makes it easy to make a package the same day that distinguishes itself from the other one by using, e.g., YYYY.MM.DD.HH.mm. Pkgutil processes any number of these fields until one package "wins". I don't know if you do but it's a suggestion. I also think we should make it clear that the version string is now in three parts where the middle one is optional, the content of it should be from a fixed list which from the start should contain "p" for patched. Something like this: 1.2.3[,x],REV=YYYY.MM.DD[.xx] What do you think? /peter From pfelecan at opencsw.org Sat Feb 5 19:13:35 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 05 Feb 2011 19:13:35 +0100 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 5 Feb 2011 17:42:01 +0000") References: Message-ID: Maciej Blizi?ski writes: > 2011/2/5 Philip Brown : >> To me, "libraries [..] should be kept in [...]" implies that "the >> actual library, ie: the file" should be kept in... >> >> That would need to be cleared up, to explicitly allow symlinks. > > Doesn't the word "should" imply that in well-grounded cases a > different approach can be used? As a assiduous reader of RFCs I'm used to make the distinction between *should* and *must*, i.e., should = recommended but optional, must = mandatory. If everybody agrees that we keep this meaning then the proposal is satisfactory. Probably a meta-policy defining the usage of terms would be a good addition for clarifying the interpretation of policies. -- Peter From phil at bolthole.com Sat Feb 5 23:08:44 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 5 Feb 2011 14:08:44 -0800 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: Message-ID: 2011/2/5 Maciej Blizi?ski : > 2011/2/5 Philip Brown : >> To me, "libraries [..] should be kept in [...]" implies that "the >> actual library, ie: the file" should be kept in... >> >> That would need to be cleared up, to explicitly allow symlinks. > > Doesn't the word "should" imply that in well-grounded cases a > different approach can be used? No it doesnt. I understand what Peter F was saying, reguarding traditional RFC language. But lets make our regs readable to "common folks". Example: If you mean "usually", then say "usually". To most folks, "should" == "must". From phil at bolthole.com Sat Feb 5 23:21:35 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 5 Feb 2011 14:21:35 -0800 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: References: Message-ID: On Sat, Feb 5, 2011 at 9:42 AM, Peter Bonivart wrote: > ... > > Looking at what's written now at > http://www.opencsw.org/extend-it/contribute-packages/build-standards/#versioning, > I think it should be allowed (but not to be used unless needed) for > more numeric fields than YYYY.MM.DD since that makes it easy to make a > package the same day that distinguishes itself from the other one by > using, e.g., YYYY.MM.DD.HH.mm. Pkgutil processes any number of these > fields until one package "wins". I don't know if you do but it's a > suggestion. It is what I have always presumed, and have suggested to folks when needed. Rather than make an explicit "hh.mm" thing, I think it's more than adequate to have YYYY.MM.DD.seqnum We only need a max of 4 fields there for full disambiguation. > > I also think we should make it clear that the version string is now in > three parts where the middle one is optional, the content of it should > be from a fixed list which from the start should contain "p" for > patched. Something like this: > > 1.2.3[,x],REV=YYYY.MM.DD[.xx] > > What do you think? Works for me. Although we should probably make some other recommendations in the writeup such as: - keep the optional field as short as possible. - it is preferred to NOT be present, unless neccessary - current neccessary uses are: ",p", which denotes a feature patch applied by the maintainer. See README for details. Other uses should be discussed on the maintainers list. .. oh I guess we can formalise also, ",sparconly" and ",i386only" Lets avoid people creating 1.2.3,ithinkthisisokaybuttryitandletmeknowmkay,REV=YYYY.MM.DD From bwalton at opencsw.org Sun Feb 6 00:17:14 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 05 Feb 2011 18:17:14 -0500 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: References: Message-ID: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Feb 05 17:21:35 -0500 2011: > Works for me. Although we should probably make some other > recommendations in the writeup such as: > - keep the optional field as short as possible. > - it is preferred to NOT be present, unless neccessary > - current neccessary uses are: ",p", which denotes a feature patch Ok, so it's treated as a 'flag' instead of a value. That works for me. > applied by the maintainer. See README for details. Other uses should > be discussed on the maintainers list. > .. oh I guess we can formalise also, ",sparconly" and ",i386only" Just for clarification, are you saying that a you'd see: 1.2.3,p,sparconly,REV=YYYY.MM.DD I presume so, as the alternate isn't very nice: 1.2.3,psparconly,REV=... A third option is to have only one additional field between upstream version info and REV= that contains single letter sets like: 1.2.3,pi,REV=YYYY.MM.DD where ,pi indicates that it carries a feature patch and is i386only. This would require standardizing the use of letters in this field. > Lets avoid people creating > 1.2.3,ithinkthisisokaybuttryitandletmeknowmkay,REV=YYYY.MM.DD Agreed. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From william at wbonnet.net Sun Feb 6 00:26:46 2011 From: william at wbonnet.net (William Bonnet) Date: Sun, 06 Feb 2011 00:26:46 +0100 Subject: [csw-maintainers] Introducing the QA pages mockup In-Reply-To: <4D47443C.8060401@wbonnet.net> References: <4D47443C.8060401@wbonnet.net> Message-ID: <4D4DDCB6.50507@wbonnet.net> Hi A few pages have been added since the first email, espacially a top level page : http://www-mockup.opencsw.org/qa/ This page will be the starting point for navigation in the QA pages. I still have to add some text in several pages, and icon legend. Missing text should be commited tomorrow. cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From phil at bolthole.com Sun Feb 6 00:34:17 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 5 Feb 2011 15:34:17 -0800 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Feb 5, 2011 at 3:17 PM, Ben Walton wrote: > > Just for clarification, are you saying that a you'd see: > > 1.2.3,p,sparconly,REV=YYYY.MM.DD > > I presume so, as the alternate isn't very nice: > > 1.2.3,psparconly,REV=... oh. Hmmm. I didnt think about multivalues. Hm... From phil at bolthole.com Sun Feb 6 01:41:52 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 5 Feb 2011 16:41:52 -0800 Subject: [csw-maintainers] Introducing the QA pages mockup In-Reply-To: <4D4DDCB6.50507@wbonnet.net> References: <4D47443C.8060401@wbonnet.net> <4D4DDCB6.50507@wbonnet.net> Message-ID: http://www-mockup.opencsw.org/qa/maintainers/retired/ needs to have updated "retired maintainers are not listed here", to be "... with no packages..." On Sat, Feb 5, 2011 at 3:26 PM, William Bonnet wrote: > Hi > > A few pages have been added since the first email, espacially a top level > page : http://www-mockup.opencsw.org/qa/ > > This page will be the starting point for navigation in the QA pages. > > I still have to add some text in several pages, and icon legend. Missing > text should be commited tomorrow. > > cheers > W. > > -- > 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 jcraig at opencsw.org Sun Feb 6 04:03:30 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Sat, 5 Feb 2011 22:03:30 -0500 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: Message-ID: On Sat, Feb 5, 2011 at 5:08 PM, Philip Brown wrote: > 2011/2/5 Maciej Blizi?ski : >> 2011/2/5 Philip Brown : >>> To me, "libraries [..] should be kept in [...]" implies that "the >>> actual library, ie: the file" should be kept in... >>> >>> That would need to be cleared up, to explicitly allow symlinks. >> >> Doesn't the word "should" imply that in well-grounded cases a >> different approach can be used? > > No it doesnt. > > I understand what Peter F was saying, reguarding traditional RFC language. > But lets make our regs readable to "common folks". > > Example: If you mean "usually", then say "usually". > To most folks, "should" == "must". no "should == should", "must == must". If you believe "should == must" then this could explain some of the infighting on the release process. How can one argue against the precise application of language. Leaving wiggle room just opens the process up to boundary cases. If we go with "should == must" then what do we use for "should == should". Why have policy if your not going to use enforceable terms. (hold breath; count ten; sorry; rant-off) Sorry for the sharp reply but I've just come off the week from on-call hell and this seems a silly argument. Jon From bonivart at opencsw.org Sun Feb 6 06:06:37 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 6 Feb 2011 06:06:37 +0100 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Feb 6, 2011 at 12:17 AM, Ben Walton wrote: > Just for clarification, are you saying that a you'd see: > > 1.2.3,p,sparconly,REV=YYYY.MM.DD This does not look good. > I presume so, as the alternate isn't very nice: > > 1.2.3,psparconly,REV=... Neither does this. > A third option is to have only one additional field between upstream > version info and REV= that contains single letter sets like: > > 1.2.3,pi,REV=YYYY.MM.DD This is the best in my opinion. Let's treat it as flags and only allow to pick from a fixed list to keep it from getting carried away and be easily checked. p = patched i = i386 only s = sparc only >> Lets avoid people creating >> 1.2.3,ithinkthisisokaybuttryitandletmeknowmkay,REV=YYYY.MM.DD This will also be hard to automatically check. /peter From maciej at opencsw.org Sun Feb 6 11:21:23 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 6 Feb 2011 10:21:23 +0000 Subject: [csw-maintainers] Config files with and without .CSW postfix and the same base name Message-ID: I've discovered a potential issue with configuration files. One package may ship a configuration file directly, while other may ship a file with the .CSW postfix. For example, /etc/opt/csw/mime.types.CSW is shipped by CSWmutt-base, while CSWhtdig ships /etc/opt/csw/mime.types. When CSWmutt-base is installed first, subsequent installation of CSWhtdig will overwrite the mime.types file. Should we consider this scenario a file collision? Maciej From maciej at opencsw.org Sun Feb 6 12:27:23 2011 From: maciej at opencsw.org (Maciej Blizinski) Date: Sun, 6 Feb 2011 12:27:23 +0100 Subject: [csw-maintainers] =?utf-8?q?=5BPOLICY=5D_opencsw-policy=3A_Abstra?= =?utf-8?q?ct_and_copyright?= Message-ID: <1296991643-28680-1-git-send-email-maciej@opencsw.org> Hello fellow maintainers, The topic of policy codification has been stuck on format discussions for last couple of weeks. It'd like to continue, under the assumption that there isn't that much interest in working with formats, and I can continue using asciidoc. I'd like to start laying the groundwork of the policy document. I'll be sending it in reasonably sized chunks, so that we can agree and commit them bit by bit. Here's the first chunk, which is a rough copy of the Debian policy manual abstract and copyright notice. It also defines the license as GPL 2.0+. Please provide your comments. If maintainers are OK with this change, I'll submit it to the code repository. Maciej --- pkg/opencsw-policy/trunk/Makefile | 7 +++-- pkg/opencsw-policy/trunk/checksums | 2 +- pkg/opencsw-policy/trunk/files/index.txt | 36 +++++++++++++++++++++++++++++- 3 files changed, 40 insertions(+), 5 deletions(-) diff --git a/pkg/opencsw-policy/trunk/Makefile b/pkg/opencsw-policy/trunk/Makefile index e2f2c18..698e2d0 100644 --- a/pkg/opencsw-policy/trunk/Makefile +++ b/pkg/opencsw-policy/trunk/Makefile @@ -10,14 +10,14 @@ define BLURB endef SPKG_SOURCEURL = http://www.opencsw.org MASTER_SITES = http://www.gnu.org/licenses/ -DISTFILES = fdl-1.3.txt +DISTFILES = gpl-2.0.txt CONFIGURE_SCRIPTS = BUILD_SCRIPTS = policy INSTALL_SCRIPTS = policy TEST_SCRIPTS = ARCHALL_CSWopencsw-policy = 1 CATALOGNAME_CSWopencsw-policy = opencsw_policy -LICENSE = fdl-1.3.txt +LICENSE = gpl-2.0.txt BUILD_DEP_PKGS = CSWasciidoc @@ -41,6 +41,7 @@ install-policy: @$(MAKECOOKIE) post-merge: + # For testing purposes if [ -d $(HOME)/public_html/policy ]; then \ - cp $(PKGROOT)/opt/csw/share/doc/opencsw_policy/index.html $(HOME)/public_html/policy; \ + rsync -vr $(PKGROOT)/opt/csw/share/doc/opencsw_policy/ $(HOME)/public_html/policy; \ fi diff --git a/pkg/opencsw-policy/trunk/checksums b/pkg/opencsw-policy/trunk/checksums index e6fa4f0..6986890 100644 --- a/pkg/opencsw-policy/trunk/checksums +++ b/pkg/opencsw-policy/trunk/checksums @@ -1 +1 @@ -10b9de612d532fdeeb7fe8fcd1435cc6 fdl-1.3.txt +b234ee4d69f5fce4486a80fdaf4a4263 gpl-2.0.txt diff --git a/pkg/opencsw-policy/trunk/files/index.txt b/pkg/opencsw-policy/trunk/files/index.txt index 7e9ee64..fbb183c 100644 --- a/pkg/opencsw-policy/trunk/files/index.txt +++ b/pkg/opencsw-policy/trunk/files/index.txt @@ -3,5 +3,39 @@ OpenCSW packaging policy $Id: Makefile 11888 2010-12-12 12:43:48Z skayser $ :toc: :website: http://www.opencsw.org - :leveloffset: 1 + +Abstract +======== + +This manual describes the policy requirements for the OpenCSW package +catalog. This includes the structure and contents of the OpenCSW package +catalog and several design issues of OpenCSW packages, as well as +technical requirements that each package must satisfy to be included in +the distribution. + +Copyright Notice +================ + +Copyright ? 2011 OpenCSW + +Parts of this manual are copied from the Debian GNU/Linux policy manual. +This manual is released with compliance with Debian manual's licensing +terms. + +This manual is free software; you may redistribute it and/or modify it +under the terms of the GNU General Public License as published by the +Free Software Foundation; either version 2, or (at your option) any +later version. + +This is distributed in the hope that it will be useful, but without any +warranty; without even the implied warranty of merchantability or +fitness for a particular purpose. See the GNU General Public License for +more details. + +A copy of the GNU General Public License is available on the World Wide +Web at the GNU General Public Licence. You can also obtain it by writing +to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, +Boston, MA 02110-1301, USA. + +include::shared-csw-opt.txt[] -- 1.7.3.2 From maciej at opencsw.org Sun Feb 6 12:41:06 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 6 Feb 2011 11:41:06 +0000 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: Message-ID: 2011/2/5 Philip Brown : > 2011/2/5 Maciej Blizi?ski : >> 2011/2/5 Philip Brown : >>> To me, "libraries [..] should be kept in [...]" implies that "the >>> actual library, ie: the file" should be kept in... >>> >>> That would need to be cleared up, to explicitly allow symlinks. >> >> Doesn't the word "should" imply that in well-grounded cases a >> different approach can be used? > > No it doesnt. > > I understand what Peter F was saying, reguarding traditional RFC language. > But lets make our regs readable to "common folks". > > Example: If you mean "usually", then say "usually". > To most folks, "should" == "must". Even if you reject RFC 2119[1] (which is a shame), we still do need to find a way to express ideas described in it. Would you like to propose an alternative? Maciej [1] http://www.ietf.org/rfc/rfc2119.txt From pfelecan at opencsw.org Sun Feb 6 12:43:37 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 06 Feb 2011 12:43:37 +0100 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: (Philip Brown's message of "Sat, 5 Feb 2011 14:08:44 -0800") References: Message-ID: Philip Brown writes: > 2011/2/5 Maciej Blizi?ski : >> 2011/2/5 Philip Brown : >>> To me, "libraries [..] should be kept in [...]" implies that "the >>> actual library, ie: the file" should be kept in... >>> >>> That would need to be cleared up, to explicitly allow symlinks. >> >> Doesn't the word "should" imply that in well-grounded cases a >> different approach can be used? > > No it doesnt. > > I understand what Peter F was saying, reguarding traditional RFC language. > But lets make our regs readable to "common folks". The policies public/readership is not "common folks", whatever is that, but computer scientists, engineers, &c, i.e literates. > Example: If you mean "usually", then say "usually". > To most folks, "should" == "must". This is so profoundly wrong that I'm on the point of fainting... -- Peter From pfelecan at opencsw.org Sun Feb 6 12:46:58 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 06 Feb 2011 12:46:58 +0100 Subject: [csw-maintainers] Config files with and without .CSW postfix and the same base name In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 6 Feb 2011 10:21:23 +0000") References: Message-ID: Maciej Blizi?ski writes: > I've discovered a potential issue with configuration files. One > package may ship a configuration file directly, while other may ship a > file with the .CSW postfix. For example, /etc/opt/csw/mime.types.CSW > is shipped by CSWmutt-base, while CSWhtdig ships > /etc/opt/csw/mime.types. When CSWmutt-base is installed first, > subsequent installation of CSWhtdig will overwrite the mime.types > file. > > Should we consider this scenario a file collision? Yes. A potential collision. IMO, this mime.types is so generic that I would think that it belongs in a specific package, maybe a common one. Or, I don't fully understand this mime.types stuff. -- Peter From pfelecan at opencsw.org Sun Feb 6 12:54:08 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 06 Feb 2011 12:54:08 +0100 Subject: [csw-maintainers] [POLICY] opencsw-policy: Abstract and copyright In-Reply-To: <1296991643-28680-1-git-send-email-maciej@opencsw.org> (Maciej Blizinski's message of "Sun, 6 Feb 2011 12:27:23 +0100") References: <1296991643-28680-1-git-send-email-maciej@opencsw.org> Message-ID: Maciej Blizinski writes: > Please provide your comments. If maintainers are OK with this change, I'll > submit it to the code repository. What's the repository's address? > +Abstract > +======== > + > +This manual describes the policy requirements for the OpenCSW package > +catalog. This includes the structure and contents of the OpenCSW package > +catalog and several design issues of OpenCSW packages, as well as > +technical requirements that each package must satisfy to be included in > +the distribution. I don't like the term "OpenCSW package catalog". What about "OpenCSW package distribution"? It seems to me that it better reflects the subject; BTW, the final word is exactly that: "distribution". Consequently, here is the revised text: This manual describes the policy requirements for the OpenCSW package distribution. This includes the structure and contents of the OpenCSW package distribution and several design issues of OpenCSW packages, as well as technical requirements that each package must satisfy to be included in the distribution. -- Peter From maciej at opencsw.org Sun Feb 6 13:21:02 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 6 Feb 2011 12:21:02 +0000 Subject: [csw-maintainers] [POLICY] opencsw-policy: Abstract and copyright In-Reply-To: References: <1296991643-28680-1-git-send-email-maciej@opencsw.org> Message-ID: 2011/2/6 Peter FELECAN : > Maciej Blizinski writes: > >> Please provide your comments. ?If maintainers are OK with this change, I'll >> submit it to the code repository. > > What's the repository's address? Right now, files are in our main repository: https://gar.svn.sourceforge.net/svnroot/gar/ We had a discussion about having our own repository for the policy. We didn't arrive at any concrete solution, so I went with the default. >> +Abstract >> +======== >> + >> +This manual describes the policy requirements for the OpenCSW package >> +catalog. This includes the structure and contents of the OpenCSW package >> +catalog and several design issues of OpenCSW packages, as well as >> +technical requirements that each package must satisfy to be included in >> +the distribution. > > I don't like the term "OpenCSW package catalog". What about "OpenCSW > package distribution"? It seems to me that it better reflects the > subject; BTW, the final word is exactly that: > "distribution". Consequently, here is the revised text: > > This manual describes the policy requirements for the OpenCSW package > distribution. This includes the structure and contents of the OpenCSW > package distribution and several design issues of OpenCSW packages, as > well as technical requirements that each package must satisfy to be > included in the distribution. Done. I'll send out the updated patch. From maciej at opencsw.org Sun Feb 6 13:23:00 2011 From: maciej at opencsw.org (Maciej Blizinski) Date: Sun, 6 Feb 2011 13:23:00 +0100 Subject: [csw-maintainers] =?utf-8?q?=5BPATCH=5D_opencsw-policy=3A_Abstrac?= =?utf-8?q?t_and_copyright?= In-Reply-To: References: Message-ID: <1296994980-22573-1-git-send-email-maciej@opencsw.org> This change: - sets the license to GPL 2.0+ - adds abstract - adds a copyright notice --- pkg/opencsw-policy/trunk/Makefile | 7 +++-- pkg/opencsw-policy/trunk/checksums | 2 +- pkg/opencsw-policy/trunk/files/index.txt | 36 +++++++++++++++++++++++++++++- 3 files changed, 40 insertions(+), 5 deletions(-) diff --git a/pkg/opencsw-policy/trunk/Makefile b/pkg/opencsw-policy/trunk/Makefile index e2f2c18..698e2d0 100644 --- a/pkg/opencsw-policy/trunk/Makefile +++ b/pkg/opencsw-policy/trunk/Makefile @@ -10,14 +10,14 @@ define BLURB endef SPKG_SOURCEURL = http://www.opencsw.org MASTER_SITES = http://www.gnu.org/licenses/ -DISTFILES = fdl-1.3.txt +DISTFILES = gpl-2.0.txt CONFIGURE_SCRIPTS = BUILD_SCRIPTS = policy INSTALL_SCRIPTS = policy TEST_SCRIPTS = ARCHALL_CSWopencsw-policy = 1 CATALOGNAME_CSWopencsw-policy = opencsw_policy -LICENSE = fdl-1.3.txt +LICENSE = gpl-2.0.txt BUILD_DEP_PKGS = CSWasciidoc @@ -41,6 +41,7 @@ install-policy: @$(MAKECOOKIE) post-merge: + # For testing purposes if [ -d $(HOME)/public_html/policy ]; then \ - cp $(PKGROOT)/opt/csw/share/doc/opencsw_policy/index.html $(HOME)/public_html/policy; \ + rsync -vr $(PKGROOT)/opt/csw/share/doc/opencsw_policy/ $(HOME)/public_html/policy; \ fi diff --git a/pkg/opencsw-policy/trunk/checksums b/pkg/opencsw-policy/trunk/checksums index e6fa4f0..6986890 100644 --- a/pkg/opencsw-policy/trunk/checksums +++ b/pkg/opencsw-policy/trunk/checksums @@ -1 +1 @@ -10b9de612d532fdeeb7fe8fcd1435cc6 fdl-1.3.txt +b234ee4d69f5fce4486a80fdaf4a4263 gpl-2.0.txt diff --git a/pkg/opencsw-policy/trunk/files/index.txt b/pkg/opencsw-policy/trunk/files/index.txt index 7e9ee64..a889537 100644 --- a/pkg/opencsw-policy/trunk/files/index.txt +++ b/pkg/opencsw-policy/trunk/files/index.txt @@ -3,5 +3,39 @@ OpenCSW packaging policy $Id: Makefile 11888 2010-12-12 12:43:48Z skayser $ :toc: :website: http://www.opencsw.org - :leveloffset: 1 + +Abstract +======== + +This manual describes the policy requirements for the OpenCSW package +distribution. This includes the structure and contents of the OpenCSW +package distribution and several design issues of OpenCSW packages, +as well as technical requirements that each package must satisfy to be +included in the distribution. + +Copyright Notice +================ + +Copyright ? 2011 OpenCSW + +Parts of this manual are copied from the Debian GNU/Linux policy manual. +This manual is released with compliance with Debian manual's licensing +terms. + +This manual is free software; you may redistribute it and/or modify it +under the terms of the GNU General Public License as published by the +Free Software Foundation; either version 2, or (at your option) any +later version. + +This is distributed in the hope that it will be useful, but without any +warranty; without even the implied warranty of merchantability or +fitness for a particular purpose. See the GNU General Public License for +more details. + +A copy of the GNU General Public License is available on the World Wide +Web at the GNU General Public Licence. You can also obtain it by writing +to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, +Boston, MA 02110-1301, USA. + +include::shared-csw-opt.txt[] -- 1.7.3.2 From bwalton at opencsw.org Sun Feb 6 14:48:06 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 06 Feb 2011 08:48:06 -0500 Subject: [csw-maintainers] Config files with and without .CSW postfix and the same base name In-Reply-To: References: Message-ID: <1296999964-sup-5175@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sun Feb 06 06:46:58 -0500 2011: > Yes. A potential collision. IMO, this mime.types is so generic that > I would think that it belongs in a specific package, maybe a common > one. Or, I don't fully understand this mime.types stuff. It's not a bad idea to share it via a common package. Does anyone know how frequently the contents of mime.types changes? If it's glacial, it could go in CSWcommon. Otherwise, a separate CSWmimetypes (or similar) package would get my recommendation. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Feb 6 15:44:11 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 06 Feb 2011 09:44:11 -0500 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: Message-ID: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Feb 05 17:08:44 -0500 2011: > > Doesn't the word "should" imply that in well-grounded cases a > > different approach can be used? > > No it doesnt. > > I understand what Peter F was saying, reguarding traditional RFC > language. But lets make our regs readable to "common folks". > > Example: If you mean "usually", then say "usually". To most folks, > "should" == "must". I don't think this is a case where you want to dumb down the language and make it run contrary to commonly accepted usage in other contexts (RFC's etc). That is asking for confusion and it would ultimate lessen the value of these documents. The target audience is perfectly capable of understanding should vs must and we're not writing for anyone else. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sun Feb 6 17:04:37 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 6 Feb 2011 08:04:37 -0800 Subject: [csw-maintainers] Config files with and without .CSW postfix and the same base name In-Reply-To: References: Message-ID: 2011/2/6 Maciej Blizi?ski : > I've discovered a potential issue with configuration files. ?One > package may ship a configuration file directly, while other may ship a > file with the .CSW postfix. ?For example, /etc/opt/csw/mime.types.CSW > is shipped by CSWmutt-base, while CSWhtdig ships > /etc/opt/csw/mime.types. ?When CSWmutt-base is installed first, > subsequent installation of CSWhtdig will overwrite the mime.types > file. > > Should we consider this scenario a file collision? reguardless of file collision or not, htdig is doing it *wrong*. it should never ship "mime.types" directly. But yes its a collision too, and probably a shared mime-types package could be a good thing. From phil at bolthole.com Sun Feb 6 17:07:02 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 6 Feb 2011 08:07:02 -0800 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> References: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Feb 6, 2011 at 6:44 AM, Ben Walton wrote: > > I don't think this is a case where you want to dumb down the language > and make it run contrary to commonly accepted usage in other contexts > (RFC's etc). people complain about the language of the RFCs, too :) but, reguardless: I'll withdraw my objection, as long as we copy the RFC methodology of including a "key" to terms. Explicitly stating in the document, or in a page directly linked from that document, what "must, should, may", etc mean in our context. From phil at bolthole.com Sun Feb 6 17:08:42 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 6 Feb 2011 08:08:42 -0800 Subject: [csw-maintainers] [POLICY] opencsw-policy: Abstract and copyright In-Reply-To: <1296991643-28680-1-git-send-email-maciej@opencsw.org> References: <1296991643-28680-1-git-send-email-maciej@opencsw.org> Message-ID: On Sun, Feb 6, 2011 at 3:27 AM, Maciej Blizinski wrote: > Hello fellow maintainers, > > The topic of policy codification has been stuck on format discussions for last > couple of weeks. ?It'd like to continue, under the assumption that there isn't > that much interest in working with formats, and I can continue using asciidoc. > For the record, after poking at it some more, I'm okay with asciidoc. From william at wbonnet.net Sun Feb 6 21:44:47 2011 From: william at wbonnet.net (William Bonnet) Date: Sun, 06 Feb 2011 21:44:47 +0100 Subject: [csw-maintainers] Introducing the QA pages mockup In-Reply-To: References: <4D47443C.8060401@wbonnet.net> <4D4DDCB6.50507@wbonnet.net> Message-ID: <4D4F083F.5030006@wbonnet.net> Hi > http://www-mockup.opencsw.org/qa/maintainers/retired/ > > needs to have updated "retired maintainers are not listed here", to be > "... with no packages..." Fixed, thanks for the report cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From william at wbonnet.net Sun Feb 6 21:57:15 2011 From: william at wbonnet.net (William Bonnet) Date: Sun, 06 Feb 2011 21:57:15 +0100 Subject: [csw-maintainers] Introducing the QA pages mockup In-Reply-To: References: <4D47443C.8060401@wbonnet.net> Message-ID: <4D4F0B2B.4070902@wbonnet.net> On 01/02/2011 00:59, Philip Brown wrote: > orphaned packages, are packages whose maintainer has retired. The > maintainer may or may not be available to answer questions about it Fixed -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From maciej at opencsw.org Sun Feb 6 23:26:03 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 6 Feb 2011 22:26:03 +0000 Subject: [csw-maintainers] [POLICY] Policy-team Message-ID: I have an idea about the process of codification of our policy. The general idea is that we do it together as a community. One person prepares a change, and sends it out so others can see it and comment on it. When the change is accepted, it can be committed to the repository. To make the process work smoothly, the person who sent the change, needs to know when is it okay to submit the patch. On our mailing lists, things usually work the way that whenever a proposal is submitted, comments provided are primarily criticisms. Proposals are pass when critical voices fade away. I'd like to suggest to add a new element to the process. There probably are people who are interested in the policy making more than others. I guess that it would be probably three or four people. Let's call them policy-team. When a new patch is sent out, policy-team reads it, and if the patch looks good to them, they respond: "looks good". If there are criticisms, they need to be addressed as usual; however, if there are no criticisms, there will be 2 or 3 affirmative voices, which will constitute a basis to submit a patch. It's not that only the policy-team people would take part in policy making. All patches would be sent to the mailing list, and every maintainer would have an opportunity to read and respond. The idea behind policy-team is to have a group of people who will always respond to a policy related patch, stating whether they support the change or not, and helping the process go forward. Volunteers? Thoughts? Maciej From william at wbonnet.net Mon Feb 7 00:43:21 2011 From: william at wbonnet.net (William Bonnet) Date: Mon, 07 Feb 2011 00:43:21 +0100 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: <4D4F3219.7010401@wbonnet.net> Hi > Volunteers? Not me ;) > Thoughts? But this is a very good idea. I support it . cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From phil at bolthole.com Mon Feb 7 01:12:46 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 6 Feb 2011 16:12:46 -0800 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: 2011/2/6 Maciej Blizi?ski : > I have an idea about the process of codification of our policy. ?The > general idea is that we do it together as a community. ?One person > prepares a change, and sends it out so others can see it and comment > on it. ?When the change is accepted, it can be committed to the > repository. > > To make the process work smoothly, the person who sent the change, > needs to know when is it okay to submit the patch. ?On our mailing > lists, things usually work the way that whenever a proposal is > submitted, comments provided are primarily criticisms. ?Proposals are > pass when critical voices fade away. and if they dont? what triggers a vote? Is there a mandatory discusion period length? and what is the threshold for a a change in policy to pass? Given our small size, I dont think that "simple majority" is a good idea. and should we have different voting threshholds for new policies, vs changing existing ones? > Volunteers? ?Thoughts? I would volunteer From pfelecan at opencsw.org Mon Feb 7 10:05:03 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 07 Feb 2011 10:05:03 +0100 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 6 Feb 2011 22:26:03 +0000") References: Message-ID: Maciej Blizi?ski writes: > Volunteers? Thoughts? As I'm strongly interested in policy I would like to be part of the team and fully understand that the policy team doesn't have a special vote but a special role. -- Peter From pfelecan at opencsw.org Mon Feb 7 10:10:23 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 07 Feb 2011 10:10:23 +0100 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: (Philip Brown's message of "Sun, 6 Feb 2011 16:12:46 -0800") References: Message-ID: Philip Brown writes: > 2011/2/6 Maciej Blizi?ski : >> I have an idea about the process of codification of our policy. ?The >> general idea is that we do it together as a community. ?One person >> prepares a change, and sends it out so others can see it and comment >> on it. ?When the change is accepted, it can be committed to the >> repository. >> >> To make the process work smoothly, the person who sent the change, >> needs to know when is it okay to submit the patch. ?On our mailing >> lists, things usually work the way that whenever a proposal is >> submitted, comments provided are primarily criticisms. ?Proposals are >> pass when critical voices fade away. > > and if they dont? what triggers a vote? Is there a mandatory > discusion period length? A policy is implemented when a majority agreed on it, by consensus or formal vote, if needed. > and what is the threshold for a a change in policy to pass? Given our > small size, I dont think that "simple majority" is a good idea. > and should we have different voting threshholds for new policies, vs > changing existing ones? On the contrary, given our small number I think that the simple majority is a very good thing. In any truthful elective system those who vote form the active electoral set and the majority is formed in that set. -- Peter From maciej at opencsw.org Mon Feb 7 10:17:10 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 7 Feb 2011 09:17:10 +0000 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: 2011/2/7 Philip Brown : > 2011/2/6 Maciej Blizi?ski : >> I have an idea about the process of codification of our policy. ?The >> general idea is that we do it together as a community. ?One person >> prepares a change, and sends it out so others can see it and comment >> on it. ?When the change is accepted, it can be committed to the >> repository. >> >> To make the process work smoothly, the person who sent the change, >> needs to know when is it okay to submit the patch. ?On our mailing >> lists, things usually work the way that whenever a proposal is >> submitted, comments provided are primarily criticisms. ?Proposals are >> pass when critical voices fade away. > > and if they dont? ?what triggers a vote? I would guess that vote is the right thing to do when a discussion reaches an impasse. The trigger would be one of the sides (or both) to call for it by sending an e-mail to the mailing list. > Is there a mandatory > discusion period length? I would like not to define a mandatory length. It depends on the change, some will require a discussion, but not all. > and what is the threshold for a a change in policy to pass? Given our > small size, I dont think that "simple majority" is a good idea. I certainly hope that in most cases, policy changes will happen by consensus, not by vote. If a community has to vote a lot, it's a sign of community's problems. (Although on the other hand, if a community does have problems, it's better to diagnose them as quickly as possible, so I'm not saying we shouldn't vote.) You've been often stressing that even initially popular ideas might turn out to be flawed. I agree that popular support is not a guarantee that one choice is better than the other. That's why when a discussion is held, all sides need to present their arguments well. However, I don't see that as a basis to reject the democratic process of policy making, and I don't see a better alternative. > and should we have different voting threshholds for new policies, vs > changing existing ones? I'd like to distinguish between two separate activities: - policy making - policy codification The two may be done at the same time, but aren't necessarily identical. Of course, these two activities are related, and it's impossible to do one without the other. I would like us to primarily focus on codification, at least for the time being. In codification, the discussions would primarily regard wording, and potentially document structure. I would like us to take the existing, preferably uncontroversial elements of our policy, and start giving them the shape of a document that can be put online. Regarding voting thresholds, I don't have an opinion on that. I guess that the higher the threshold, the easier it is for a minority to block a change. I don't know what the optimal values are. I'd be interested to hear about ways to establish such thresholds and their effects. I was personally thinking about a simple 50% threshold. I'd also like to repeat I do hope we will be working by consensus. >> Volunteers? ?Thoughts? > > I would volunteer Cool. I also saw a response from Peter Felecan, so we have three people already, excellent. Anybody else? From hson at opencsw.org Mon Feb 7 12:45:56 2011 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 07 Feb 2011 12:45:56 +0100 Subject: [csw-maintainers] Anyone like to use graphics proggies? (gimp) In-Reply-To: <60288847-C871-4AF2-9CF6-04A803771AD1@opencsw.org> References: <60288847-C871-4AF2-9CF6-04A803771AD1@opencsw.org> Message-ID: <4D4FDB74.1050009@opencsw.org> On 2011-02-02 08:25, Dagobert Michelsen wrote: > Hi, > > Am 01.02.2011 um 19:56 schrieb Philip Brown: >> Our current gimp was compiled by me. It was really mostly a quickie >> "do our new gtk libs work" test. I'm not a regular user of the thing. >> As such, is anyone willing to take it over and compile the latest? >> >> We have an "upgrade" request, and I dont really have time to deal with >> it properly at the moment. > > > Roger, it would also be cool if we could release imagemagick64. Is there > something missing? > I'll have to recheck to see if all these X11 rebuilds might have gotten us closer... From phil at bolthole.com Mon Feb 7 16:07:42 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Feb 2011 07:07:42 -0800 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: 2011/2/7 Maciej Blizi?ski : > ... > Regarding voting thresholds, I don't have an opinion on that. ?I guess > that the higher the threshold, the easier it is for a minority to > block a change. It's a zero sum game, The flip side of the above is, the lower the threshold is, the easier it is for "dumb ideas in the long run" to get through. Given your original premise of attempting to get "general consensus" before making policy, 50% sounds contradictory to that. 75% agreement sounds closer to that principle. From jcraig at opencsw.org Mon Feb 7 16:38:39 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Mon, 7 Feb 2011 10:38:39 -0500 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: On Mon, Feb 7, 2011 at 10:07 AM, Philip Brown wrote: > 2011/2/7 Maciej Blizi?ski : >> ... >> Regarding voting thresholds, I don't have an opinion on that. ?I guess >> that the higher the threshold, the easier it is for a minority to >> block a change. > > It's a zero sum game, The flip side of the above is, the lower the > threshold is, the easier it is for "dumb ideas in the long run" to get > through. > > Given your original premise of attempting to get "general consensus" > before making policy, 50% sounds contradictory to that. > 75% agreement sounds closer to that principle. As a middle ground a simple majority could approve a change with a minimum discussion time that allows full discourse. A super majority could approve a change and bypass/limit the minimum discussion. This help prevent the ramrodding of questionable items while speeding along items with consensus. majority - 50% - 1 week super majority - 75% - 2 day consensus - 100% - no minimum From pfelecan at opencsw.org Mon Feb 7 16:55:23 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 07 Feb 2011 16:55:23 +0100 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: (Jonathan Craig's message of "Mon, 7 Feb 2011 10:38:39 -0500") References: Message-ID: Jonathan Craig writes: > On Mon, Feb 7, 2011 at 10:07 AM, Philip Brown wrote: >> 2011/2/7 Maciej Blizi?ski : >>> ... >>> Regarding voting thresholds, I don't have an opinion on that. ?I guess >>> that the higher the threshold, the easier it is for a minority to >>> block a change. >> >> It's a zero sum game, The flip side of the above is, the lower the >> threshold is, the easier it is for "dumb ideas in the long run" to get >> through. >> >> Given your original premise of attempting to get "general consensus" >> before making policy, 50% sounds contradictory to that. >> 75% agreement sounds closer to that principle. > > As a middle ground a simple majority could approve a change with a > minimum discussion time that allows full discourse. A super majority > could approve a change and bypass/limit the minimum discussion. This > help prevent the ramrodding of questionable items while speeding along > items with consensus. > > majority - 50% - 1 week > super majority - 75% - 2 day > consensus - 100% - no minimum This is nice but utterly complicated. What's wrong with majority as defined: The greater number; more than half; as, a majority of mankind; a majority of the votes cast. [1913 Webster] The amount or number by which one aggregate exceeds all other aggregates with which it is contrasted; especially, the number by which the votes for a successful candidate exceed those for all other candidates; as, he is elected by a majority of five hundred votes. See {Plurality}. [1913 Webster] (elections) more than half of the votes [syn: {majority}, {absolute majority}] for the sake of completeness, consensus: agreement in the judgment or opinion reached by a group as a whole; "the lack of consensus reflected differences in theoretical positions"; "those rights and obligations are based on an unstated consensus" Let's say that if there is no consensus after 1 week we proceed to a vote. Note that I agree with Maciej that if we reach consensus rarely and vote often there is an issue in the community. Lets observe where the consensus gets stuck. -- Peter From sirtobi at unix-ag.uni-hannover.de Tue Feb 1 23:36:52 2011 From: sirtobi at unix-ag.uni-hannover.de (sirtobi at unix-ag.uni-hannover.de) Date: Tue, 1 Feb 2011 21:36:52 -0100 Subject: [csw-maintainers] How to get out of the project... In-Reply-To: References: Message-ID: <20110201213652.3ae998c3@sirtobi.com> Hi there, I have a kind of pitty question but cant find the answer on the web... I want to be removed from the lists and I dont need any account anymore. Especially removing me from the lists would be great. Some years ago I was a student with a lot of free time. I became a Maintainer for my own project "gtklp". It was a cool time and I enjoyed being part of the Project. But the times have changed. As some of you may have noticed "gtklp" wasnt updated for years. I got a job, a wife and a very cute little girl laste june. This month I bought a house with a big garden. These are new big "projects" and so my software projects are nearly stalled. So please remove me from the lists. I wish all of you a great future and cool times, many greetings and goodbye, sirtobi From phil at bolthole.com Mon Feb 7 18:02:18 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Feb 2011 09:02:18 -0800 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: On 2/7/11, Peter FELECAN wrote: > > This is nice but utterly complicated. What's wrong with majority as > defined: >... Because 51% in favour, can mean 49% vehemently against, yet it still passes. Having a policy passed, that pisses off 49% of active maintainers, is never a good idea. From phil at bolthole.com Mon Feb 7 18:04:29 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Feb 2011 09:04:29 -0800 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: On 2/7/11, Jonathan Craig wrote: > On Mon, Feb 7, 2011 at 10:07 AM, Philip Brown wrote: >>... > majority - 50% - 1 week > super majority - 75% - 2 day > consensus - 100% - no minimum > We're talking about *policy* here. Not "what color should we paint the website", but formal, ideally not-changing-in-the-future, policy. In my opinion, there should be a *minimum* of 1 week discussion period, for all policy decisions. If it isnt important enough to reserve a week's period of time for discussion for it, then it doesnt belong as "policy" in the first place. From phil at bolthole.com Mon Feb 7 18:16:50 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Feb 2011 09:16:50 -0800 Subject: [csw-maintainers] How to get out of the project... In-Reply-To: <20110201213652.3ae998c3@sirtobi.com> References: <20110201213652.3ae998c3@sirtobi.com> Message-ID: On 2/1/11, sirtobi at unix-ag.uni-hannover.de wrote: > Hi there, > > I have a kind of pitty question but cant find the answer on the web... > I want to be removed from the lists and I dont need any account > anymore. Especially removing me from the lists would be great. > Congratulations on your family :) for future reference, emailing the board list (board@ ...) is the appropriate thing to do. I'm sure they'll take it from here though. From bwalton at opencsw.org Mon Feb 7 18:25:17 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Feb 2011 12:25:17 -0500 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> Message-ID: <1297099461-sup-1716@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sun Feb 06 11:07:02 -0500 2011: > people complain about the language of the RFCs, too :) And our newspapers are written to a sixth grade reading level. :) > but, reguardless: I'll withdraw my objection, as long as we copy the > RFC methodology of including a "key" to terms. Explicitly stating in > the document, or in a page directly linked from that document, what > "must, should, may", etc mean in our context. Works for me. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Tue Feb 8 00:10:37 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 7 Feb 2011 23:10:37 +0000 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: <1297099461-sup-1716@pinkfloyd.chass.utoronto.ca> References: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> <1297099461-sup-1716@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/7 Ben Walton : > Excerpts from Philip Brown's message of Sun Feb 06 11:07:02 -0500 2011: > >> people complain about the language of the RFCs, too :) > > And our newspapers are written to a sixth grade reading level. :) > >> but, reguardless: I'll withdraw my objection, as long as we copy the >> RFC methodology of including a "key" to terms. Explicitly stating in >> the document, or in a page directly linked from that document, what >> "must, should, may", etc mean in our context. > > Works for me. I've updated the wiki page, adding a reference to RFC 2119. I've also added the suggestion that --prefix can be used together with --libdir. Please take another look. http://wiki.opencsw.org/proposal:shared-library-placement From phil at bolthole.com Tue Feb 8 01:51:50 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Feb 2011 16:51:50 -0800 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> <1297099461-sup-1716@pinkfloyd.chass.utoronto.ca> Message-ID: On 2/7/11, Maciej Blizi?ski wrote: > > I've updated the wiki page, adding a reference to RFC 2119. no, please dont "make a reference to rfcs". Our standards should be self-contained. Please take the appropriate section, write it in normal-people language as much as possible, and put it on our own pages. in the interests of time, here is a concrete example for you: ------------------------------------------------------------------------ Usage of standard words in our standards documents: "Must" - means every package is required to be this way "Should" - means that under normal circumstances, packages are expected to be this way, with occassional exceptions with justifications allowed "May" - draws attention to an optional feature, which, even though it is not common, is explicitly allowed ---------------------------------------------------------------------------- PS: RFC2119 uses A LOT of CAPITALS. For EMPHASIS. I thought you said that using CAPITALS, was RUDE? :-D From phil at bolthole.com Tue Feb 8 01:54:19 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Feb 2011 16:54:19 -0800 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> <1297099461-sup-1716@pinkfloyd.chass.utoronto.ca> Message-ID: On 2/7/11, Maciej Blizi?ski wrote: > > I've updated the wiki page, adding a reference to RFC 2119. I've also > added the suggestion that --prefix can be used together with --libdir. > Arrrg. Maciej, you are still using language that essentially "requires" moving the real libraries into /opt/csw/lib. You now know that at least two maintainers, strongly object to this. So please stop it. Specifically: "Shared library files need to be moved from /opt/csw/foo/lib to /opt/csw/lib." key word here is "moved", along with "need to be". From bwalton at opencsw.org Tue Feb 8 02:45:42 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Feb 2011 20:45:42 -0500 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> Message-ID: <1297129479-sup-1289@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Sun Feb 06 00:06:37 -0500 2011: > > 1.2.3,pi,REV=YYYY.MM.DD > > This is the best in my opinion. Let's treat it as flags and only > allow to pick from a fixed list to keep it from getting carried away > and be easily checked. Agreed. Does anyone _not_ like this choice? > p = patched > i = i386 only > s = sparc only Works for me. Anything else that would be useful to define at the outset here? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Feb 8 03:55:32 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Feb 2011 21:55:32 -0500 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> <1297099461-sup-1716@pinkfloyd.chass.utoronto.ca> Message-ID: <1297133366-sup-8095@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Feb 07 19:51:50 -0500 2011: > no, please dont "make a reference to rfcs". Our standards should be > self-contained. I don't see the RFC reference as a problem. It's not about to disappear anytime soon. Self contained is good as a general principle, but we're not talking about some random /. article here. > Please take the appropriate section, write it in normal-people > language as much as possible, and put it on our own pages. Why the insistence on dumbed-down language? These documents are aimed at maintainers, not the general public. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Feb 8 04:25:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Feb 2011 22:25:20 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: Message-ID: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Fri Feb 04 03:22:32 -0500 2011: > Indeed, we cannot have a strict, mandatory policy on this, rather a > recommendation which is still a policy. Consequently, your > proposition of modification cannot be as strong as you proposed, > i.e., imposing the symbolic links instead of the real files. This is true, I agree. However, I think that for this to be a useful policy, we should at least agree on the preferred location for the file, and by proxy, the preferred direction for the symlink (eg: from 'special' -> 'normal' or from 'normal' -> 'special'). This will add consistency overall, while allowing for the opposite file placement in justified cases. My preference, as the whole point of this proposal is to have more libraries available in /opt/csw/lib, is to prefer the files to be placed in /opt/csw/lib and the symlinks (if any) to be in /opt/csw/special/lib/. Does anyone think this should be the opposite by default? It would also help to have at least some example of a case where you'd have cause to reverse the preferred direction of the symlinks. This is not something to include in the documents, but simply to further our discussion and make the documents better overall. (Please forgive me if I've missed a previously described example.) > As for using alternatives for shared libraries, I don't know what to > think. I thought that alternatives are more appropriate to > executables but I must confess that thoroughly exploring > alternatives is one of my objectives. I think this is correct. Alternatives would work for shared libraries in the technical sense, but I don't think they're a good practical choice. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Feb 8 05:03:39 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Feb 2011 20:03:39 -0800 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: <1297133366-sup-8095@pinkfloyd.chass.utoronto.ca> References: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> <1297099461-sup-1716@pinkfloyd.chass.utoronto.ca> <1297133366-sup-8095@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Feb 7, 2011 at 6:55 PM, Ben Walton wrote: > E >> Please take the appropriate section, write it in normal-people >> language as much as possible, and put it on our own pages. > > Why the insistence on dumbed-down language? ?These documents are aimed > at maintainers, not the general public. By saying, that you are saying, "maintainers are 'special': they're smarter than 'the general public'. The general public is too stupid to understand our elite documents, we shouldnt bother trying to write docs for more 'common' people" Excuse me? We should be moving away from elitism, not towards it. We need to be more inclusive. Putting things in RFC-style language is a major turn-off to potential maintainers who arent already familiar with that sort of jargon. From phil at bolthole.com Tue Feb 8 05:07:51 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Feb 2011 20:07:51 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Feb 7, 2011 at 7:25 PM, Ben Walton wrote: > > My preference, as the whole point of this proposal is to have more > libraries available in /opt/csw/lib, is to prefer the files to be > placed in /opt/csw/lib and the symlinks (if any) to be in > /opt/csw/special/lib/. > > Does anyone think this should be the opposite by default? yes. I've already written this, AND I've already written why. Because that is the "normal" way that programs install things, when you compile with configure --prefix=/opt/csw/prefix That is the "normal" location ,therefore that should be the "real" location. This is consistent with standard behaviour. For example, /usr/openwin/lib. that is/was the "real" location of the libX11 libraries, but for convenience, symlinks were made from other locations pointing to there. We are in the same situation. We basically want a reference in /opt/csw/lib, for convenience. Plus the issue about keeping "du -k" output consistent within the program files for a prefix. From jcraig at opencsw.org Tue Feb 8 07:40:25 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Tue, 8 Feb 2011 01:40:25 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Feb 7, 2011 at 11:07 PM, Philip Brown wrote: > On Mon, Feb 7, 2011 at 7:25 PM, Ben Walton wrote: >> >> My preference, as the whole point of this proposal is to have more >> libraries available in /opt/csw/lib, is to prefer the files to be >> placed in /opt/csw/lib and the symlinks (if any) to be in >> /opt/csw/special/lib/. >> >> Does anyone think this should be the opposite by default? > > yes. I've already written this, AND I've already written why. > Because that is the "normal" way that programs install things, when > you compile with > ?configure --prefix=/opt/csw/prefix > > That is the "normal" location ,therefore that should be the "real" location. > This is consistent with standard behaviour. For example, > /usr/openwin/lib. that is/was the "real" location of the libX11 > libraries, but for convenience, symlinks were made from other > locations pointing to there. > We are in the same situation. We basically want a reference in > /opt/csw/lib, for convenience. > I concur. Libraries should be placed in their package specific subdirectory as the package install would have it. For convenience, a symlink from our global library directory (/opt/cw/lib) should be made to the actual file. The primary reason being that this allows easier integration of multiple versions. If you reverse this and force the actual library into /opt/csw/lib then you will have to move this library to its package/versioned subdirectory before overwriting. This would be a logistical nightmare. As to libraries with SONAME collisions I don't know whether its better to not create any symlinks or always create symlinks to the newest version (or possibly last installed). Its a coin toss between problems finding libraries during builds and the possibility that you'll break an existing application by installing a newer version of the library. Having said that, I guess I would lean towards operational stability and not create any symlinks. From dam at opencsw.org Tue Feb 8 08:10:53 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Feb 2011 08:10:53 +0100 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: <1297129479-sup-1289@pinkfloyd.chass.utoronto.ca> References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> <1297129479-sup-1289@pinkfloyd.chass.utoronto.ca> Message-ID: Hi, Am 08.02.2011 um 02:45 schrieb Ben Walton: > Excerpts from Peter Bonivart's message of Sun Feb 06 00:06:37 -0500 2011: > >>> 1.2.3,pi,REV=YYYY.MM.DD >> >> This is the best in my opinion. Let's treat it as flags and only >> allow to pick from a fixed list to keep it from getting carried away >> and be easily checked. > > Agreed. Does anyone _not_ like this choice? > >> p = patched >> i = i386 only >> s = sparc only > > Works for me. Anything else that would be useful to define at the > outset here? Two things: - Lets remove i/s as it is good to always release a bundle. The i386 only was used in the past if someone made a manual mistake during packaging and wanted to respin i386 only. This is IMHO generally bad. If an error occurs all packages should be rebuild. Introducing extra complexity to allow for manual patching is not a good idea. We should focus on full automation and the flag is useless for this. - If the "p" flag is present there should be checkpkg-check that /opt/csw/share/doc//README.CSW is present. Best regards -- Dago From maciej at opencsw.org Tue Feb 8 08:37:37 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 8 Feb 2011 07:37:37 +0000 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> <1297099461-sup-1716@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/8 Philip Brown : > On 2/7/11, Maciej Blizi?ski wrote: >> >> I've updated the wiki page, adding a reference to RFC 2119. ?I've also >> added the suggestion that --prefix can be used together with --libdir. >> > > Arrrg. > Maciej, you are still using language that essentially "requires" > moving the real libraries into /opt/csw/lib. > > You now know that at least two maintainers, strongly object to this. > So please stop it. > > Specifically: > > "Shared library files need to be moved from /opt/csw/foo/lib to /opt/csw/lib." > > key word here is "moved", along with "need to be". Right. This part of the document concerns not so much about what to do, but rather how and/or when to do it. Here's the updated version: ++ Implementation details If a piece of software is compiled with the /opt/csw prefix, public shared libraries are usually already at the right place. If there are any private libraries in /opt/csw/lib, they can be moved to a subdirectory after the "make install" step. Software compiled with a nonstandard prefix may need post-install modifications. If there are public shared library files in /opt/csw/foo/lib, they can be moved to /opt/csw/lib after the "make install" step. An alternate approach is to pass @@--prefix=/opt/csw@@ and @@--libdir=/opt/csw/lib@@ to the configure script. From maciej at opencsw.org Tue Feb 8 09:19:16 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 8 Feb 2011 08:19:16 +0000 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: 2011/2/7 Philip Brown : > On 2/7/11, Peter FELECAN wrote: >> >> This is nice but utterly complicated. What's wrong with majority as >> defined: >>... > > Because 51% in favour, can mean 49% vehemently against, yet it still passes. > > Having a policy passed, that pisses off 49% of active maintainers, is > never a good idea. Do you believe that an outcome against the will of 51% maintainers is better than an outcome against the will of 49% of them? From pfelecan at opencsw.org Tue Feb 8 09:26:07 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 08 Feb 2011 09:26:07 +0100 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: (Philip Brown's message of "Mon, 7 Feb 2011 16:51:50 -0800") References: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> <1297099461-sup-1716@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > no, please dont "make a reference to rfcs". Our standards should be > self-contained. The cited RFC is a golden rule in our field. This is as requiring to include a part of the Webster in our documents. However, citation can be used as examples in an introductory section. > Please take the appropriate section, write it in normal-people > language as much as possible, and put it on our own pages. Again, maintainers are computer scientists, engineers and generally technologists. Even a hobbyist maintainer should have the required culture to produce professional quality. -- Peter From pfelecan at opencsw.org Tue Feb 8 09:33:34 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 08 Feb 2011 09:33:34 +0100 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: (Philip Brown's message of "Mon, 7 Feb 2011 20:03:39 -0800") References: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> <1297099461-sup-1716@pinkfloyd.chass.utoronto.ca> <1297133366-sup-8095@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Mon, Feb 7, 2011 at 6:55 PM, Ben Walton wrote: >> E >>> Please take the appropriate section, write it in normal-people >>> language as much as possible, and put it on our own pages. >> >> Why the insistence on dumbed-down language? ?These documents are aimed >> at maintainers, not the general public. > > By saying, that you are saying, "maintainers are 'special': they're > smarter than 'the general public'. The general public is too stupid to > understand our elite documents, we shouldnt bother trying to write > docs for more 'common' people" This is what *you* say. Nobody have said something like that. However, you are wrong on the public/audience, i.e., who's the readership/users of our policies. It is the maintainer community. > Excuse me? > We should be moving away from elitism, not towards it. We need to be > more inclusive. Not being elitist haven't drawn crowds to our project. > Putting things in RFC-style language is a major turn-off to potential > maintainers who arent already familiar with that sort of jargon. In my opinion, and this is said now, somebody who's not familiar or is not willing to become familiar with the standards of our field should better abstain. If you analyze the causes of "turn-off" is more about past arrogant attitudes, arbitrariness, opacity, &c, than elitism. By the way, what's wrong with elitism when it designates high professional standards? -- Peter From pfelecan at opencsw.org Tue Feb 8 09:38:18 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 08 Feb 2011 09:38:18 +0100 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: (Dagobert Michelsen's message of "Tue, 8 Feb 2011 08:10:53 +0100") References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> <1297129479-sup-1289@pinkfloyd.chass.utoronto.ca> Message-ID: Dagobert Michelsen writes: > Hi, > > Am 08.02.2011 um 02:45 schrieb Ben Walton: >> Excerpts from Peter Bonivart's message of Sun Feb 06 00:06:37 -0500 2011: >> >>>> 1.2.3,pi,REV=YYYY.MM.DD >>> >>> This is the best in my opinion. Let's treat it as flags and only >>> allow to pick from a fixed list to keep it from getting carried away >>> and be easily checked. >> >> Agreed. Does anyone _not_ like this choice? >> >>> p = patched >>> i = i386 only >>> s = sparc only >> >> Works for me. Anything else that would be useful to define at the >> outset here? > > Two things: > - Lets remove i/s as it is good to always release a bundle. The i386 only > was used in the past if someone made a manual mistake during packaging and > wanted to respin i386 only. This is IMHO generally bad. If an error occurs > all packages should be rebuild. Introducing extra complexity to allow for > manual patching is not a good idea. We should focus on full automation and > the flag is useless for this. I generally agree with you but I have the feeling that if there is a packaged project which have sense only on a given platform it should be possible to deliver only that; but this doesn't require the usage of a flag, it only requires the relaxation of the "bundle" rule. > - If the "p" flag is present there should be checkpkg-check that > /opt/csw/share/doc//README.CSW is present. Absolutely right. -- Peter From pfelecan at opencsw.org Tue Feb 8 09:34:32 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 08 Feb 2011 09:34:32 +0100 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: (Philip Brown's message of "Mon, 7 Feb 2011 16:54:19 -0800") References: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> <1297099461-sup-1716@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On 2/7/11, Maciej Blizi?ski wrote: >> >> I've updated the wiki page, adding a reference to RFC 2119. I've also >> added the suggestion that --prefix can be used together with --libdir. >> > > Arrrg. > Maciej, you are still using language that essentially "requires" > moving the real libraries into /opt/csw/lib. > > You now know that at least two maintainers, strongly object to this. > So please stop it. > > Specifically: > > "Shared library files need to be moved from /opt/csw/foo/lib to /opt/csw/lib." > > key word here is "moved", along with "need to be". Is: "Shared library files should be moved from /opt/csw/foo/lib to /opt/csw/lib." better? -- Peter From maciej at opencsw.org Tue Feb 8 09:41:06 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 8 Feb 2011 08:41:06 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/8 Philip Brown : > On Mon, Feb 7, 2011 at 7:25 PM, Ben Walton wrote: >> >> My preference, as the whole point of this proposal is to have more >> libraries available in /opt/csw/lib, is to prefer the files to be >> placed in /opt/csw/lib and the symlinks (if any) to be in >> /opt/csw/special/lib/. >> >> Does anyone think this should be the opposite by default? > > yes. I've already written this, AND I've already written why. > Because that is the "normal" way that programs install things, when > you compile with > ?configure --prefix=/opt/csw/prefix > > That is the "normal" location , No, it isn't. Our prefix is /opt/csw, and a subdirectory underneath it is not our prefix. If a maintainer uses a custom --prefix setting, it's most probably because of file conflicts in /opt/csw/bin, and --bindir=/opt/csw/bin/specialdir would suffice. There are also other ways of achieving this goal. As it stands in the proposal, a way to support multiple versions is outside the scope. > This is consistent with standard behaviour. For example, > /usr/openwin/lib. that is/was the "real" location of the libX11 > libraries, but for convenience, symlinks were made from other > locations pointing to there. > We are in the same situation. We basically want a reference in > /opt/csw/lib, for convenience. The proposal, as it stands now, allows such symlinks to be made, if there are reasons to do that. > Plus the issue about keeping "du -k" output consistent within the > program files for a prefix. This issue is considered irrelevant. From pfelecan at opencsw.org Tue Feb 8 09:45:11 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 08 Feb 2011 09:45:11 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: (Philip Brown's message of "Mon, 7 Feb 2011 20:07:51 -0800") References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Mon, Feb 7, 2011 at 7:25 PM, Ben Walton wrote: >> >> My preference, as the whole point of this proposal is to have more >> libraries available in /opt/csw/lib, is to prefer the files to be >> placed in /opt/csw/lib and the symlinks (if any) to be in >> /opt/csw/special/lib/. >> >> Does anyone think this should be the opposite by default? > > yes. I've already written this, AND I've already written why. > Because that is the "normal" way that programs install things, when > you compile with > configure --prefix=/opt/csw/prefix > > That is the "normal" location ,therefore that should be the "real" location. > This is consistent with standard behaviour. For example, > /usr/openwin/lib. that is/was the "real" location of the libX11 > libraries, but for convenience, symlinks were made from other > locations pointing to there. The OpenWinndows situation is special and the historical reasons are well known. The migration toward a "vanilla" X11 makes that obsolete. We don't need that. > We are in the same situation. We basically want a reference in > /opt/csw/lib, for convenience. > > Plus the issue about keeping "du -k" output consistent within the > program files for a prefix. This disk usage argument seems to me so lame that I'm abstaining from comment. -- Peter From maciej at opencsw.org Tue Feb 8 09:47:50 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 8 Feb 2011 08:47:50 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/8 Jonathan Craig : > The primary reason being that this allows easier integration of > multiple versions. ?If you reverse this and force the actual library > into /opt/csw/lib then you will have to move this library to its > package/versioned subdirectory before overwriting. ?This would be a > logistical nightmare. I'm not sure I'm following. Can you describe a concrete scenario? > As to libraries with SONAME collisions I don't know whether its better > to not create any symlinks or always create symlinks to the newest > version (or possibly last installed). ?Its a coin toss between > problems finding libraries during builds and the possibility that > you'll break an existing application by installing a newer version of > the library. ?Having said that, I guess I would lean towards > operational stability and not create any symlinks. Each backward-incompatible upgrade of a library comes with a new SONAME, so it won't break existing programs. There's one predictable SONAME collision scenario, and it is C++ libraries compiled with Solaris Studio vs GCC. Because each complier has it's own way of name mangling, the two libraries will be incompatible. I see two potential solutions to it: 1. Injecting a soname modification, e.g. turning libfoo.so.1 into libfoo-gcc.so.1 2. Keeping GCC-compiled C++ libraries in a separate directory, e.g. /opt/csw/lib-gcc Maciej From pfelecan at opencsw.org Tue Feb 8 09:46:37 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 08 Feb 2011 09:46:37 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: (Jonathan Craig's message of "Tue, 8 Feb 2011 01:40:25 -0500") References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: Jonathan Craig writes: > On Mon, Feb 7, 2011 at 11:07 PM, Philip Brown wrote: >> On Mon, Feb 7, 2011 at 7:25 PM, Ben Walton wrote: >>> >>> My preference, as the whole point of this proposal is to have more >>> libraries available in /opt/csw/lib, is to prefer the files to be >>> placed in /opt/csw/lib and the symlinks (if any) to be in >>> /opt/csw/special/lib/. >>> >>> Does anyone think this should be the opposite by default? >> >> yes. I've already written this, AND I've already written why. >> Because that is the "normal" way that programs install things, when >> you compile with >> ?configure --prefix=/opt/csw/prefix >> >> That is the "normal" location ,therefore that should be the "real" location. >> This is consistent with standard behaviour. For example, >> /usr/openwin/lib. that is/was the "real" location of the libX11 >> libraries, but for convenience, symlinks were made from other >> locations pointing to there. >> We are in the same situation. We basically want a reference in >> /opt/csw/lib, for convenience. >> > > I concur. Libraries should be placed in their package specific > subdirectory as the package install would have it. For convenience, a > symlink from our global library directory (/opt/cw/lib) should be made > to the actual file. > > The primary reason being that this allows easier integration of > multiple versions. If you reverse this and force the actual library > into /opt/csw/lib then you will have to move this library to its > package/versioned subdirectory before overwriting. This would be a > logistical nightmare. > > As to libraries with SONAME collisions I don't know whether its better > to not create any symlinks or always create symlinks to the newest > version (or possibly last installed). Its a coin toss between > problems finding libraries during builds and the possibility that > you'll break an existing application by installing a newer version of > the library. Having said that, I guess I would lean towards > operational stability and not create any symlinks. What about stating that a symbolic link *should* be made in a sense or another if the need arise but, as it implies, is not mandatory. -- Peter From pfelecan at opencsw.org Tue Feb 8 09:58:20 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 08 Feb 2011 09:58:20 +0100 Subject: [csw-maintainers] How to get out of the project... In-Reply-To: <20110201213652.3ae998c3@sirtobi.com> (sirtobi@unix-ag.uni-hannover.de's message of "Tue, 1 Feb 2011 21:36:52 -0100") References: <20110201213652.3ae998c3@sirtobi.com> Message-ID: sirtobi at unix-ag.uni-hannover.de writes: > Hi there, > > I have a kind of pitty question but cant find the answer on the web... > I want to be removed from the lists and I dont need any account > anymore. Especially removing me from the lists would be great. As our lists are managed by mailman, you go to https://lists.opencsw.org/mailman/listinfo/maintainers and near the end of the page you'll see instruction of how to unsubscribe. -- Peter From pfelecan at opencsw.org Tue Feb 8 09:53:52 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 08 Feb 2011 09:53:52 +0100 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: (Philip Brown's message of "Mon, 7 Feb 2011 09:02:18 -0800") References: Message-ID: Philip Brown writes: > On 2/7/11, Peter FELECAN wrote: >> >> This is nice but utterly complicated. What's wrong with majority as >> defined: >>... > > Because 51% in favour, can mean 49% vehemently against, yet it still passes. > > Having a policy passed, that pisses off 49% of active maintainers, is > never a good idea. As said Alexis de Tocqueville, the democracy is the dictatorship of the majority over the minority. But that is true mainly in ochlocracies. -- Peter From pfelecan at opencsw.org Tue Feb 8 09:55:16 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 08 Feb 2011 09:55:16 +0100 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: (Philip Brown's message of "Mon, 7 Feb 2011 09:04:29 -0800") References: Message-ID: Philip Brown writes: > On 2/7/11, Jonathan Craig wrote: >> On Mon, Feb 7, 2011 at 10:07 AM, Philip Brown wrote: >>>... >> majority - 50% - 1 week >> super majority - 75% - 2 day >> consensus - 100% - no minimum >> > > We're talking about *policy* here. > Not "what color should we paint the website", but formal, ideally > not-changing-in-the-future, policy. > In my opinion, there should be a *minimum* of 1 week discussion > period, for all policy decisions. > > If it isnt important enough to reserve a week's period of time for > discussion for it, then it > doesnt belong as "policy" in the first place. Policy is not only enforcement but also agreement. -- Peter From maciej at opencsw.org Tue Feb 8 10:10:41 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 8 Feb 2011 09:10:41 +0000 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: Message-ID: 2011/2/5 Maciej Blizi?ski : > Yes, I agree that using symlink can be a valid solution. ?However, > using symlinks vs regular files is a tangential issue. > > Perhaps we should not include anything about files vs symlinks in the > proposal. ?This can be covered by a separate proposal. ?If you care > about this, would you like to put forward a proposal regarding the use > of symlinks? Phil, could you address this paragraph? From maciej at opencsw.org Tue Feb 8 13:19:28 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 8 Feb 2011 12:19:28 +0000 Subject: [csw-maintainers] Building OpenVPN 2.1.4 (with tun device support) Message-ID: There was a pkgrequest for OpenVPN update. I gave it a shot. Compilation of tun.c fails: /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I/opt/csw/include -I. -xO3 -m32 -xa rch=v8 -xnorunpath -c cryptoapi.c "packet_id.h", line 127: warning: zero or negative subscript "packet_id.h", line 127: warning: zero or negative subscript "packet_id.h", line 127: warning: zero or negative subscript "mbuf.h", line 61: warning: syntax error: empty member declaration "list.h", line 59: warning: syntax error: empty member declaration "route.h", line 92: warning: zero or negative subscript "route.h", line 113: warning: zero or negative subscript "route.h", line 92: warning: zero or negative subscript "route.h", line 113: warning: zero or negative subscript "list.h", line 59: warning: syntax error: empty member declaration "mbuf.h", line 61: warning: syntax error: empty member declaration "tun.c", line 711: undefined symbol: command_line "tun.c", line 716: warning: improper pointer/integer combination: arg #1 "tun.c", line 1392: #error: I need the symbol TUNNEWPPA from net/if_tun.h cc: acomp failed for tun.c gmake[4]: *** [tun.o] Error 2 gmake[4]: *** Waiting for unfinished jobs.... gmake[4]: Leaving directory `/home/maciej/src/opencsw/pkg/openvpn/trunk/work/sol aris9-sparc/build-isa-sparcv8/openvpn-2.1.4' Is anyone interested in working on openvpn? From bwalton at opencsw.org Tue Feb 8 14:49:46 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 08 Feb 2011 08:49:46 -0500 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> <1297129479-sup-1289@pinkfloyd.chass.utoronto.ca> Message-ID: <1297172909-sup-2134@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Feb 08 02:10:53 -0500 2011: Hi Dago, > - Lets remove i/s as it is good to always release a bundle. The i386 > only was used in the past if someone made a manual mistake during > packaging and wanted to respin i386 only. This is IMHO generally > bad. If an error occurs all packages should be > rebuild. Introducing extra complexity to allow for manual patching > is not a good idea. We should focus on full automation and the > flag is useless for this. I thought these flags were used when a package wouldn't build on one platform or the other for some reason...? If it has only been used as you indicate above, then I agree that it's not a good choice. > - If the "p" flag is present there should be checkpkg-check that > /opt/csw/share/doc//README.CSW is present. Agreed. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Feb 8 15:29:24 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Feb 2011 06:29:24 -0800 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: On Tue, Feb 8, 2011 at 12:55 AM, Peter FELECAN wrote: > Philip Brown writes: >> In my opinion, there should be a *minimum* of 1 week discussion >> period, for all policy decisions. >> >> If it isnt important enough to reserve a week's period of time for >> discussion for it, then it >> doesnt belong as "policy" in the first place. > > Policy is not only enforcement but also agreement. You made a true statement there, but I'm not sure on which side of the issue you mean it to be. So I will expand on my original email to say: agreement is good. *informed*, *well thought out* agreement is better. So, especially given that not all people read their email every day, it is better to give room for that, with a 1 week minimum discussion period for policy. From phil at bolthole.com Tue Feb 8 15:41:40 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Feb 2011 06:41:40 -0800 Subject: [csw-maintainers] Building OpenVPN 2.1.4 (with tun device support) In-Reply-To: References: Message-ID: 2011/2/8 Maciej Blizi?ski : > There was a pkgrequest for OpenVPN update. ?I gave it a shot. > Compilation of tun.c fails: > > "tun.c", line 716: warning: improper pointer/integer combination: arg #1 > "tun.c", line 1392: #error: I need the symbol TUNNEWPPA from net/if_tun.h > It would probably help if you had the appropriate required package installed. if_tun.h is not installed on the build system, that I can see. From phil at bolthole.com Tue Feb 8 15:51:27 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Feb 2011 06:51:27 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/8 Maciej Blizi?ski : > 2011/2/8 Philip Brown : >> >> yes. I've already written this, AND I've already written why. >> Because that is the "normal" way that programs install things, when >> you compile with >> ?configure --prefix=/opt/csw/prefix >> >> That is the "normal" location , > > No, it isn't. let me clarify: "normal, for that software's installation process" >> Plus the issue about keeping "du -k" output consistent within the >> program files for a prefix. > > This issue is considered irrelevant. You misspelled "Maciej considers this issue irrelevant". That does not make the issue universally irrelevant I consider your goal of having the physical rather than the symlink, in /opt/csw/lib, to be irrelevant to any kind of quality improvement. Why is your opinion more important than mine? >> Perhaps we should not include anything about files vs symlinks in the >> proposal. This can be covered by a separate proposal. If you care >> about this, would you like to put forward a proposal regarding the use >> of symlinks? > >Phil, could you address this paragraph? I thought I already said that was okay. The trouble is, you keep using language in the proposal that mandates having the physical file in /opt/csw/lib, and denies using symlinks. As far as I can think of, there is no clean simple grammatical construct you can use, that covers "move the file, or make a symlink". Using the word "move" in the spec, denies the use of sylinks. The whole point of symlinking, is to NOT move, but make a reference instead. From skayser at opencsw.org Tue Feb 8 16:07:12 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 8 Feb 2011 16:07:12 +0100 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> <1297129479-sup-1289@pinkfloyd.chass.utoronto.ca> Message-ID: <20110208150712.GS21610@sebastiankayser.de> * Peter FELECAN wrote: > Dagobert Michelsen writes: > > - If the "p" flag is present there should be checkpkg-check that > > /opt/csw/share/doc//README.CSW is present. > > Absolutely right. Can I ask the naive question of why we need this at all when all the applied patches are easily visible from the repository? Sebastian From dam at opencsw.org Tue Feb 8 16:54:54 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Feb 2011 16:54:54 +0100 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> <1297129479-sup-1289@pinkfloyd.chass.utoronto.ca> Message-ID: <79585D13-50C6-444D-8EF9-13F35D2B47F1@opencsw.org> Hi Peter, Am 08.02.2011 um 09:38 schrieb Peter FELECAN: > Dagobert Michelsen writes: >> Am 08.02.2011 um 02:45 schrieb Ben Walton: >>> Excerpts from Peter Bonivart's message of Sun Feb 06 00:06:37 -0500 2011: >>> >>>>> 1.2.3,pi,REV=YYYY.MM.DD >>>> >>>> This is the best in my opinion. Let's treat it as flags and only >>>> allow to pick from a fixed list to keep it from getting carried away >>>> and be easily checked. >>> >>> Agreed. Does anyone _not_ like this choice? >>> >>>> p = patched >>>> i = i386 only >>>> s = sparc only >>> >>> Works for me. Anything else that would be useful to define at the >>> outset here? >> >> Two things: >> - Lets remove i/s as it is good to always release a bundle. The i386 only >> was used in the past if someone made a manual mistake during packaging and >> wanted to respin i386 only. This is IMHO generally bad. If an error occurs >> all packages should be rebuild. Introducing extra complexity to allow for >> manual patching is not a good idea. We should focus on full automation and >> the flag is useless for this. > > I generally agree with you but I have the feeling that if there is a > packaged project which have sense only on a given platform it should be > possible to deliver only that; but this doesn't require the usage of a > flag, it only requires the relaxation of the "bundle" rule. What you say is already the case, see adobereader. But it is not what the flag was used in the past: it indicated if a package was re-released with the same version but only "fixed" on either sparc or i386. This is IMHO unnecessary and confusing. >> - If the "p" flag is present there should be checkpkg-check that >> /opt/csw/share/doc//README.CSW is present. > > Absolutely right. :-) Best regards -- Dago From dam at opencsw.org Tue Feb 8 16:57:02 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Feb 2011 16:57:02 +0100 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: <1297172909-sup-2134@pinkfloyd.chass.utoronto.ca> References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> <1297129479-sup-1289@pinkfloyd.chass.utoronto.ca> <1297172909-sup-2134@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, Am 08.02.2011 um 14:49 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Tue Feb 08 02:10:53 -0500 2011: >> - Lets remove i/s as it is good to always release a bundle. The i386 >> only was used in the past if someone made a manual mistake during >> packaging and wanted to respin i386 only. This is IMHO generally >> bad. If an error occurs all packages should be >> rebuild. Introducing extra complexity to allow for manual patching >> is not a good idea. We should focus on full automation and the >> flag is useless for this. > > I thought these flags were used when a package wouldn't build on one > platform or the other for some reason...? Nope. > If it has only been used as > you indicate above, then I agree that it's not a good choice. Ok, so let's remove "i" and "s". >> - If the "p" flag is present there should be checkpkg-check that >> /opt/csw/share/doc//README.CSW is present. > > Agreed. Best regards -- Dago From dam at opencsw.org Tue Feb 8 17:02:39 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Feb 2011 17:02:39 +0100 Subject: [csw-maintainers] [policy] Re: feature patching, and naming + source packages? In-Reply-To: <20110208150712.GS21610@sebastiankayser.de> References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> <1297129479-sup-1289@pinkfloyd.chass.utoronto.ca> <20110208150712.GS21610@sebastiankayser.de> Message-ID: <2D173A05-9C3B-4D99-AC35-DCBDA35B82AF@opencsw.org> Hi Sebastian, Am 08.02.2011 um 16:07 schrieb Sebastian Kayser: > * Peter FELECAN wrote: >> Dagobert Michelsen writes: >>> - If the "p" flag is present there should be checkpkg-check that >>> /opt/csw/share/doc//README.CSW is present. >> >> Absolutely right. > > Can I ask the naive question of why we need this at all when all the > applied patches are easily visible from the repository? It indicates that a package contains software that does not work 100% the same as the pristine version does. The flag is not for "make compile" patches, but for contributed upstream patches not yet applied to upstream. Personally I see no real need for this, but it is a nice to have the locally applied things documented. Apart from that I would like to note that we already have source packages which can be activated at any time by calling NOSOURCEPACKAGE= gmake repackage or by changing the GAR default "NOSOURCEPACKAGE ?= 1". The source package will include the upstream sources and all patches. Best regards -- Dago From skayser at opencsw.org Tue Feb 8 17:26:05 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 8 Feb 2011 17:26:05 +0100 Subject: [csw-maintainers] [policy] Re: feature patching, and naming + source packages? In-Reply-To: <2D173A05-9C3B-4D99-AC35-DCBDA35B82AF@opencsw.org> References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> <1297129479-sup-1289@pinkfloyd.chass.utoronto.ca> <20110208150712.GS21610@sebastiankayser.de> <2D173A05-9C3B-4D99-AC35-DCBDA35B82AF@opencsw.org> Message-ID: <20110208162605.GT21610@sebastiankayser.de> * Dagobert Michelsen wrote: > Am 08.02.2011 um 16:07 schrieb Sebastian Kayser: > > * Peter FELECAN wrote: > >> Dagobert Michelsen writes: > >>> - If the "p" flag is present there should be checkpkg-check that > >>> /opt/csw/share/doc//README.CSW is present. > >> > >> Absolutely right. > > > > Can I ask the naive question of why we need this at all when all the > > applied patches are easily visible from the repository? > > It indicates that a package contains software that does not work > 100% the same as the pristine version does. The flag is not for > "make compile" patches, but for contributed upstream patches not > yet applied to upstream. Personally I see no real need for this, > but it is a nice to have the locally applied things documented. Thanks Dago. So it's intended for notable derivations from or additions to the the expected (==upstream) functionality - of which we only have very few I suppose. Sebastian From maciej at opencsw.org Tue Feb 8 18:51:04 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 8 Feb 2011 17:51:04 +0000 Subject: [csw-maintainers] /usr/{local,share} references Message-ID: I've spent some time researching the scale of /usr/{local,share} references. I've re-indexed our catalog and compiled a list of all files that currently trigger this error: http://buildfarm.opencsw.org/~maciej/files-with-bad-content.html The numbers are: 4010 occurrences of /usr/local and 1564 occurences of /usr/share. Some people probably already had worked with their packages cleaning up /usr/{local,shared} references. What are your thoughts about it, given the number of occurrences of this issue in our catalog, is the benefit worth the effort? Maciej From pfelecan at opencsw.org Tue Feb 8 19:08:08 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 08 Feb 2011 19:08:08 +0100 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: (Philip Brown's message of "Tue, 8 Feb 2011 06:29:24 -0800") References: Message-ID: Philip Brown writes: > On Tue, Feb 8, 2011 at 12:55 AM, Peter FELECAN wrote: >> Philip Brown writes: > >>> In my opinion, there should be a *minimum* of 1 week discussion >>> period, for all policy decisions. >>> >>> If it isnt important enough to reserve a week's period of time for >>> discussion for it, then it >>> doesnt belong as "policy" in the first place. >> >> Policy is not only enforcement but also agreement. > > > You made a true statement there, but I'm not sure on which side of the > issue you mean it to be. So I will expand on my original email to say: > agreement is good. *informed*, *well thought out* agreement is better. > So, especially given that not all people read their email every day, > it is better to give room for that, with a 1 week minimum discussion > period for policy. A week seems alright for me. What about a maximum after which, if there's no consensus we proceed to a vote? 10 days seems enough and prevents evaporation. -- Peter From pfelecan at opencsw.org Tue Feb 8 19:18:15 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 08 Feb 2011 19:18:15 +0100 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 8 Feb 2011 17:51:04 +0000") References: Message-ID: Maciej Blizi?ski writes: > I've spent some time researching the scale of /usr/{local,share} > references. I've re-indexed our catalog and compiled a list of all > files that currently trigger this error: > > http://buildfarm.opencsw.org/~maciej/files-with-bad-content.html > > The numbers are: 4010 occurrences of /usr/local and 1564 occurences of > /usr/share. > > Some people probably already had worked with their packages cleaning > up /usr/{local,shared} references. What are your thoughts about it, > given the number of occurrences of this issue in our catalog, is the > benefit worth the effort? Can you re-state what benefit and effort you speak about? Note aside, this show that this is a moot issue. For example, in gcc3objc I provide a README.CSW which states: 2. /usr/local/include or /opt/sfw/include are not part of the default include search path. This is evidently valid. I think that spending too much time on removing *all* references isn't worth the effort. P.S. you list isn't sorted which is a PITA. -- Peter From skayser at opencsw.org Tue Feb 8 19:15:17 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 8 Feb 2011 19:15:17 +0100 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: Message-ID: <20110208181517.GU21610@sebastiankayser.de> * Maciej Blizi??ski wrote: > I've spent some time researching the scale of /usr/{local,share} > references. I've re-indexed our catalog and compiled a list of all > files that currently trigger this error: > > http://buildfarm.opencsw.org/~maciej/files-with-bad-content.html > > The numbers are: 4010 occurrences of /usr/local and 1564 occurences of > /usr/share. > > Some people probably already had worked with their packages cleaning > up /usr/{local,shared} references. What are your thoughts about it, > given the number of occurrences of this issue in our catalog, is the > benefit worth the effort? IMHO there are areas (e.g. an updated samba/php pkg, requested pkg updates in general, a build standards overhaul, or bug squashing) that would rather deserve our time and energy. When have we last seen a bug report on a /usr/local occurence? Dealing with this sort of stuff seems oddly detached from reality when having a look at the pending bugs in the bug tracker. Sebastian From bonivart at opencsw.org Tue Feb 8 19:47:11 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 8 Feb 2011 19:47:11 +0100 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: <20110208181517.GU21610@sebastiankayser.de> References: <20110208181517.GU21610@sebastiankayser.de> Message-ID: On Tue, Feb 8, 2011 at 7:15 PM, Sebastian Kayser wrote: > IMHO there are areas (e.g. an updated samba/php pkg, requested pkg > updates in general, a build standards overhaul, or bug squashing) that > would rather deserve our time and energy. > > When have we last seen a bug report on a /usr/local occurence? Dealing > with this sort of stuff seems oddly detached from reality when having a > look at the pending bugs in the bug tracker. Exactly, this is just a distraction from what's really important but our packages are being held hostage at release time by a man totally lacking the concept of priorities. That's what needs fixing. /peter From maciej at opencsw.org Tue Feb 8 19:57:24 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 8 Feb 2011 18:57:24 +0000 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: Message-ID: 2011/2/8 Peter FELECAN : > P.S. you list isn't sorted which is a PITA. Right, thanks for suggestion. Fixed. From maciej at opencsw.org Tue Feb 8 20:07:29 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 8 Feb 2011 19:07:29 +0000 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: Message-ID: 2011/2/8 Peter FELECAN : > Can you re-state what benefit and effort you speak about? The effort is in going through files one by one, looking for reasons why /usr/local is present in them. Then figuring whether they should be removed or not, and patching them if necessary. The benefit - in some cases, we can discover places where software might try to scan directories for purposes of discovering files, e.g. mime.types. In other cases, there might be hard-coded references to, say, interpreters, which might be actual bugs. I don't have any other examples. > Note aside, this show that this is a moot issue. For example, in > gcc3objc I provide a README.CSW which states: > > ? ? ? ? 2. /usr/local/include or /opt/sfw/include are not part of the > ? ? ? ? ? ?default include search path. > > This is evidently valid. Yes, agreed. > I think that spending too much time on removing *all* references isn't > worth the effort. Yes. Just reviewing them, without removing, is also a lot of time. From phil at bolthole.com Tue Feb 8 21:34:46 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Feb 2011 12:34:46 -0800 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: On Tue, Feb 8, 2011 at 10:08 AM, Peter FELECAN wrote: > Philip Brown writes: >> So, especially given that not all people read their email every day, >> it is better to give room for that, with a 1 week minimum discussion >> period for policy. > > A week seems alright for me. What about a maximum after which, if > there's no consensus we proceed to a vote? 10 days seems enough and > prevents evaporation. Some discussions take longer than 10 days. I dont think putting an automatic vote trigger in place is neccessarily the right thing to do. If on the other hand, discussion has stalled for [x] amount of time, I think it would be fair to allow for any concerned party to call for a vote, which should then be acted upon. The tricky bit is in objectively defining "stalled" (vs "being contended"), and what a good value of "x" is. From phil at bolthole.com Tue Feb 8 21:40:21 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Feb 2011 12:40:21 -0800 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: Message-ID: 2011/2/8 Maciej Blizi?ski : > I've spent some time researching the scale of /usr/{local,share} > references. ?I've re-indexed our catalog and compiled a list of all > files that currently trigger this error: > > http://buildfarm.opencsw.org/~maciej/files-with-bad-content.html > > The numbers are: 4010 occurrences of /usr/local and 1564 occurences of > /usr/share. > > Some people probably already had worked with their packages cleaning > up /usr/{local,shared} references. ?What are your thoughts about it, > given the number of occurrences of this issue in our catalog, is the > benefit worth the effort? > I dont think its worth attempting to put together a project whose purpose is to go through and eliminate references in all pre-existing packages. On the other hand, it seems a no-brainer to do so for new or updated packages going forward. After all, it should be fairly trivial to throw together an automated script to do it with minimal effort A silly little example being for f in `find . -type f | xargs grep -l /usr/local` ; do sed 's:/usr/local:/opt/csw:g' $f >$f.cswfix; mv $f.cswfix $f done Feel free to rewrite in your preferred language of perl, python, or whatever floats your boat :) From phil at bolthole.com Tue Feb 8 21:43:41 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Feb 2011 12:43:41 -0800 Subject: [csw-maintainers] [policy] Re: feature patching, and naming + source packages? In-Reply-To: <2D173A05-9C3B-4D99-AC35-DCBDA35B82AF@opencsw.org> References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> <1297129479-sup-1289@pinkfloyd.chass.utoronto.ca> <20110208150712.GS21610@sebastiankayser.de> <2D173A05-9C3B-4D99-AC35-DCBDA35B82AF@opencsw.org> Message-ID: On Tue, Feb 8, 2011 at 8:02 AM, Dagobert Michelsen wrote: > > Apart from that I would like to note that we already have source > packages which can be activated at any time by calling > ?NOSOURCEPACKAGE= gmake repackage > or by changing the GAR default "NOSOURCEPACKAGE ?= 1". The source > package will include the upstream sources and all patches. > > maybe you would want to start a new thread with a more relevant subject for this, but... it is not intuitive what the above does. Even with your additional comentary, I'm not sure what it does. But by itself, the line NOSOURCEPACKAGE= gmake repackage is certainly very cryptic. From phil at bolthole.com Tue Feb 8 21:48:21 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Feb 2011 12:48:21 -0800 Subject: [csw-maintainers] [policy] Re: feature patching, and naming In-Reply-To: <79585D13-50C6-444D-8EF9-13F35D2B47F1@opencsw.org> References: <1296947439-sup-9445@pinkfloyd.chass.utoronto.ca> <1297129479-sup-1289@pinkfloyd.chass.utoronto.ca> <79585D13-50C6-444D-8EF9-13F35D2B47F1@opencsw.org> Message-ID: On Tue, Feb 8, 2011 at 7:54 AM, Dagobert Michelsen wrote: > > > What you say is already the case, see adobereader. But it is not what the > flag was used in the past: it indicated if a package was re-released > with the same version but only "fixed" on either sparc or i386. This > is IMHO unnecessary and confusing. That is one viewpoint. However, a different viewpoint, is that requiring users to re-download the other side.. the "non-fixed" version... when exactly *nothing* has changed in the "newer" package, is even more unneccessary. Of the two viewpoints, I think that triggering thousands of redownloads for no possible good, is worse than the slight odditity of marking the "fixed" side specially. Which is why we have historically supported this sort of thing, above and beyond the benefit that the maintainer only has to compile and reupload "half" the packages to be resubmitted. From dam at opencsw.org Tue Feb 8 22:20:30 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Feb 2011 22:20:30 +0100 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: Message-ID: Hi Phil, Am 08.02.2011 um 21:40 schrieb Philip Brown: > 2011/2/8 Maciej Blizi?ski : >> I've spent some time researching the scale of /usr/{local,share} >> references. I've re-indexed our catalog and compiled a list of all >> files that currently trigger this error: >> >> http://buildfarm.opencsw.org/~maciej/files-with-bad-content.html >> >> The numbers are: 4010 occurrences of /usr/local and 1564 occurences of >> /usr/share. >> >> Some people probably already had worked with their packages cleaning >> up /usr/{local,shared} references. What are your thoughts about it, >> given the number of occurrences of this issue in our catalog, is the >> benefit worth the effort? > > I dont think its worth attempting to put together a project whose > purpose is to go through and eliminate references in all pre-existing > packages. > > On the other hand, it seems a no-brainer to do so for new or updated > packages going forward. > > After all, it should be fairly trivial to throw together an automated > script to do it with minimal effort > > A silly little example being > > for f in `find . -type f | xargs grep -l /usr/local` ; do > sed 's:/usr/local:/opt/csw:g' $f >$f.cswfix; mv $f.cswfix $f > done > > Feel free to rewrite in your preferred language of perl, python, or > whatever floats your boat :) You are not serious about this, right? It is a no-brainer because no brain is involved in this fix. Using this script says "checkpkg, shut up!" and "Phil, shut up! I don't care about quality and just want my package to go through." In inspected a couple of my package and every occurence needs to be verified manually. There are even scripts looking for configuration stuff which should keep the include to /usr/local but must have /opt/csw manually added and the check overridden. Or have just one occurrence corrected and keep another in an example section. If we are talking at the level of brainless replacement let's just drop the test, ok? This is even more bad than keeping /usr/local because it says "I have looked at it and judged to replace it" instead of "well, I kept the defaults, if they are wrong I look again". BTW, I found in yaz a real positive where tons of stuff is correctly auto-configured with the exception of one path to /usr/local/share/... and a comment /* Don't know how to make this with autoconf */ :-( And, yes, this is important to 100% functionality. Best regards -- Dago From phil at bolthole.com Tue Feb 8 23:01:16 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Feb 2011 14:01:16 -0800 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: Message-ID: On Tue, Feb 8, 2011 at 1:20 PM, Dagobert Michelsen wrote: > Hi Phil, > > Am 08.02.2011 um 21:40 schrieb Philip Brown: >> >> A silly little example being >> >> for f in `find . -type f | xargs grep -l /usr/local` ; do >> sed 's:/usr/local:/opt/csw:g' $f >$f.cswfix; mv $f.cswfix $f >> done >> >> Feel free to rewrite in your preferred language of perl, python, or >> whatever floats your boat :) > > You are not serious about this, right? Well, I would certainly prefer that people manually inspect and replace. But for those people whining that this takes too much effort, the above provides an almost effortless alternative. In inspected a couple of my package > and every occurence needs to be verified manually. There are even > scripts looking for configuration stuff which should keep the include > to /usr/local but must have /opt/csw manually added and the check > overridden. I would be interested to hear more details, about specific cases where the above script did something "bad". I think that all maintainers would benefit from this information. > This is even more bad than keeping /usr/local because it says "I have > looked at it and judged to replace it" instead of "well, I kept the > defaults, if they are wrong I look again". But if they dont even look, how are they going to come to the point of examining the defaults, knowing they are wrong, and "looking again"? In some cases, having wrong defaults, does not "break" the app. but you silently lose functionality. The maintainer may never notice that unless they explicitly examine all /usr/local occurrences. Which is what I'm in favor of, but others are opposed to. > BTW, I found in yaz a real positive where tons of stuff is correctly > auto-configured with the exception of one path to /usr/local/share/... > and a comment /* Don't know how to make this with autoconf */ :-( > And, yes, this is important to 100% functionality. That's nice that yaz "does the right thing" for 99%. Nothing wrong with csw-specific patching for that "one path" that they dont know how to autoconf either though. From maciej at opencsw.org Tue Feb 8 23:01:41 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 8 Feb 2011 22:01:41 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/8 Philip Brown : > 2011/2/8 Maciej Blizi?ski : >> 2011/2/8 Philip Brown : >>> >>> yes. I've already written this, AND I've already written why. >>> Because that is the "normal" way that programs install things, when >>> you compile with >>> ?configure --prefix=/opt/csw/prefix >>> >>> That is the "normal" location , >> >> No, it isn't. > > let me clarify: > > "normal, for that software's installation process" That did not clarify it at all. Software's installation process is about putting files into bindir, libdir and others, in the way prescribed by the arguments of the ./configure script. Arguments of the ./configure script come from the maintainer's decisions. Maintainer's decisions come from their goals, our policy and maintainer's own technical knowledge. Our policy^Wstandards define what the prefix is, and that prefix is /opt/csw. Using a different prefix is not, at OpenCSW, normal. To unpack the concept of prefix, it's really a shortcut, denoting common base directory for a number of other directories, such as bin, lib, share and var. If a piece of software needs to use a different bin directory, it should change that with --bindir. But this is a different discussion, a discussion about supporting multiple versions of one piece of software, which I want to keep separate from this one. >>> Plus the issue about keeping "du -k" output consistent within the >>> program files for a prefix. >> >> This issue is considered irrelevant. > > You misspelled "Maciej considers this issue irrelevant". > That does not make the issue universally irrelevant The issue can be relevant if you make a case for it, and what you've presented so far in the previous thread, did not help you make your case. > I consider your goal of having the physical rather than the symlink, > in /opt/csw/lib, to be irrelevant to any kind of quality improvement. > Why is your opinion more important than mine? I want to keep the symlinks discussion separate from the libraries discussion. There are two aspects: 1. The part of the policy saying that libraries should be available from /opt/csw 2. The part of the policy saying how files can be made available from a given directory If you want to talk about the first one, let's talk about the first one. If you want to talk about symlinks, let's open a new thread and talk about when regular files, and when symlinks should be used, any why. >>> Perhaps we should not include anything about files vs symlinks in the >>> proposal. ?This can be covered by a separate proposal. ?If you care >>> about this, would you like to put forward a proposal regarding the use >>> of symlinks? >> >>Phil, could you address this paragraph? > > I thought I already said that was okay. The trouble is, you keep using > language in the proposal that mandates having the physical file in > /opt/csw/lib, and denies using symlinks. > As far as I can think of, there is no clean simple grammatical > construct you can use, that covers ?"move the file, or make a > symlink". > Using the word "move" in the spec, denies the use of sylinks. The > whole point of symlinking, is to NOT move, but make a reference > instead. Please take another look at the revision 2011-02-08 of the document, I don't think it mandates the use of regular files only. http://wiki.opencsw.org/proposal:shared-library-placement Maciej From jcraig at opencsw.org Tue Feb 8 23:12:13 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Tue, 8 Feb 2011 17:12:13 -0500 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: On Tue, Feb 8, 2011 at 3:34 PM, Philip Brown wrote: > On Tue, Feb 8, 2011 at 10:08 AM, Peter FELECAN wrote: >> Philip Brown writes: > >>> So, especially given that not all people read their email every day, >>> it is better to give room for that, with a 1 week minimum discussion >>> period for policy. >> >> A week seems alright for me. What about a maximum after which, if >> there's no consensus we proceed to a vote? 10 days seems enough and >> prevents evaporation. > > > Some discussions take longer than 10 days. I dont think putting an > automatic vote trigger in place is neccessarily the right thing to do. > > If on the other hand, discussion has stalled for [x] amount of time, I > think it would be fair to allow for any concerned party to call for a > vote, which should then be acted upon. > The tricky bit is in objectively defining "stalled" (vs "being > contended"), and what a good value of "x" is. The easy answer is after 10 days a majority can force a vote, but then they may just go ahead and vote the decision. I would hope that one would not simply cast a vote to stifle discussion, but its a risk that must be taken. It seems like your concern is over protecting the minority voice. So, what are the minority rights? Do we have the equivalent of a filibuster? Should the minority have the right to block progress? From phil at bolthole.com Wed Feb 9 00:00:57 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Feb 2011 15:00:57 -0800 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: On Tue, Feb 8, 2011 at 2:12 PM, Jonathan Craig wrote: > > The easy answer is after 10 days a majority can force a vote, but then you have to tally "votes" to see if "a majority" is asking for a vote, before voting :) I dont think that is very workable. > It seems like your concern is over protecting the minority voice. yup. > ?So, > what are the minority rights? Do we have the equivalent of a > filibuster? ?Should the minority have the right to block progress? I dont think that filibusters are a good thing. On the flip side, I dont think that a majority just ignoring issues raised by a minority group, because "hey we've got enough people to just ignore them" is a good thing either. IDEALLY, this sort of thing would be handled by a project secretary, who would be fair and impartial to judge whether each side's concerns are being properly heard and discussed, before the vote takes place. Unfortunately, and putting this as respectfully as possible, I'm not sure that our current secretary is a good example of impartiality when it comes to listening to both sides. So we may be better off with some other mechanism. Also, we need to make sure that the writeup for a vote, is done fairly. We've already been through a vote where the writeup was unfairly biased towards one side, because only one person wrote it. I think it's important that for "issue" type votes, a person from each "side", gets to write their respective side of the ballot writeup. From maciej at opencsw.org Wed Feb 9 00:12:33 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 8 Feb 2011 23:12:33 +0000 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: Peter (F) and Phil, since you've volunteered for the policy-team, could you review my proposed code change? http://lists.opencsw.org/pipermail/maintainers/2011-February/013970.html Maciej From bwalton at opencsw.org Wed Feb 9 02:44:28 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 08 Feb 2011 20:44:28 -0500 Subject: [csw-maintainers] [policy] GPG Signing Key handling Message-ID: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> Hi All, The board has been in discussion with Phil about holding the GPG signing key in its possession and has reached a bit of an impasse. We've discussed a few different configurations of which positions on the board should hold the key but have not come to an agreement. As has been pointed out several times in the conversation, this is an important issue and will impact the project well into the future. It's important that we make a good choice now. To that end, the board has decided that a vote shall be held to ascertain what the members of the project feel is the best way to proceed. The vote will allow you to individually decide whether each of the three board positions (not people, as the people will change) should hold the key. Each position that receives 50% support will be responsible for securely holding a copy of the key. It will then pass from person to person as new boards come and go. It will be possible for you, as a group, to decide that no member of the board should hold the key. This would happen when no position receives 50% support. This is an equally valid potential result. I'm avoiding presenting either the Phil's position or that of the board here as I'm hoping that any discussion around this is sparked from your own initial reactions. That's not to say that these are secret by any means either, just that I don't want to frame the discussion starting from either point of view. The vote will be open to all members and will run for 7 days. Please review the language below and present any clarifications you'd like for public discussion. The vote will be initiated once discussion seems to be abating. The planned phrasing of the ballot is: The GPG signing key is an important asset for OpenCSW. As a member of OpenCSW, you are asked to make three yes or no selections, one per board position, to indicate which, if any, of the board positions you feel should hold a copy of the key. Selecting yes for a position indicates that you feel this position (and consequently the person holding this position from year to year) should be responsible for holding a copy of the key. Selecting no indicates that you do not want this position to hold the key. Question 1: Should the Secretary position hold the key? yes/no Question 2: Should the Treasurer position hold the key? yes/no Question 3: Should the President position hold the key? yes/no Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Wed Feb 9 05:24:20 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Feb 2011 20:24:20 -0800 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> Message-ID: On Tuesday, February 8, 2011, Ben Walton wrote: > Please review the language below and present any clarifications you'd > like for public discussion. ?The vote will be initiated once > discussion seems to be abating. I find it very odd that this voting issue be raised, without any mention of why it was even brought up. (I'm not even sure why myself) clarifications, for those who may not be aware of this: it should be noted that two separate people/roles currently hold the key already; the release manager, and the backup release manager. So it is already redundantly held. you also do not make any statement of justification why -any- board member position should hold a copy of the key, in addition to these positions. A question then should also be raised of whether "the board" is expected to hold a copy of *all* digital assets at all times. For example, the root password, and database master passwords, for every machine and service associated with opencsw. Currently, "the board" does not hold such things in a formal sense, and as far as I have heard, has no plans to do so as "a policy". I have pointed this out to the board, and asked for an explanation of why they think the signing key should be treated any differently than these other secure assets. I have received no reply to that. For my own personal opinion, I think that IF the membership deems it appropriate that a board member always have a copy of the key, then the treasurer seems like the appropriate position. However, if delegation of responsability and security is enough for those other things, it seems it should be good enough for the keys as well. From phil at bolthole.com Wed Feb 9 05:48:53 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Feb 2011 20:48:53 -0800 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses Message-ID: 2011/2/8 Maciej Blizi?ski : > Peter (F) and Phil, since you've volunteered for the policy-team, > could you review my proposed code change? > > http://lists.opencsw.org/pipermail/maintainers/2011-February/013970.html > oh yikes. That brings up another issue... I dont recall that everyone agreed on a "license" for our docs & policies. If you insist on copying things verbatim from the debian one, we may get theirs imposed on us. the whole viralness of GPL. If on the other hand, we dont copy, then we are free to choose our own at a later date. From phil at bolthole.com Wed Feb 9 05:56:26 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Feb 2011 20:56:26 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/8 Maciej Blizi?ski : > 2011/2/8 Philip Brown : > >> As far as I can think of, there is no clean simple grammatical >> construct you can use, that covers ?"move the file, or make a >> symlink". >> Using the word "move" in the spec, denies the use of sylinks. The >> whole point of symlinking, is to NOT move, but make a reference >> instead. > > Please take another look at the revision 2011-02-08 of the document, I > don't think it mandates the use of regular files only. > > http://wiki.opencsw.org/proposal:shared-library-placement As requested, I took another look. I hate to say it, but perhaps must do so. Please take this in the most neutral manner; perhaps you are missing a nuance of English in this. Using the word "move", disallows symlinks. You have to use a different word. The last paragraphs almost make flexible use of the word "move", but only becuase they dont fully mandate putting anything in /opt/csw/lib at all. In contrast, where you do mandate something, you unambiguously used the word "move" again. " If a library previously thought to be private is in fact needed by other software, it has to be first moved to the shared library location," SO: "has to" == "must" "moved to the shared library location" == "mv blah.so /opt/csw/lib". That wording disallows symlinks. From maciej at opencsw.org Wed Feb 9 08:48:09 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 9 Feb 2011 07:48:09 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/9 Philip Brown : > 2011/2/8 Maciej Blizi?ski : >> 2011/2/8 Philip Brown : >> >>> As far as I can think of, there is no clean simple grammatical >>> construct you can use, that covers ?"move the file, or make a >>> symlink". >>> Using the word "move" in the spec, denies the use of sylinks. The >>> whole point of symlinking, is to NOT move, but make a reference >>> instead. >> >> Please take another look at the revision 2011-02-08 of the document, I >> don't think it mandates the use of regular files only. >> >> http://wiki.opencsw.org/proposal:shared-library-placement > > As requested, I took another look. > > I hate to say it, but perhaps must do so. Please take this in the most > neutral manner; > perhaps you are missing a nuance of English in this. Using the word > "move", disallows symlinks. > You have to use a different word. > > The last paragraphs almost make flexible use of the word "move", but > only becuase they dont fully mandate putting anything in /opt/csw/lib > at all. > > In contrast, where you do mandate something, you unambiguously used > the word "move" again. > > " If a library previously thought to be private is in fact needed by > other software, it has to be first moved to the shared library > location," > > SO: > > "has to" == "must" > > "moved to the shared library location" == "mv blah.so /opt/csw/lib". Yes, and "blah.so" could be either a regular file, or a symlink. What it is, does not matter in this paragraph. What the paragraph says, is that it has to be moved. The text doesn't use the "a library or a symlink to it" expression each time, because if we started to do this in every case where symlinks could be used, the policy would be rather unreadable. We could add a paragraph clarifying that were the word "library" or "file"[1] is used, it is a shorthand for making that file available either as a regular file, or as a symlink to it. > That wording disallows symlinks. Phil, could you address the paragraph from the link below? It concerns the very issue of symlinks. http://lists.opencsw.org/pipermail/maintainers/2011-February/014016.html Maciej [1] I'm using quotes, because I'm refering to the literal strings, not because I think that they are not really libraries or files. From pfelecan at opencsw.org Wed Feb 9 09:25:21 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 09 Feb 2011 09:25:21 +0100 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 8 Feb 2011 23:12:33 +0000") References: Message-ID: Maciej Blizi?ski writes: > Peter (F) and Phil, since you've volunteered for the policy-team, > could you review my proposed code change? > > http://lists.opencsw.org/pipermail/maintainers/2011-February/013970.html Already reviewed it. It's alright for me. -- Peter From maciej at opencsw.org Wed Feb 9 09:28:35 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 9 Feb 2011 08:28:35 +0000 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: Message-ID: 2011/2/9 Philip Brown : > 2011/2/8 Maciej Blizi?ski : >> Peter (F) and Phil, since you've volunteered for the policy-team, >> could you review my proposed code change? >> >> http://lists.opencsw.org/pipermail/maintainers/2011-February/013970.html >> > > oh yikes. That brings up another issue... I dont recall that everyone > agreed on a "license" for our docs & policies. Everyone as in everyone in policy-team (Peter F, you and me) or everyone in the project? Also, this change defines only policy's license, not the policy regulating licenses of all our documentation. To be specific, it sets the license for files that hold our policy manual and are stored under [1]. [1] https://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/opencsw-policy/ > If you insist on copying things verbatim from the debian one, we may > get theirs imposed on us. the whole viralness of GPL. > If on the other hand, we dont copy, then we are free to choose our own > at a later date. What do you suggest doing? From maciej at opencsw.org Wed Feb 9 09:34:13 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 9 Feb 2011 08:34:13 +0000 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: References: Message-ID: 2011/2/9 Peter FELECAN : > Maciej Blizi?ski writes: > >> Peter (F) and Phil, since you've volunteered for the policy-team, >> could you review my proposed code change? >> >> http://lists.opencsw.org/pipermail/maintainers/2011-February/013970.html > > Already reviewed it. It's alright for me. Thanks. Phil has raised a question about the license in [1], so I can't commit the change. Please chime in, perhaps let me interpret that e-mail. I'm not sure what does Phil imply in his question. Maciej [1] http://lists.opencsw.org/pipermail/maintainers/2011-February/014046.html From pfelecan at opencsw.org Wed Feb 9 09:38:58 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 09 Feb 2011 09:38:58 +0100 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Tue, 08 Feb 2011 20:44:28 -0500") References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > The GPG signing key is an important asset for OpenCSW. As a member of > OpenCSW, you are asked to make three yes or no selections, one per > board position, to indicate which, if any, of the board positions you > feel should hold a copy of the key. Selecting yes for a position > indicates that you feel this position (and consequently the person > holding this position from year to year) should be responsible for > holding a copy of the key. Selecting no indicates that you do not > want this position to hold the key. The GPG signing key is the asset of the OpenCSW foundation. The representatives of the foundation are the 3 board main members. Consequently it should be held by them. I think that today we have the following situation: the previous president of the foundation and a non member of the foundation hold the GPG signing key. This is unacceptable. I cannot resist the caricature of this: as if George W. Bush and Kim Jong Il holds exclusively the nuclear codes of the United States. -- Peter From pfelecan at opencsw.org Wed Feb 9 09:43:09 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 09 Feb 2011 09:43:09 +0100 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: (Philip Brown's message of "Tue, 8 Feb 2011 20:24:20 -0800") References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > A question then should also be raised of whether "the board" is > expected to hold a copy of *all* digital assets at all times. > For example, the root password, and database master passwords, for > every machine and service associated with opencsw. Currently, "the > board" does not hold such things in a formal sense, and as far as I > have heard, has no plans to do so as "a policy". You brought up a very interesting issue and I think that indeed the board must have the root password and database master passwords. However, this is not in the scope of this discussion. -- Peter From pfelecan at opencsw.org Wed Feb 9 09:46:51 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 09 Feb 2011 09:46:51 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: (Philip Brown's message of "Tue, 8 Feb 2011 20:48:53 -0800") References: Message-ID: Philip Brown writes: > 2011/2/8 Maciej Blizi?ski : >> Peter (F) and Phil, since you've volunteered for the policy-team, >> could you review my proposed code change? >> >> http://lists.opencsw.org/pipermail/maintainers/2011-February/013970.html >> > > oh yikes. That brings up another issue... I dont recall that everyone > agreed on a "license" for our docs & policies. > > If you insist on copying things verbatim from the debian one, we may > get theirs imposed on us. the whole viralness of GPL. > If on the other hand, we dont copy, then we are free to choose our own > at a later date. The "viralness" of the GPL is almost FUD --- I say "almost" because IANAL. BTW, what's wrong with GPL concerning the document describing our policies? -- Peter From pfelecan at opencsw.org Wed Feb 9 09:56:18 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 09 Feb 2011 09:56:18 +0100 Subject: [csw-maintainers] [POLICY] Policy-team In-Reply-To: (Philip Brown's message of "Tue, 8 Feb 2011 15:00:57 -0800") References: Message-ID: Philip Brown writes: > On Tue, Feb 8, 2011 at 2:12 PM, Jonathan Craig wrote: >> >> The easy answer is after 10 days a majority can force a vote, > > but then you have to tally "votes" to see if "a majority" is asking > for a vote, before voting :) > I dont think that is very workable. > >> It seems like your concern is over protecting the minority voice. > > yup. > >> ?So, >> what are the minority rights? Do we have the equivalent of a >> filibuster? ?Should the minority have the right to block progress? > > I dont think that filibusters are a good thing. > On the flip side, I dont think that a majority just ignoring issues > raised by a minority group, because "hey we've got enough people to > just ignore them" is a good thing either. > > IDEALLY, this sort of thing would be handled by a project secretary, > who would be fair and impartial to judge whether each side's concerns > are being properly heard and discussed, before the vote takes place. > > Unfortunately, and putting this as respectfully as possible, I'm not > sure that our current secretary is a good example of impartiality when > it comes to listening to both sides. > So we may be better off with some other mechanism. > > Also, we need to make sure that the writeup for a vote, is done > fairly. We've already been through a vote where the writeup was > unfairly biased towards one side, because only one person wrote it. > I think it's important that for "issue" type votes, a person from each > "side", gets to write their respective side of the ballot writeup. All the above, including personal judgment, shows that you are so afraid of losing your little power. All this petty protection of a minority formed by one person and its possible clique... Not wanting to make a Reductio ad Hitlerum type of argument I abstain to go further. -- Peter From dam at opencsw.org Wed Feb 9 10:05:05 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Feb 2011 10:05:05 +0100 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: Message-ID: <25D5D343-0CEE-4F52-B0AB-E258F9257E01@opencsw.org> Hi Phil, Am 08.02.2011 um 23:01 schrieb Philip Brown: > On Tue, Feb 8, 2011 at 1:20 PM, Dagobert Michelsen wrote: >> Am 08.02.2011 um 21:40 schrieb Philip Brown: >>> A silly little example being >>> >>> for f in `find . -type f | xargs grep -l /usr/local` ; do >>> sed 's:/usr/local:/opt/csw:g' $f >$f.cswfix; mv $f.cswfix $f >>> done >>> >>> Feel free to rewrite in your preferred language of perl, python, or >>> whatever floats your boat :) >> >> You are not serious about this, right? > > Well, I would certainly prefer that people manually inspect and replace. > But for those people whining that this takes too much effort, the > above provides an almost effortless alternative. As I outlined below it is worth than doing nothing. >> I inspected a couple of my package >> and every occurence needs to be verified manually. There are even >> scripts looking for configuration stuff which should keep the include >> to /usr/local but must have /opt/csw manually added and the check >> overridden. > > I would be interested to hear more details, about specific cases where > the above script did something "bad". I think that all maintainers > would benefit from this information. Think of "The default location for package installation is /usr/local if you don't specify --prefix". Changing this to /opt/csw would be plain wrong. There are lots of other cases. >> This is even more bad than keeping /usr/local because it says "I have >> looked at it and judged to replace it" instead of "well, I kept the >> defaults, if they are wrong I look again". > > But if they dont even look, how are they going to come to the point of > examining the defaults, knowing they are wrong, and "looking again"? Because there is a bug report. And because noone has tainted the defauls they are clearly visible. > In some cases, having wrong defaults, does not "break" the app. but > you silently lose functionality. > The maintainer may never notice that unless they explicitly examine > all /usr/local occurrences. > Which is what I'm in favor of, but others are opposed to. Not at all. I doubted the use of the /usr/local | /usr/share checks, but after inspecting yaz I came to the opinion that the checks are useful in general and really increase quality. But at the same time I came to the opinion the blindly replacing occurrences makes the situation worse by inadvertently changing valid occurrences. >> BTW, I found in yaz a real positive where tons of stuff is correctly >> auto-configured with the exception of one path to /usr/local/share/... >> and a comment /* Don't know how to make this with autoconf */ :-( >> And, yes, this is important to 100% functionality. > > That's nice that yaz "does the right thing" for 99%. > Nothing wrong with csw-specific patching for that "one path" that they > dont know how to autoconf either though. Exactly my point. The check was good as it revealed the issue. But if you change pathes do it consciously or not at all and delay inspection for some later time, but not a half-hearted job. Best regards -- Dago From phil at bolthole.com Wed Feb 9 15:54:02 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 9 Feb 2011 06:54:02 -0800 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: <25D5D343-0CEE-4F52-B0AB-E258F9257E01@opencsw.org> References: <25D5D343-0CEE-4F52-B0AB-E258F9257E01@opencsw.org> Message-ID: On Wed, Feb 9, 2011 at 1:05 AM, Dagobert Michelsen wrote: > Hi Phil, *wave* >>> I inspected a couple of my package >>> and every occurence needs to be verified manually. There are even >>> scripts looking for configuration stuff which should keep the include >>> to /usr/local but must have /opt/csw manually added and the check >>> overridden. >> >> I would be interested to hear more details, about specific cases where >> the above script did something "bad". I think that all maintainers >> would benefit from this information. > > Think of "The default location for package installation is /usr/local if > you don't specify --prefix". Changing this to /opt/csw would be plain > wrong. There are lots of other cases. Errr.. those are build instructions. The general case for that type of "error", is "anything that relates to people *building* the package". Yes, its technically "wrong" to change that, but on the other hand, it will in no way hurt users, since they're not the ones building the package. Any other class of error for this, that you can think of? btw, I'm all for a more intelligent auto-changer, that does the changes, but also reports back to the maintainer, "this is what I changed". For the gar afficionados, this should be easy, if you leverage the git stuff before and after. >> But if they dont even look, how are they going to come to the point of >> examining the defaults, knowing they are wrong, and "looking again"? > > Because there is a bug report. You are making the very VERY wrong assumption, that bug reports, magically, accurately, and always appear for problems. Unfortunately, the opposite is more often true. Just a month ago, I discovered a bug, of this very nature(unfixed /usr/local reference), in a package, because of the autochecker. It had been there for YEARS. No one had noticed it, or at least no one reported it. So the package was missing proper functionality. Not critial "it doesnt work!" functionality, but still missing. From phil at bolthole.com Wed Feb 9 15:57:30 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 9 Feb 2011 06:57:30 -0800 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: Message-ID: On Wed, Feb 9, 2011 at 12:46 AM, Peter FELECAN wrote: > Philip Brown writes: > >> 2011/2/8 Maciej Blizi?ski : >>> Peter (F) and Phil, since you've volunteered for the policy-team, >>> could you review my proposed code change? >>> >>> http://lists.opencsw.org/pipermail/maintainers/2011-February/013970.html >>> >> >> oh yikes. That brings up another issue... I dont recall that everyone >> agreed on a "license" for our docs & policies. >> >> If you insist on copying things verbatim from the debian one, we may >> get theirs imposed on us. the whole viralness of GPL. >> If on the other hand, we dont copy, then we are free to choose our own >> at a later date. > > The "viralness" of the GPL is almost FUD --- I say "almost" because > IANAL. > > BTW, what's wrong with GPL concerning the document describing > our policies? Potentially nothing. If everyone agrees to it, then nothing. It's just wrong to force a choice on people. There are some people out there (general public), who have voiced unhappiness with the "GNU Free Documentation" license, for one thing. They had specific technical reasons why, although unfortunatley I dont remember the details. Maciej writes: >What do you suggest doing? I suggest not copying from debian directly, but putting in our own words. Then we dont have to fuss over licensing at all right now. I also suggest that we could link to it, when and if long chunks are useful, rather than copying. From phil at bolthole.com Wed Feb 9 16:14:17 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 9 Feb 2011 07:14:17 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/8 Maciej Blizi?ski : > > The text doesn't use the "a library or a symlink to it" expression > each time, because if we started to do this in every case where > symlinks could be used, the policy would be rather unreadable. > Perhaps we need to take a very different wording style, rather than attempting to just make small changes. Something like, "The library needs to have a presence in /opt/csw/lib" or "the library needs to be linkable with -L/opt/csw/lib." Although personally, i think if we just settle the issue of symlinks now vs later, then the writing will be simpler. From pfelecan at opencsw.org Wed Feb 9 17:02:14 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 09 Feb 2011 17:02:14 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: (Philip Brown's message of "Wed, 9 Feb 2011 06:57:30 -0800") References: Message-ID: Philip Brown writes: > On Wed, Feb 9, 2011 at 12:46 AM, Peter FELECAN wrote: >> Philip Brown writes: >> >>> 2011/2/8 Maciej Blizi?ski : >>>> Peter (F) and Phil, since you've volunteered for the policy-team, >>>> could you review my proposed code change? >>>> >>>> http://lists.opencsw.org/pipermail/maintainers/2011-February/013970.html >>>> >>> >>> oh yikes. That brings up another issue... I dont recall that everyone >>> agreed on a "license" for our docs & policies. >>> >>> If you insist on copying things verbatim from the debian one, we may >>> get theirs imposed on us. the whole viralness of GPL. >>> If on the other hand, we dont copy, then we are free to choose our own >>> at a later date. >> >> The "viralness" of the GPL is almost FUD --- I say "almost" because >> IANAL. >> >> BTW, what's wrong with GPL concerning the document describing >> our policies? > > Potentially nothing. > If everyone agrees to it, then nothing. Alright. If somebody is against using GPL for licensing our policies document now is the time to speak up. > It's just wrong to force a choice on people. > There are some people out there (general public), who have voiced > unhappiness with the "GNU Free Documentation" license, for one thing. > They had specific technical reasons why, although unfortunatley I dont > remember the details. > > Maciej writes: >>What do you suggest doing? > > I suggest not copying from debian directly, but putting in our own > words. Then we dont have to fuss over licensing at all right now. > I also suggest that we could link to it, when and if long chunks are > useful, rather than copying. I think that adapting the Debian policies is a very wise choice. I'm against dumbing down by a rewrite with "our[you] own words". We don't have the resources to reinvent this stuff also and we need formal policies this century. -- Peter From pfelecan at opencsw.org Wed Feb 9 17:05:33 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 09 Feb 2011 17:05:33 +0100 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: (Philip Brown's message of "Wed, 9 Feb 2011 06:54:02 -0800") References: <25D5D343-0CEE-4F52-B0AB-E258F9257E01@opencsw.org> Message-ID: Philip Brown writes: > On Wed, Feb 9, 2011 at 1:05 AM, Dagobert Michelsen wrote: >> Hi Phil, > > *wave* > > >>>> I inspected a couple of my package >>>> and every occurence needs to be verified manually. There are even >>>> scripts looking for configuration stuff which should keep the include >>>> to /usr/local but must have /opt/csw manually added and the check >>>> overridden. >>> >>> I would be interested to hear more details, about specific cases where >>> the above script did something "bad". I think that all maintainers >>> would benefit from this information. >> >> Think of "The default location for package installation is /usr/local if >> you don't specify --prefix". Changing this to /opt/csw would be plain >> wrong. There are lots of other cases. > > Errr.. those are build instructions. The general case for that type of > "error", is > "anything that relates to people *building* the package". > Yes, its technically "wrong" to change that, but on the other hand, it > will in no way hurt users, since they're not the ones building the > package. > > Any other class of error for this, that you can think of? In a previous message of this thread I gave the example of gcc3 where my README.CSW mentions the lack of /usr/local and the usage of /opt/csw which is very valid. > btw, I'm all for a more intelligent auto-changer, that does the > changes, but also reports back to the maintainer, "this is what I > changed". > For the gar afficionados, this should be easy, if you leverage the git > stuff before and after. > >>> But if they dont even look, how are they going to come to the point of >>> examining the defaults, knowing they are wrong, and "looking again"? >> >> Because there is a bug report. > > You are making the very VERY wrong assumption, that bug reports, > magically, accurately, and always appear for problems. > Unfortunately, the opposite is more often true. This is as strong as the opposite assumption. > Just a month ago, I discovered a bug, of this very nature(unfixed > /usr/local reference), in a package, because of the autochecker. It > had been there for YEARS. No one had noticed it, or at least no one > reported it. So the package was missing proper functionality. > Not critial "it doesnt work!" functionality, but still missing. Can you give the exact circumstances? Which package and what issue? -- Peter From phil at bolthole.com Wed Feb 9 18:01:30 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 9 Feb 2011 09:01:30 -0800 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: Message-ID: On Wed, Feb 9, 2011 at 8:02 AM, Peter FELECAN wrote: > we need formal > policies [from?] this century. Well great! Thank you for your vote to NOT copy debian policies. After all, they are pretty much mostly written in the LAST century :) Most of our policies are already written up. You make it sound like we are facing a choice of either writing hundreds of pages ourselves, or copying wholesale from debian. This is a false choice. Most of the policies we need, we already have written up. From maciej at opencsw.org Wed Feb 9 20:09:52 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 9 Feb 2011 19:09:52 +0000 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: Message-ID: 2011/2/9 Philip Brown : > On Wed, Feb 9, 2011 at 8:02 AM, Peter FELECAN wrote: >> we need formal >> policies [from?] this century. I don't think this is what Peter meant. I think he meant that we need to have policies before our century ends. > Well great! Thank you for your vote to NOT copy debian policies. > After all, they are pretty much mostly written in the LAST century :) > > Most of our policies are already written up. You make it sound like we > are facing a choice of either writing hundreds of pages ourselves, or > copying wholesale from debian. > This is a false choice. Most of the policies we need, we already have > written up. Please point me at our abstract and copyright notice. From phil at bolthole.com Wed Feb 9 21:23:20 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 9 Feb 2011 12:23:20 -0800 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: Message-ID: 2011/2/9 Maciej Blizi?ski : > 2011/2/9 Philip Brown : >> >> Most of our policies are already written up. You make it sound like we >> are facing a choice of either writing hundreds of pages ourselves, or >> copying wholesale from debian. >> This is a false choice. Most of the policies we need, we already have >> written up. > > Please point me at our abstract and copyright notice. > I did say "most", not "all". But since you bring those things up: Do we really *need* a copyright notice? Why? Are we deathly afraid someone is going to "steal" our policies, and.... what, exactly? I'm also not sure what is the huge need for "an abstract". or even if there is, why this is so difficult to do ourselves quickly and easily. Going by http://www.debian.org/doc/debian-policy/ their "abstract" consists of two lines, which basically say, "This is the policy manual. Stuff in debian, needs to follow debian policy.". well, Duh. From skayser at opencsw.org Thu Feb 10 01:56:27 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 10 Feb 2011 01:56:27 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: Message-ID: <20110210005627.GA21610@sebastiankayser.de> * Philip Brown wrote: > 2011/2/9 Maciej Blizi??ski : > > 2011/2/9 Philip Brown : > >> > >> Most of our policies are already written up. You make it sound like we > >> are facing a choice of either writing hundreds of pages ourselves, or > >> copying wholesale from debian. > >> This is a false choice. Most of the policies we need, we already have > >> written up. > > > > Please point me at our abstract and copyright notice. > > > > I did say "most", not "all". > > But since you bring those things up: > Do we really *need* a copyright notice? Why? Are we deathly afraid > someone is going to "steal" our policies, and.... what, exactly? Is there any harm in having a license? No. So please focus on the relevant parts. > I'm also not sure what is the huge need for "an abstract". or even if > there is, why this is so difficult to do ourselves quickly and easily. > Going by > http://www.debian.org/doc/debian-policy/ > their "abstract" consists of two lines, which basically say, "This is > the policy manual. Stuff in debian, needs to follow debian policy.". If you guys start to discuss whether the _abstract_ (i.e. not even actual policies) needs to be 2 or 5 lines long I feel that the policy team isn't off to a good start. Sebastian From bwalton at opencsw.org Thu Feb 10 02:54:21 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Feb 2011 20:54:21 -0500 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: Message-ID: <1297302509-sup-3653@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Feb 08 17:01:16 -0500 2011: > Well, I would certainly prefer that people manually inspect and > replace. Or, manually inspect and _not_ replace. That is possibly a valid option in some cases. I'm with Dago on this. Manual inspection is a must. Checkpkg will point out problem files, so it's not even a matter of grepping the source tree by hand now. > But for those people whining that this takes too much effort, the > above provides an almost effortless alternative. I don't think anyone has complained about the effort involved. The complaints were centred around the how suddenly this check came into sight. > That's nice that yaz "does the right thing" for 99%. Nothing wrong > with csw-specific patching for that "one path" that they dont know > how to autoconf either though. Correct. And we (I'll take a look when I have a chance) can possibly help with the autoconf-foo to make it right by default too. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Feb 10 03:16:26 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Feb 2011 21:16:26 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Feb 07 23:07:51 -0500 2011: > yes. I've already written this, AND I've already written why. > Because that is the "normal" way that programs install things, when > you compile with > configure --prefix=/opt/csw/prefix Ok, this is technically correct, but as Maciej has pointed out, it's valid to: ./configure --prefix=/opt/csw/prefix --libdir=/opt/csw/lib. One is more normal, agreed, but both are valid. I think we're spending a lot of time on this discussion for a part of the policy that ultimately pertains to a small percentage of our packages. If we can step back for a moment, lets consider the clean solution to this: ./configure --prefix=/opt/csw That's right, if we had alternatives in the first place, we most likely wouldn't even be having this conversation. The intent of the proposal is that we _can_ move libraries back to the natural (within the scope of the entire catalog) location while still preserving the legacy package-specific prefix. I'll even grant that in this specific context, the symlink direction doesn't matter all that much. Consider though that the next steps may (will?) aim at coalescing other bits of these special packages back towards a standard ./configure --prefix=/opt/csw. Doesn't it make sense to _prefer_ (should, not must) the catalog traditional location? /me feels like he's choosing a paint colour for the bike shed. :( > Plus the issue about keeping "du -k" output consistent within the > program files for a prefix. This is not a non-issue. I understand that you say you find it useful, but it's not something you could do if the package were built more naturally within the scope of our catalog. Your ability to do it today is a side effect of our past inability to build these packages with standard directory locations. If we start considering side effects as weighted factors when setting policy, we're doomed. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Feb 10 03:22:56 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Feb 2011 21:22:56 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: <1297304275-sup-3022@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Feb 09 10:14:17 -0500 2011: > "The library needs to have a presence in /opt/csw/lib" > or "the library needs to be linkable with -L/opt/csw/lib." I prefer the second wording choice. > Although personally, i think if we just settle the issue of symlinks > now vs later, then the writing will be simpler. I'm of half a mind to agree with this, but... In hopes of actually getting this piece of the policy completed, I think we should define it without forcing the symlink direction. Language such as used above is functional and gets the ability to link without additional paths passed in. Additionally, if a package is ever consolidated back to standard paths, it won't matter anyway since there will ultimately be file(s) in /opt/csw/lib instead of the old location. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Feb 10 03:48:54 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Feb 2011 21:48:54 -0500 Subject: [csw-maintainers] list etiquette Message-ID: <1297305155-sup-9646@pinkfloyd.chass.utoronto.ca> Hi All, I've had a few requests to speak to other maintainers about language and/or tone used during discussions we've had over the past few weeks. I think that you're all of sound mind and therefore do not need me to tell you what to do or how to behave. What I will do instead is try to set an example. I would like a list where people feel free to voice dissenting opinions without being ridiculed. I would like a list where ideas are attacked, not individuals. It's incredibly easy to run astray of the above principles in a heated discussion. I personally delete many draft messages... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Feb 10 03:57:17 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Feb 2011 21:57:17 -0500 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: Message-ID: <1297306386-sup-2143@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Wed Feb 09 11:02:14 -0500 2011: > Alright. If somebody is against using GPL for licensing our policies > document now is the time to speak up. I fully support using the GPL v2+ for our documentation. > I think that adapting the Debian policies is a very wise choice. I'm > against dumbing down by a rewrite with "our[you] own words". We > don't have the resources to reinvent this stuff also and we need > formal policies this century. Agreed. The Debian folks have invested a large amount of time and energy into their documentation. Phil is correct that we do have existing documentation that can be imported, but where possible, if we can save time by importing and then modifying their work, that's a win. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Feb 10 04:02:26 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Feb 2011 22:02:26 -0500 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: <1297306386-sup-2143@pinkfloyd.chass.utoronto.ca> References: <1297306386-sup-2143@pinkfloyd.chass.utoronto.ca> Message-ID: <1297306711-sup-5849@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Wed Feb 09 21:57:17 -0500 2011: > energy into their documentation. Phil is correct that we do have > existing documentation that can be imported, but where possible, if we > can save time by importing and then modifying their work, that's a > win. Sorry, I hit the send button too quickly here... By 'importing and modifying their work' I'm referring to cases where we'd be filling in gaps in our own policies. I do not mean that we should make this the default practice for every piece of our policy. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Feb 10 04:17:07 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Feb 2011 22:17:07 -0500 Subject: [csw-maintainers] [POLICY] Shared library placement proposal In-Reply-To: References: <1297003242-sup-8556@pinkfloyd.chass.utoronto.ca> <1297099461-sup-1716@pinkfloyd.chass.utoronto.ca> <1297133366-sup-8095@pinkfloyd.chass.utoronto.ca> Message-ID: <1297307050-sup-383@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Feb 07 23:03:39 -0500 2011: > On Mon, Feb 7, 2011 at 6:55 PM, Ben Walton wrote: > > E > >> Please take the appropriate section, write it in normal-people > >> language as much as possible, and put it on our own pages. > > > > Why the insistence on dumbed-down language? ?These documents are aimed > > at maintainers, not the general public. > > By saying, that you are saying, "maintainers are 'special': they're > smarter than 'the general public'. The general public is too stupid to > understand our elite documents, we shouldnt bother trying to write > docs for more 'common' people" No. What I'm really saying is that we're writing to a technical audience that is already familiar with this type of language or fully able to comprehend it upon first encounter. > We should be moving away from elitism, not towards it. We need to be > more inclusive. I really don't see this as elitist. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Feb 10 04:57:46 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Feb 2011 22:57:46 -0500 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> Message-ID: <1297308294-sup-7358@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Feb 08 23:24:20 -0500 2011: Hi Phil, > I find it very odd that this voting issue be raised, without any > mention of why it was even brought up. (I'm not even sure why > myself) Well, I thought it was clear from the introduction. We've been in discussion with you about this and your point of view differs from ours. I've been considering how to bridge this gap and have even considered that your point of view is possibly correct. I'm not wholly convinced of that, but the points you made are not without merit. I also considered simply saying the equivalent of "my way or the highway" but didn't think that was appropriate for several reasons all of which are too obvious to mention. During our conversation, you said on more than one occasion that this issue is of the utmost importance to get right. I agree with this. Thus, as a group, we should decide how to do this. It should not happen based on your opinion, my opinion or that of the board as a group. Thus, I wrote the email last night to trigger this discussion with all members. Do you take issue with this decision being made by the full membership? If so, why? > the release manager, and the backup release manager. So it is > already redundantly held. Nothing slight against James, but as he's not a member, his holding the key does not count as redundancy for the purpose of this discussion. > you also do not make any statement of justification why -any- board > member position should hold a copy of the key, in addition to these > positions. As perhaps the most important record the community holds, it should be the responsibility of the board to hold it and delegate it's use in signing catalogs. > A question then should also be raised of whether "the board" is > expected to hold a copy of *all* digital assets at all times. This will be addressed in time. I won't speak for Maciej and Ihsan here, but my own though process is that the gpg key is the most important element and therefore a logical place to start. > For example, the root password, and database master passwords, for > every machine and service associated with opencsw. Currently, "the > board" does not hold such things in a formal sense, and as far as I > have heard, has no plans to do so as "a policy". Database, mailing list and similar passwords are one thing. Root passwords are different. I don't think that OpenCSW is going to tell Baltic Online or Gore to hand over passwords to servers. They are lending us the use of considerable resources and they do grant root access via sudo. I personally don't think it is our right to ask for the root password to those machines. > I have pointed this out to the board, and asked for an explanation > of why they think the signing key should be treated any differently > than these other secure assets. I have received no reply to that. No, you didn't get a reply. I apologize for that. > For my own personal opinion, I think that IF the membership deems it > appropriate that a board member always have a copy of the key, then > the treasurer seems like the appropriate position. I argue that the gpg key is equivalent to the royal signet. It is used to authenticate the validity of various documents. The secretary is the one charged with documents and their official status. Thus, if I had to choose a single board position to hold the key, my vote would be for the secretary. For redundancy purposes, I think that two or more positions should hold the key. In this scenario, my vote would be for treasurer and secretary. As the vote will allow selecting all or none of the positions, you'll be able to vote for whatever configuration you feel is appropriate. Please vote based on positions, though, not people. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Feb 10 05:04:38 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Feb 2011 23:04:38 -0500 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> Message-ID: <1297310347-sup-9989@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Wed Feb 09 03:43:09 -0500 2011: Hi Peter, > > A question then should also be raised of whether "the board" is > > expected to hold a copy of *all* digital assets at all times. > > For example, the root password, and database master passwords, for > > every machine and service associated with opencsw. Currently, "the > > board" does not hold such things in a formal sense, and as far as I > > have heard, has no plans to do so as "a policy". > > You brought up a very interesting issue and I think that indeed the > board must have the root password and database master > passwords. However, this is not in the scope of this discussion. I agree with you on the database passwords (and other passwords of similar nature), but as I mentioned in my reply to Phil, I'm not sure it is the right of the OpenCSW foundation to demand root passwords for equipment that we don't own. We're privileged to have these resources dedicated to our use. None of the sponsors are required to do this. It doesn't hurt to ask, but I personally would not want to force the issue if they say no. If we make demands such as this, they may reconsider their charity. Please let me know if you feel otherwise. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu Feb 10 05:59:31 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 9 Feb 2011 20:59:31 -0800 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: <1297302509-sup-3653@pinkfloyd.chass.utoronto.ca> References: <1297302509-sup-3653@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Feb 9, 2011 at 5:54 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Tue Feb 08 17:01:16 -0500 2011: > >> Well, I would certainly prefer that people manually inspect and >> replace. > > Or, manually inspect and _not_ replace. ?That is possibly a valid > option in some cases. ?I'm with Dago on this. ?Manual inspection is a > must. ?Checkpkg will point out problem files, so it's not even a > matter of grepping the source tree by hand now. > >> But for those people whining that this takes too much effort, the >> above provides an almost effortless alternative. > > I don't think anyone has complained about the effort involved. ?The > complaints were centred around the how suddenly this check came into > sight. well, wonderful. Does that mean we have "consensus" that this is the right thing to do moving forward then? And to answer a prior email, the circumstances of the recent occurence, were a package that pops up a dialog box that by default, has a particular set of directories that the user can choose from, along with manually typing in a full path to a different directory. /usr/local was present, /opt/csw/anything was not. So the user misses out on the "feature" of convenience, unless the /usr/local reference is either patched or augmented. From phil at bolthole.com Thu Feb 10 06:15:57 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 9 Feb 2011 21:15:57 -0800 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Feb 9, 2011 at 12:38 AM, Peter FELECAN wrote: >... > The GPG signing key is the asset of the OpenCSW foundation. > The representatives of the foundation are the 3 board main members. > Consequently it should be held by them. > > I think that today we have the following situation: the previous > president of the foundation and a non member of the foundation hold the > GPG signing key. I dont see how the current holder being "the previous president" has any relevance. Are you somehow suggesting that if I were not the prior president, that you would have no objections? Doesnt seem to make much sense to me. > Are you saying that This is unacceptable. I cannot resist the caricature of > this: as if George W. Bush and Kim Jong Il holds exclusively the nuclear > codes of the United States. and this is just gratuitously insulting. Ignoring the insulting one, and looking at the partially relevant bit objectively: The "nuclear codes" are meant to be held by "the president", because he has a functional role in deciding when and if to use it. Once he is no longer president, he no longer has that role, so no longer has access to those keys. In contrast, I hold the gpg signing key not because I was board president, but because I am the current release manager. Since I continue to be, for now, the current release manager, it makes sense for me to hold the keys, because I have a functional need to do so. If at some time in the future, there is a new release manager, I will turn over the key to them without complaint. As far as ALL 3 board members having the signing key, I dont think this is a good idea, for the following reason: You cant just "take back" a gpg signing key from someone at the end of their term, without revoking it for *everyone*. Revoking the key every year, would be a hardship and an irritation to our users. Because of this, I think it is best *for our users*, if it passes through as few hands as possible. I think the majority of members consider James to be a trustworthy person, as I hope they also do myself. While James has not requested to become "a member of the organization", he is still a maintainer in good standing. Not being a member, merely means he does not get a "vote" in things. I do not see how that makes him any less trustworthy, however. As such, I hope that the current level of redundancy for our signing keys will be deemed as adequate for our members. PS: to answer Ben's question: no I do not take object to having this issue decided by the full membership From phil at bolthole.com Thu Feb 10 06:25:25 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 9 Feb 2011 21:25:25 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> Message-ID: On Wednesday, February 9, 2011, Ben Walton wrote: > I think we're spending a lot of time on this discussion for a part of > the policy that ultimately pertains to a small percentage of our > packages. This is certainly true. Unfortunately, see below... > If we can step back for a moment, lets consider the clean solution to > this: > > ./configure --prefix=/opt/csw > > That's right, if we had alternatives in the first place, we most > likely wouldn't even be having this conversation. This is not true. So it would seem that you have missed one of the main points of this discussion. The issue, about "a small percentage of our packages", is that they CANNOT be packaged up with prefix=/opt/csw. Even with use of "alternatives" utils. This subdiscussion, is only relating to things that MUST have their own prefix. Certainly, if there are clean ways to compile it and install something with prefix=/opt/csw we should do so. But we are talking about the things that cannot. For example, the multiple versions of berkeleydb. That we have to have installed at the same time, and use as neccessary. It's not a matter of "pick this one, to be the 'real/active' one" >... > as Maciej has pointed out, it's > valid to: ./configure --prefix=/opt/csw/prefix --libdir=/opt/csw/lib. > One is more normal, agreed, but both are valid. In many cases, this works. In very rare cases, it does not. But that side of things isnt really the important thing here. What I've written before in this very thread thread, but I guess I have to repeat now, is that having the library detectable in $PREFIX/lib is important, not so much for the program itself, but for *other* programs that need to link with it. Unfortunately, some software has really dumb configuration. it only allows for --with-somelib=/install/prefix/here NOT --with-somelib-lib=/path1 --with-somelib-inc=path2 --with-somelib-utils=path3 Not having the shared lib visible in its expected place of $PREFIX/lib, would require some other programs to be heavily patched to compile it properly. So, it needs some kind of presence in *both* /opt/csw/lib and /opt/csw/PREFIX/lib So then we come back to symlinks, and which direction they should be. > If we start considering side effects as weighted factors when setting > policy, we're doomed. If everything else is equal, then side effects are then useful to consider. Functionally speaking, for achieving the goal of "allow use with -L/opt/csw/lib", direction of symlinks doesnt matter. At that point, the lesser side issues are fair play for a decision on which direction they should go. From maciej at opencsw.org Thu Feb 10 08:15:33 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 10 Feb 2011 07:15:33 +0000 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: <1297302509-sup-3653@pinkfloyd.chass.utoronto.ca> References: <1297302509-sup-3653@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/10 Ben Walton : > Excerpts from Philip Brown's message of Tue Feb 08 17:01:16 -0500 2011: > >> Well, I would certainly prefer that people manually inspect and >> replace. > > Or, manually inspect and _not_ replace. ?That is possibly a valid > option in some cases. I agree. However, an inspected and left reference to /usr/local will raise a question from the release manager. Perhaps we should have some sort of standardized way of communicating that the package maintainer knows about the reference and considers it valid. For example, an override entry added to the checkpkg_override file in the package. From maciej at opencsw.org Thu Feb 10 08:57:22 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 10 Feb 2011 07:57:22 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/10 Philip Brown : > This subdiscussion, is only relating to things that MUST have their own prefix. I am not entirely sure whether any software actually requires being compiled with a custom prefix. It's quite likely that every package currently compiled with a custom prefix, could be in fact compiled with --prefix=/opt/csw. Other steps can be taken to ensure compatibility with other versions of the same piece of software. > Certainly, if there are clean ways to compile it and install something > with prefix=/opt/csw we should do so. But we are talking about the > things that cannot. > For example, the multiple versions of berkeleydb. That we have to have > installed at the same time, and use as neccessary. It's not a matter > of "pick this one, to be the 'real/active' one" Are there two incompatible libdb-X.Y.so files with the same SONAME? If the answer is no, then BerkeleyDB can be compiled with --prefix=/opt/csw. >>... >> ?as Maciej has pointed out, it's >> valid to: ./configure --prefix=/opt/csw/prefix --libdir=/opt/csw/lib. >> One is more normal, agreed, but both are valid. > > ?In many cases, this works. In very rare cases, it does not. But that > side of things isnt really the important thing here. > > What I've written before in this very thread thread, but I guess I > have to repeat now, is that having the library detectable in > $PREFIX/lib is important, not so much for the program itself, but for > *other* programs that need to link with it. By $PREFIX, do you mean our prefix, or a different one? > Unfortunately, some software has really dumb configuration. it only allows for > --with-somelib=/install/prefix/here > NOT > ?--with-somelib-lib=/path1 --with-somelib-inc=path2 --with-somelib-utils=path3 > > Not having the shared lib visible in its expected place of > $PREFIX/lib, would require some other programs to be heavily patched > to compile it properly. > So, it needs some kind of presence in *both* /opt/csw/lib and > /opt/csw/PREFIX/lib I highly doubt this is the case. I haven't seen an example of source code which, configured with --prefix=/opt/csw, requires a library to be in /opt/csw/foo/lib, and can't be linked when that library is available through /opt/csw/lib. When a library is present in /opt/csw/lib, and the running binary contains /opt/csw/lib in RPATH, the library will always be found. All our binaries have /opt/csw/lib in RPATH, therefore all libraries in /opt/csw/lib will always be found. If there is a binary that needs OpenCSW libraries and does not have /opt/csw/lib in RPATH, it's a bug, right? >> If we start considering side effects as weighted factors when setting >> policy, we're doomed. > > If everything else is equal, then side effects are then useful to consider. > Functionally speaking, ?for achieving the goal of "allow use with > -L/opt/csw/lib", direction of symlinks doesnt matter. At that point, > the lesser side issues are fair play for a decision on which direction > they should go. While I agree with the general statement that if larger criteria are equal, considering smaller criteria is useful, I believe that the smaller criteria should be within the scope of our goals as the project. The output of "du -k" is not within OpenCSW's goals. If you would like to include the output of "du -k" in our policies, the proper way to do this is sending out a proposal. From pfelecan at opencsw.org Thu Feb 10 09:23:38 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 10 Feb 2011 09:23:38 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: (Philip Brown's message of "Wed, 9 Feb 2011 09:01:30 -0800") References: Message-ID: Philip Brown writes: > On Wed, Feb 9, 2011 at 8:02 AM, Peter FELECAN wrote: >> we need formal >> policies [from?] this century. > > > Well great! Thank you for your vote to NOT copy debian policies. > After all, they are pretty much mostly written in the LAST century :) Please restrain yourself of deforming my statements. My statement was that I' in favor of *adapting* Debian policies. Period. -- Peter From pfelecan at opencsw.org Thu Feb 10 09:28:25 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 10 Feb 2011 09:28:25 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: <20110210005627.GA21610@sebastiankayser.de> (Sebastian Kayser's message of "Thu, 10 Feb 2011 01:56:27 +0100") References: <20110210005627.GA21610@sebastiankayser.de> Message-ID: Sebastian Kayser writes: > * Philip Brown wrote: >> 2011/2/9 Maciej Blizi??ski : >> > 2011/2/9 Philip Brown : >> >> >> >> Most of our policies are already written up. You make it sound like we >> >> are facing a choice of either writing hundreds of pages ourselves, or >> >> copying wholesale from debian. >> >> This is a false choice. Most of the policies we need, we already have >> >> written up. >> > >> > Please point me at our abstract and copyright notice. >> > >> >> I did say "most", not "all". >> >> But since you bring those things up: >> Do we really *need* a copyright notice? Why? Are we deathly afraid >> someone is going to "steal" our policies, and.... what, exactly? > > Is there any harm in having a license? No. So please focus on the > relevant parts. > >> I'm also not sure what is the huge need for "an abstract". or even if >> there is, why this is so difficult to do ourselves quickly and easily. >> Going by >> http://www.debian.org/doc/debian-policy/ >> their "abstract" consists of two lines, which basically say, "This is >> the policy manual. Stuff in debian, needs to follow debian policy.". > > If you guys start to discuss whether the _abstract_ (i.e. not even > actual policies) needs to be 2 or 5 lines long I feel that the policy > team isn't off to a good start. I agree with you. This is exactly what I'm afraid when such noise is raised about 10 lines of text. Sterile divagation about license, copying, patrimony, &c. This is clearly a policy of obstruction. -- Peter From pfelecan at opencsw.org Thu Feb 10 09:41:42 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 10 Feb 2011 09:41:42 +0100 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: <1297310347-sup-9989@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Wed, 09 Feb 2011 23:04:38 -0500") References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> <1297310347-sup-9989@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Peter FELECAN's message of Wed Feb 09 03:43:09 -0500 2011: > > Hi Peter, > >> > A question then should also be raised of whether "the board" is >> > expected to hold a copy of *all* digital assets at all times. >> > For example, the root password, and database master passwords, for >> > every machine and service associated with opencsw. Currently, "the >> > board" does not hold such things in a formal sense, and as far as I >> > have heard, has no plans to do so as "a policy". >> >> You brought up a very interesting issue and I think that indeed the >> board must have the root password and database master >> passwords. However, this is not in the scope of this discussion. > > I agree with you on the database passwords (and other passwords of > similar nature), but as I mentioned in my reply to Phil, I'm not sure > it is the right of the OpenCSW foundation to demand root passwords for > equipment that we don't own. I thought mainly about database, mail and other privileged roles for thing *owned* by the foundation which excludes the root passwords for the build-farm servers. > We're privileged to have these resources dedicated to our use. None > of the sponsors are required to do this. It doesn't hurt to ask, but > I personally would not want to force the issue if they say no. If we > make demands such as this, they may reconsider their charity. Please > let me know if you feel otherwise. I'm letting you know that I don't feel otherwise. -- Peter From pfelecan at opencsw.org Thu Feb 10 11:25:19 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 10 Feb 2011 11:25:19 +0100 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: (Philip Brown's message of "Wed, 9 Feb 2011 21:15:57 -0800") References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Wed, Feb 9, 2011 at 12:38 AM, Peter FELECAN wrote: >>... >> The GPG signing key is the asset of the OpenCSW foundation. >> The representatives of the foundation are the 3 board main members. >> Consequently it should be held by them. >> >> I think that today we have the following situation: the previous >> president of the foundation and a non member of the foundation hold the >> GPG signing key. > > I dont see how the current holder being "the previous president" has > any relevance. Are you somehow suggesting that if I were not the prior > president, that you would have no objections?[...] Not at all. >> Are you saying that This is unacceptable. I cannot resist the caricature of >> this: as if George W. Bush and Kim Jong Il holds exclusively the nuclear >> codes of the United States. > > and this is just gratuitously insulting. Don't you understand metaphors? analogies? The purpose of this wasn't to insult but to show a similarity. > In contrast, I hold the gpg signing key not because I was board > president, but because I am the current release manager. Since I > continue to be, for now, the current release manager, it makes sense > for me to hold the keys, because I have a functional need to do so. > If at some time in the future, there is a new release manager, I will > turn over the key to them without complaint. I think that the release management role should dispose, non exclusively, of the GPG sign key. The keywords here are "non exclusively". > I think the majority of members consider James to be a trustworthy > person, as I hope they also do myself. > While James has not requested to become "a member of the > organization", he is still a maintainer in good standing. > Not being a member, merely means he does not get a "vote" in things. I > do not see how that makes him any less trustworthy, however. It's not a question of trust but of the paradox of your opinion: a non member can have the key but the members of the board doesn't. > As such, I hope that the current level of redundancy for our signing > keys will be deemed as adequate for our members. There is at least one member who deems that inadequate: me. The vote will decide if I'm alone in which case I will comply. On the contrary, will you? -- Peter From james at opencsw.org Thu Feb 10 12:53:03 2011 From: james at opencsw.org (James Lee) Date: Thu, 10 Feb 2011 11:53:03 GMT Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: <1297308294-sup-7358@pinkfloyd.chass.utoronto.ca> References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> <1297308294-sup-7358@pinkfloyd.chass.utoronto.ca> Message-ID: <20110210.11530300.1164248968@gyor.oxdrove.co.uk> On 10/02/11, 03:57:46, Ben Walton wrote regarding Re: [csw-maintainers] [policy] GPG Signing Key handling: > > the release manager, and the backup release manager. So it is > > already redundantly held. > Nothing slight against James, but as he's not a member, his holding > the key does not count as redundancy for the purpose of this > discussion. If I were a member I could leave so the point is invalid. I have held the key since before OpenCSW existed so the point is doubly invalid. This is because of the practical problem of how people relinquish knowledge at cessation of a role. An escrow was required and for now I have provided that service. Of course trust is used and a risk exists but assess what the risk is and how alternative plans reduce or remove risk and reliance on trust. James. From maciej at opencsw.org Thu Feb 10 15:43:56 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 10 Feb 2011 14:43:56 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/9 Philip Brown : > 2011/2/8 Maciej Blizi?ski : >> >> The text doesn't use the "a library or a symlink to it" expression >> each time, because if we started to do this in every case where >> symlinks could be used, the policy would be rather unreadable. >> > > > > > Perhaps we need to take a very different wording style, rather than > attempting to just make small changes. > Something like, > "The library needs to have a presence in /opt/csw/lib" > or "the library needs to be linkable with -L/opt/csw/lib." This kind of wording sounds good to me. In the specific case of -L, I think it should be rather "Findable at runtime when RPATH is set to /opt/csw/lib or /opt/csw/lib/$ISALIST". The reason is that there's a counterexample: the way we link against libnet, is -L/opt/csw/lib/libnet-new. The libnet.so.1 file is located in /opt/csw/lib (it's a symlink to libnet.so.1.6.0, but it's an implementation detail). The same approach can be used with berkeleydb. The wording "The library needs to have a presence in /opt/csw/lib" sounds the best to me. > Although personally, i think if we just settle the issue of symlinks > now vs later, then the writing will be simpler. I have suggested writing a separate proposal for the issue of symlinks. Symlinks are a powerful tool, and practically any file can be replaced with a symlink to another file located somewhere else. If we want to regulate how symlinks are used, we should have at least a rough policy when the use of symlinks is appropriate. From phil at bolthole.com Thu Feb 10 18:41:23 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Feb 2011 09:41:23 -0800 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: <1297302509-sup-3653@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/9 Maciej Blizi?ski : > > I agree. ?However, an inspected and left reference to /usr/local will > raise a question from the release manager. ?Perhaps we should have > some sort of standardized way of communicating that the package > maintainer knows about the reference and considers it valid. we already have one. the cswmaintainers file. From phil at bolthole.com Thu Feb 10 18:43:28 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Feb 2011 09:43:28 -0800 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: <1297302509-sup-3653@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Feb 10, 2011 at 9:41 AM, Philip Brown wrote: > 2011/2/9 Maciej Blizi?ski : >> >> I agree. ?However, an inspected and left reference to /usr/local will >> raise a question from the release manager. ?Perhaps we should have >> some sort of standardized way of communicating that the package >> maintainer knows about the reference and considers it valid. > > we already have one. ?the cswmaintainers file. > oops, sorry, i meant cswreleasemgr. as per http://www.opencsw.org/extend-it/contribute-packages/build-standards/ From phil at bolthole.com Thu Feb 10 18:48:41 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Feb 2011 09:48:41 -0800 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: <20110210005627.GA21610@sebastiankayser.de> Message-ID: On Thu, Feb 10, 2011 at 12:28 AM, Peter FELECAN wrote: > Sebastian Kayser writes: > >> * Philip Brown wrote: >>> >>> I'm also not sure what is the huge need for "an abstract". or even if >>> there is, why this is so difficult to do ourselves quickly and easily. >>> Going by >>> http://www.debian.org/doc/debian-policy/ >>> their "abstract" consists of two lines, which basically say, "This is >>> the policy manual. Stuff in debian, needs to follow debian policy.". >> >> If you guys start to discuss whether the _abstract_ (i.e. not even >> actual policies) needs to be 2 or 5 lines long I feel that the policy >> team isn't off to a good start. > > I agree with you. This is exactly what I'm afraid when such noise is > raised about 10 lines of text. Sterile divagation about license, > copying, patrimony, &c. This is clearly a policy of obstruction. It's not "clearly" anything of the sort. I'm only proposing that we keep things as simple as possible. And to do things ourselves, rather than feel the need to copy others. Nowhere do I say "lets not have policy docs". Rather, I'm saying lets just avoid putting stuff in them that isnt neccessary. Are you saying you'd prefer the other way, and go for "parlimentary proceedure" or whatever, in all voting and writeups? From phil at bolthole.com Thu Feb 10 19:03:36 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Feb 2011 10:03:36 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/9 Maciej Blizi?ski : > 2011/2/10 Philip Brown : >> This subdiscussion, is only relating to things that MUST have their own prefix. >... >> Certainly, if there are clean ways to compile it and install something >> with prefix=/opt/csw we should do so. But we are talking about the >> things that cannot. >> For example, the multiple versions of berkeleydb. That we have to have >> installed at the same time, and use as neccessary. It's not a matter >> of "pick this one, to be the 'real/active' one" > > Are there two incompatible libdb-X.Y.so files with the same SONAME? > If the answer is no, then BerkeleyDB can be compiled with > --prefix=/opt/csw. sigh. Certainly the thing "can be compiled" that way. The problem is that we need the FULL environment, to actually use it to compile things that need it. Some "newer" progams, need "older" versions, not just "the latest version" of berkeleydb. We need the binary utils, and include files, etc. for that version all present. We need multiple versions installed, at the same time. They CANNOT co-exist in the same namespace, there are conflicts for almost every filename. Therefore, they must be delivered in their own subprefix. That being the case, either the maintainer has to do all kinds of fancy post-build scripting to install the stuff expecting to be installed directly under /opt/csw.... Or they can just do the straightforward thing and compile with --prefix=/opt/csw/berkeleydb-X I would submit to the readers, that the latter is far saner. >> What I've written before in this very thread thread, but I guess I >> have to repeat now, is that having the library detectable in >> $PREFIX/lib is important, not so much for the program itself, but for >> *other* programs that need to link with it. > > By $PREFIX, do you mean our prefix, or a different one? csw/subprefix. > >> Unfortunately, some software has really dumb configuration. it only allows for >> --with-somelib=/install/prefix/here >> NOT >> ?--with-somelib-lib=/path1 --with-somelib-inc=path2 --with-somelib-utils=path3 >> >> Not having the shared lib visible in its expected place of >> $PREFIX/lib, would require some other programs to be heavily patched >> to compile it properly. >> So, it needs some kind of presence in *both* /opt/csw/lib and >> /opt/csw/PREFIX/lib > > I highly doubt this is the case. Maciej, I'm not just talking hypothetically, I've SEEN this happen. to my great irritation. with multiple pieces of software. Are you going to take my word for it, or are you going to call me a liar by insisting I provide "proof"? "I've never seen it" != "it doesnt exist". > While I agree with the general statement that if larger criteria are > equal, considering smaller criteria is useful, I believe that the > smaller criteria should be within the scope of our goals as the > project. ?The output of "du -k" is not within OpenCSW's goals. you have no right to make that statement. Plus it is provably false anyway. If something is a common user behaviour in Solaris, then it is "within opencsw's goals" to support it, since our documented goals are to provide "a straightforward, easy-to-use experience for the user" > If you > would like to include the output of "du -k" in our policies, the > proper way to do this is sending out a proposal. This is ludicrous. you are setting up absurd hurdles specifically targetted to justify you ignoring this issue, with no other benefit. To treat it equally and fairly, would mean we would have to generate an "officially approved list of user commands, with all 'approved' command line switches". And then if a user said, "well I use that command, with this other switch", the maintainer could say "well sorry thats not on our approved user command list, goodbye", which would be equally heinous. From maciej at opencsw.org Thu Feb 10 19:03:33 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 10 Feb 2011 18:03:33 +0000 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: <1297302509-sup-3653@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/10 Philip Brown : > On Thu, Feb 10, 2011 at 9:41 AM, Philip Brown wrote: >> 2011/2/9 Maciej Blizi?ski : >>> >>> I agree. ?However, an inspected and left reference to /usr/local will >>> raise a question from the release manager. ?Perhaps we should have >>> some sort of standardized way of communicating that the package >>> maintainer knows about the reference and considers it valid. >> >> we already have one. ?the cswmaintainers file. >> > > oops, sorry, i meant cswreleasemgr. > as per > http://www.opencsw.org/extend-it/contribute-packages/build-standards/ Dago, what do you think about including the content of the checkpkg_override file in cswreleasemgr? From phil at bolthole.com Thu Feb 10 19:06:16 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Feb 2011 10:06:16 -0800 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Feb 10, 2011 at 2:25 AM, Peter FELECAN wrote: > Philip Brown writes: > >> As such, I hope that the current level of redundancy for our signing >> keys will be deemed as adequate for our members. > > There is at least one member who deems that inadequate: me. The vote will > decide if I'm alone in which case I will comply. On the contrary, will > you? > I believe I have already stated that I will. From phil at bolthole.com Thu Feb 10 19:18:48 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Feb 2011 10:18:48 -0800 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: <1297302509-sup-3653@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/10 Maciej Blizi?ski : > >> oops, sorry, i meant cswreleasemgr. >> as per >> http://www.opencsw.org/extend-it/contribute-packages/build-standards/ > > Dago, what do you think about including the content of the > checkpkg_override file in cswreleasemgr? > I would prefer cswreleasemgr, to have *human targetted* syntax, not auto-generated stuff. Last I saw, the checkpkg_override file was not particularly human-readable. Or at least, not very _informative_. "ignore this file". Umm, okay but why? What I would prefer to see: cswreleasemgr: opt/csw/foo/bar: ignore /usr/local refs, they are just examples opt/csw/foo/baz: /usr/share refs are in addition to /opt/csw/share refs, so allow From dam at opencsw.org Thu Feb 10 19:26:57 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 10 Feb 2011 19:26:57 +0100 Subject: [csw-maintainers] /usr/{local,share} references In-Reply-To: References: <1297302509-sup-3653@pinkfloyd.chass.utoronto.ca> Message-ID: <8296DB9C-7C69-4A82-B590-7D5DF8B0AD0E@opencsw.org> Hi Maciej, Am 10.02.2011 um 19:03 schrieb Maciej Blizi?ski: > 2011/2/10 Philip Brown : >> On Thu, Feb 10, 2011 at 9:41 AM, Philip Brown wrote: >>> 2011/2/9 Maciej Blizi?ski : >>>> >>>> I agree. However, an inspected and left reference to /usr/local will >>>> raise a question from the release manager. Perhaps we should have >>>> some sort of standardized way of communicating that the package >>>> maintainer knows about the reference and considers it valid. >>> >>> we already have one. the cswmaintainers file. >>> >> >> oops, sorry, i meant cswreleasemgr. >> as per >> http://www.opencsw.org/extend-it/contribute-packages/build-standards/ > > Dago, what do you think about including the content of the > checkpkg_override file in cswreleasemgr? Nothing, because the information is already there. But the check could make cswreleasemgr mandatory if checpkg_override is present. Best regards -- Dago From bwalton at opencsw.org Fri Feb 11 02:55:40 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 10 Feb 2011 20:55:40 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> Message-ID: <1297388989-sup-1754@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Feb 10 13:03:36 -0500 2011: Hi Phil, > > If you would like to include the output of "du -k" in our > > policies, the proper way to do this is sending out a proposal. > > This is ludicrous. you are setting up absurd hurdles specifically > targetted to justify you ignoring this issue, with no other benefit. I'm sorry, but until every package is built by default with --prefix=/opt/csw/mypackage[1], thus making 'du -k' a csw-wide feature, it's nothing more than an artifact. You really don't want to consider artifacts when setting policy do you? Please note that I'm not saying you don't presently find it a useful thing to do, I'm simply pointing out that when setting a policy, it's not a good selection criteria. If mysql or berkelydb or any of the other special packages were moved to --prefix=/opt/csw in full at the next update, it would immediately invalidate your current use of 'du -k' and that is a perfectly viable thing for a maintainer to do. Moving on... Thanks -Ben [1] I've forgotten the name, but there is a Linux distro out there that does just this. Every package is placed in its own prefix and symlinks from the central location are provided. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Feb 11 03:08:05 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Feb 2011 18:08:05 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: <1297388989-sup-1754@pinkfloyd.chass.utoronto.ca> References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297388989-sup-1754@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Feb 10, 2011 at 5:55 PM, Ben Walton wrote: >.. > If mysql or berkelydb or any of the other special packages were moved > to --prefix=/opt/csw in full at the next update, it would immediately > invalidate your current use of 'du -k' and that is a perfectly viable > thing for a maintainer to do. I completely agree with that. I am perfectly fine with that. My only point is that, when a package *IS* split off into its own subprefix, it should at least be consistent about actually Being In The Sub-Prefix. Any deliberation about "*Should* package X have its own subprefix?" is completely free from any entanglement with "du", in my book. From bwalton at opencsw.org Fri Feb 11 03:19:31 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 10 Feb 2011 21:19:31 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297388989-sup-1754@pinkfloyd.chass.utoronto.ca> Message-ID: <1297390494-sup-8357@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Feb 10 21:08:05 -0500 2011: Hi Phil, > My only point is that, when a package *IS* split off into its own > subprefix, it should at least be consistent about actually Being In > The Sub-Prefix. Ok, fair enough. I hereby suggest that instead of spending another entire week on this nit, that we simply push forward with language that does not define the direction of the symlink. The language used should allow the maintainer at his/her discretion to symlink in either direction without running astray of the policy. The enforcement piece should centre only on making -L/opt/csw/lib work in a manner consistent with packages built with --prefix=/opt/csw. Good? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri Feb 11 12:30:01 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 11 Feb 2011 11:30:01 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/10 Philip Brown : > 2011/2/9 Maciej Blizi?ski : >> 2011/2/10 Philip Brown : >>> This subdiscussion, is only relating to things that MUST have their own prefix. >>... >>> Certainly, if there are clean ways to compile it and install something >>> with prefix=/opt/csw we should do so. But we are talking about the >>> things that cannot. >>> For example, the multiple versions of berkeleydb. That we have to have >>> installed at the same time, and use as neccessary. It's not a matter >>> of "pick this one, to be the 'real/active' one" >> >> Are there two incompatible libdb-X.Y.so files with the same SONAME? >> If the answer is no, then BerkeleyDB can be compiled with >> --prefix=/opt/csw. > > sigh. > > Certainly the thing "can be compiled" that way. The problem is that we > need the FULL environment, to actually use it to compile things that > need it. Can you provide a specific example? One piece of software that needs an old version of berkeleydb, is postfix. I've read its build recipe[1], which requires two elements: 1. Include files 2. The .so file (with its target) It does not require anything else. No other parts of berkeleydb-4.2 are necessary. It's just one example though, so I'd be interested if there is a piece of software which requires more than the two elements listed above. > Some "newer" progams, need "older" versions, not just "the > latest version" of berkeleydb. > ?We need the binary utils, and include files, etc. for that version all present. > We need multiple versions installed, at the same time. > They CANNOT co-exist in the same namespace, there are conflicts for > almost every filename. Yes, there are filename conflicts. > Therefore, they must be delivered in their own subprefix. This is a non-sequitur. If file conflicts are present, there are two things to be done: 1. Find out whether older files are actually useful 2. If they are, either put them in a separate directory, or modify file names to remove conflicts Delivering in a custom prefix is a way of accomplishing point 2, but it's not the only way. > That being the case, either the maintainer has to do all kinds of > fancy post-build scripting to install the stuff expecting to be > installed directly under /opt/csw.... > Or they can just do the straightforward thing and compile with > ?--prefix=/opt/csw/berkeleydb-X > > I would submit to the readers, that the latter is far saner. There are two sides to it: building the library (say, berkeleydb) and building software that links to it. It may be easier to build berkeleydb itself with a custom prefix, but it makes it harder later on, for other maintainers to build software linking against it. >>> Unfortunately, some software has really dumb configuration. it only allows for >>> --with-somelib=/install/prefix/here >>> NOT >>> ?--with-somelib-lib=/path1 --with-somelib-inc=path2 --with-somelib-utils=path3 >>> >>> Not having the shared lib visible in its expected place of >>> $PREFIX/lib, would require some other programs to be heavily patched >>> to compile it properly. >>> So, it needs some kind of presence in *both* /opt/csw/lib and >>> /opt/csw/PREFIX/lib >> >> I highly doubt this is the case. > > Maciej, I'm not just talking hypothetically, I've SEEN this happen. to > my great irritation. with multiple pieces of software. > Are you going to take my word for it, or are you going to call me a > liar by insisting I provide "proof"? It is not possible for me to answer a question framed that way. I would like to discuss ideas, not people. > "I've never seen it" != "it doesnt exist". Agreed. The second part of the reasoning is: if it exists, it is possible to come up with an example. I believe it makes sense to examine evidence before forming an opinion. It would help to provide a scenario in which there's a need to provide a library outside of /opt/csw/lib even though it is already available in /opt/csw/lib. >> While I agree with the general statement that if larger criteria are >> equal, considering smaller criteria is useful, I believe that the >> smaller criteria should be within the scope of our goals as the >> project. ?The output of "du -k" is not within OpenCSW's goals. > > you have no right to make that statement. Plus it is provably false anyway. > If something is a common user behaviour in Solaris, then it is "within > opencsw's goals" to support it, since our documented goals are to > provide "a straightforward, easy-to-use experience for the user" > >> If you >> would like to include the output of "du -k" in our policies, the >> proper way to do this is sending out a proposal. > > This is ludicrous. you are setting up absurd hurdles specifically > targetted to justify you ignoring this issue, with no other benefit. > > To treat it equally and fairly, would mean we would have to generate > an "officially approved list of user commands, with all 'approved' > command line switches". > ?And then if a user said, "well I use that command, with this other > switch", the maintainer could say "well sorry thats not on our > approved user command list, goodbye", which would be equally heinous. The argument above sets up and attacks a straw-man. I'm not suggesting anything about a list of approved command line switches. I'm suggesting that if the distribution of disk usage across directories under /opt/csw is a factor to be taken into account in our policy, it needs to be discussed and agreed on separately, before it can be used in policy making. Maciej [1] http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/postfix/trunk/Makefile?view=markup Lines 181-185 [2] http://lists.opencsw.org/pipermail/maintainers/2011-February/014094.html From maciej at opencsw.org Fri Feb 11 12:59:05 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 11 Feb 2011 11:59:05 +0000 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: <20110210005627.GA21610@sebastiankayser.de> Message-ID: 2011/2/10 Philip Brown : > On Thu, Feb 10, 2011 at 12:28 AM, Peter FELECAN wrote: >> Sebastian Kayser writes: >> >>> * Philip Brown wrote: >>>> >>>> I'm also not sure what is the huge need for "an abstract". or even if >>>> there is, why this is so difficult to do ourselves quickly and easily. >>>> Going by >>>> http://www.debian.org/doc/debian-policy/ >>>> their "abstract" consists of two lines, which basically say, "This is >>>> the policy manual. Stuff in debian, needs to follow debian policy.". >>> >>> If you guys start to discuss whether the _abstract_ (i.e. not even >>> actual policies) needs to be 2 or 5 lines long I feel that the policy >>> team isn't off to a good start. >> >> I agree with you. This is exactly what I'm afraid when such noise is >> raised about 10 lines of text. Sterile divagation about license, >> copying, patrimony, &c. This is clearly a policy of obstruction. > > > It's not "clearly" anything of the sort. I'm only ?proposing that we > keep things as simple as possible. Simple, in what sense? It doesn't seem to be simple to make progress in our policy work. Look at the timeline: 2011-02-06 12:27 Maciej sends the first revision of the patch sent out [1] 2011-02-06 12:54 Peter F sends a review with a suggestion [2] 2011-02-06 13:23 Maciej sends the second revision [3] 2011-02-09 00:12 Maciej asks for feedback [4] 2011-02-09 05:48 Phil sends a disapproving review [5] 2011-02-09 09:25 Peter F confirms his approval [6] It took Peter F and me one hour to prepare a reviewed and revised change. 5 days later, after exchanging many e-mails, the patch has neither Phil's approval nor a concrete, constructive review (see [2] for an example of such review) from him. I would not call it simple. > And to do things ourselves, rather than feel the need to copy others. > Nowhere do I say "lets not have policy docs". Rather, I'm saying lets > just avoid putting stuff in them that isnt neccessary. The license is necessary, isn't it? We could remove the abstract, if it makes things easier. Maciej [1] http://lists.opencsw.org/pipermail/maintainers/2011-February/013964.html [2] http://lists.opencsw.org/pipermail/maintainers/2011-February/013968.html [3] http://lists.opencsw.org/pipermail/maintainers/2011-February/013970.html [4] http://lists.opencsw.org/pipermail/maintainers/2011-February/014043.html [5] http://lists.opencsw.org/pipermail/maintainers/2011-February/014046.html [6] http://lists.opencsw.org/pipermail/maintainers/2011-February/014049.html From bwalton at opencsw.org Fri Feb 11 14:01:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 11 Feb 2011 08:01:20 -0500 Subject: [csw-maintainers] bug in gar In-Reply-To: References: <1297387850-sup-984@pinkfloyd.chass.utoronto.ca> <1297389436-sup-2655@pinkfloyd.chass.utoronto.ca> <1297392902-sup-2386@pinkfloyd.chass.utoronto.ca> Message-ID: <1297429065-sup-7610@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Feb 10 23:49:57 -0500 2011: > On Thu, Feb 10, 2011 at 6:56 PM, Ben Walton wrote: > > Excerpts from Philip Brown's message of Thu Feb 10 21:42:53 -0500 2011: > >> > >> note that it's pulling in ncurses. The whole point is to build > >> WITHOUT ncurses? > > > > No, the recipe is correct. ?It compiles both but only spits out the > > minimal package. > > That would be what I would call NOT correct. > But, moving on... No, it's completely correct within the way GAR work. > >?What do you have in ~/staging at the end? ?What > > about: Did you get the right package out the bottom end? > > ls -l work/solaris-*/build-global/*prototype > > cat work/solaris-*/build-global/CSWdialog-minimal.prototype > > > > That should all be accurate. > > > > > current9s$ ls work/solaris*/build-global > CSWdialog-minimal.copyright CSWdialog-minimal.prototype-sparc > CSWdialog-minimal.depend CSWdialog.copyright > CSWdialog-minimal.gspec checkpkg_override.CSWdialog > CSWdialog-minimal.pkginfo checkpkg_override.CSWdialog-minimal > CSWdialog-minimal.prototype prototype > > > This is wrong; Really? How so? > current9s$ cat work/solaris*/build-global/CSWdialog-minimal.prototype > f none /opt/csw/bin/dialog.minimal 0755 root bin > d none /opt/csw/share/alternatives 0755 root bin > f cswalternatives /opt/csw/share/alternatives/dialog-minimal 0644 root bin > d none /opt/csw/share/doc/dialog-minimal 0755 root bin > f none /opt/csw/share/doc/dialog-minimal/license 0644 root bin > d none /opt/csw/share/man/man1 0755 root bin > f none /opt/csw/share/man/man1/dialog.1.minimal 0644 root bin > i checkpkg_override=checkpkg_override.CSWdialog-minimal > > as of course the pkginfo is. > At least it's *consistently* wrong. ha-ha. Where exactly is this incorrect? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Feb 11 14:33:31 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 11 Feb 2011 08:33:31 -0500 Subject: [csw-maintainers] Fwd: bug in gar In-Reply-To: <0E7FCAC5-4150-4549-93EB-8D19C81DE313@opencsw.org> References: <9625868E-9FD7-4C5F-A324-662E0E27A71F@opencsw.org> <0E7FCAC5-4150-4549-93EB-8D19C81DE313@opencsw.org> Message-ID: <1297431003-sup-819@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Feb 11 08:21:42 -0500 2011: Hi Dago, > >>> d none /opt/csw/share/doc/dialog-minimal 0755 root bin > >>> f none /opt/csw/share/doc/dialog-minimal/license 0644 root bin > > > > dialog-minimal should be dialog_minimal due to the catalog name. > > There is no > > CATALOGNAME_CSWdialog-minimal = dialog_minimal in the Makefile and > > the defaults seem to be not 100% in all cases. > > > > > > Best regards > > > > -- dago > > It works with the latest GAR, probably Maciej was right that Phil > used an old GAR. Nonetheless I recommend using CATALOGNAME_* > explicitly to avoid any confusion. Yes, I missed this in the output. I've made this explicit in r13253. Phil: Apologies for not seeing that. Please update GAR and the build recipe for dialog and rebuild. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri Feb 11 14:34:23 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 11 Feb 2011 13:34:23 +0000 Subject: [csw-maintainers] bug in gar In-Reply-To: <1297429065-sup-7610@pinkfloyd.chass.utoronto.ca> References: <1297387850-sup-984@pinkfloyd.chass.utoronto.ca> <1297389436-sup-2655@pinkfloyd.chass.utoronto.ca> <1297392902-sup-2386@pinkfloyd.chass.utoronto.ca> <1297429065-sup-7610@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/11 Ben Walton : > Excerpts from Philip Brown's message of Thu Feb 10 23:49:57 -0500 2011: >> current9s$ ls work/solaris*/build-global >> CSWdialog-minimal.copyright ? ? ? ? ?CSWdialog-minimal.prototype-sparc >> CSWdialog-minimal.depend ? ? ? ? ? ? CSWdialog.copyright >> CSWdialog-minimal.gspec ? ? ? ? ? ? ?checkpkg_override.CSWdialog >> CSWdialog-minimal.pkginfo ? ? ? ? ? ?checkpkg_override.CSWdialog-minimal >> CSWdialog-minimal.prototype ? ? ? ? ?prototype >> >> >> This is wrong; I don't see anything wrong in these paths. The pkgname has a dash as intended. >> current9s$ cat work/solaris*/build-global/CSWdialog-minimal.prototype >> f none /opt/csw/bin/dialog.minimal 0755 root bin >> d none /opt/csw/share/alternatives 0755 root bin >> f cswalternatives /opt/csw/share/alternatives/dialog-minimal 0644 root bin I think this is a problematic path. >> d none /opt/csw/share/doc/dialog-minimal 0755 root bin >> f none /opt/csw/share/doc/dialog-minimal/license 0644 root bin Also this. But... it might be an artifact from before gar sources were updated (if they were) from a pre-r13189 version. From phil at bolthole.com Fri Feb 11 15:55:51 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Feb 2011 06:55:51 -0800 Subject: [csw-maintainers] bug in gar In-Reply-To: References: <1297387850-sup-984@pinkfloyd.chass.utoronto.ca> <1297389436-sup-2655@pinkfloyd.chass.utoronto.ca> <1297392902-sup-2386@pinkfloyd.chass.utoronto.ca> <1297429065-sup-7610@pinkfloyd.chass.utoronto.ca> Message-ID: Note: the original email was private, not to the list. but since Maciej sent to the list, I will reply here: 2011/2/11 Maciej Blizi?ski : > 2011/2/11 Ben Walton : >> Excerpts from Philip Brown's message of Thu Feb 10 23:49:57 -0500 2011: .... >>> CSWdialog-minimal.pkginfo ? ? ? ? ? ?checkpkg_override.CSWdialog-minimal >>> CSWdialog-minimal.prototype ? ? ? ? ?prototype >>> >>> >>> This is wrong; > > I don't see anything wrong in these paths. ?The pkgname has a dash as intended. That phrase was referring to what comes afterwards. Because of the ":" at the end of it, output immediately following it. > >>> current9s$ cat work/solaris*/build-global/CSWdialog-minimal.prototype ...> >>> f cswalternatives /opt/csw/share/alternatives/dialog-minimal 0644 root bin > >Also this. ?But... it might be an artifact from before gar sources > were updated (if they were) from a pre-r13189 version. I will try that later today From bonivart at opencsw.org Fri Feb 11 17:16:46 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 11 Feb 2011 17:16:46 +0100 Subject: [csw-maintainers] Fwd: bug in gar In-Reply-To: <1297431003-sup-819@pinkfloyd.chass.utoronto.ca> References: <9625868E-9FD7-4C5F-A324-662E0E27A71F@opencsw.org> <0E7FCAC5-4150-4549-93EB-8D19C81DE313@opencsw.org> <1297431003-sup-819@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Feb 11, 2011 at 2:33 PM, Ben Walton wrote: >> It works with the latest GAR, probably Maciej was right that Phil >> used an old GAR. ?Nonetheless I recommend using CATALOGNAME_* >> explicitly to avoid any confusion. > > Yes, I missed this in the output. ?I've made this explicit in r13253. This probably started with me skipping both PACKAGES and CATALOGNAME since they were exactly the same as the source for my initial version. /peter From phil at bolthole.com Fri Feb 11 17:30:50 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Feb 2011 08:30:50 -0800 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: <20110210005627.GA21610@sebastiankayser.de> Message-ID: 2011/2/11 Maciej Blizi?ski : > 2011/2/10 Philip Brown : > >> >> It's not "clearly" anything of the sort. I'm only ?proposing that we >> keep things as simple as possible. > > Simple, in what sense? The policy. no one said policy *making* was simple (in any context, whether in opencsw, or elsewhere). The goal should be a simple, easy to read and understand _policy_, not ease of creating new policies. In the same way that our overall goals should be to provide a simple easy to use experience for the _user_, not "to make maintainers lives easier". Quality of end product should come first. ease of production, second. > 2011-02-06 12:27 Maciej sends the first revision of the patch sent out [1] > 2011-02-06 12:54 Peter F sends a review with a suggestion [2] > 2011-02-06 13:23 Maciej sends the second revision [3] > 2011-02-09 00:12 Maciej asks for feedback [4] > 2011-02-09 05:48 Phil sends a disapproving review [5] > 2011-02-09 09:25 Peter F confirms his approval [6] > > It took Peter F and me one hour to prepare a reviewed and revised > change. ?5 days later, after exchanging many e-mails, the patch has > neither Phil's approval nor a concrete, constructive review (see [2] > for an example of such review) from him. I thought what I said was fairly concrete, in that I dont think we need an abstract, or a license. And if we DO set down a license, we need to have a vote on it (becuase it will affect ALL of our documentation, for all time. Having you just decide on one, and having a quickie little "verbal" agreement on the mailing list, seems grossly inappropriate for such a scope) And before that, to have a fair vote, first evaluate all the choices and provide a proper comparison to voters... Now that, is the opposite of simple. Nor is this me being "obstructionist" or other garbage: this is me pointing out **the proper way to do things**, in any real life business organization, particularly a supposedly democratically founded one. Ironically, it's "The Secretary" who should be pushing for proper protocol and procedure in this kind of proceeding. > The license is necessary, isn't it? I personally dont think so. >?We could remove the abstract, if > it makes things easier. Sounds good to me. From william at wbonnet.net Fri Feb 11 18:10:06 2011 From: william at wbonnet.net (William Bonnet) Date: Fri, 11 Feb 2011 18:10:06 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: Message-ID: <4D556D6E.30406@wbonnet.net> Hi >> oh yikes. That brings up another issue... I dont recall that everyone >> agreed on a "license" for our docs& policies. > During a previous camp, we have suggested to use CDDL to cover documentation and build description. I think it was in Oslo. cheers W. From phil at bolthole.com Fri Feb 11 18:45:30 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Feb 2011 09:45:30 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/11 Maciej Blizi?ski : > 2011/2/10 Philip Brown : >> 2011/2/9 Maciej Blizi?ski : >>> 2011/2/10 Philip Brown : >> sigh. >> >> Certainly the thing "can be compiled" that way. The problem is that we >> need the FULL environment, to actually use it to compile things that >> need it. > > Can you provide a specific example? ?One piece of software that needs > an old version of berkeleydb, is postfix. ?I've read its build > recipe[1], which requires two elements: > > 1. Include files > 2. The .so file (with its target) > > It does not require anything else. ?No other parts of berkeleydb-4.2 > are necessary. that in itself, should be a sufficient example. However, I have been told by people who know berkeleydb better than I, that you also need the version-specific utilities (binaries) because of differences in the underlying 'database' format between versions. > This is a non-sequitur. ?If file conflicts are present, there are two > things to be done: > > 1. Find out whether older files are actually useful ... All my comments are predicated with [when it is determined that it is *neccessary* to have a subprefix]. I am not saying it is always necessary. I am only saying that *when* it is, that certain things should then be done. So please stop derailing the discussion by going back to [we 'also' need to find out if it is neccessary] >>>> Unfortunately, some software has really dumb configuration. it only allows for >>>> --with-somelib=/install/prefix/here >>>> NOT >>>> ?--with-somelib-lib=/path1 --with-somelib-inc=path2 --with-somelib-utils=path3 >>>> >>>> Not having the shared lib visible in its expected place of >>>> $PREFIX/lib, would require some other programs to be heavily patched >>>> to compile it properly. >>>> So, it needs some kind of presence in *both* /opt/csw/lib and >>>> /opt/csw/PREFIX/lib >>> >>> I highly doubt this is the case. >> >> Maciej, I'm not just talking hypothetically, I've SEEN this happen. to >> my great irritation. with multiple pieces of software. >> Are you going to take my word for it, or are you going to call me a >> liar by insisting I provide "proof"? > > It is not possible for me to answer a question framed that way. meaning, you dont wish to be seen as impolite. But you ARE saying you dont believe me. > would like to discuss ideas, not people. > >> "I've never seen it" != "it doesnt exist". > > Agreed. ?The second part of the reasoning is: if it exists, it is > possible to come up with an example. Lots of things are "possible", without being easy to do. I've compiled hundreds of pieces of software. You're asking me to go through all of them, for the reason that you cant show me professional courtesy and respect, by taking my word for it that I've hit this? >> This is ludicrous. you are setting up absurd hurdles specifically >> targetted to justify you ignoring this issue, with no other benefit. >> >> To treat it equally and fairly, would mean we would have to generate >> an "officially approved list of user commands, with all 'approved' >> command line switches". >> ?And then if a user said, "well I use that command, with this other >> switch", the maintainer could say "well sorry thats not on our >> approved user command list, goodbye", which would be equally heinous. > > The argument above sets up and attacks a straw-man. ?I'm not > suggesting anything about a list of approved command line switches. its close enough. you are at minimum suggesting a list of "approved tools", outside of which, we should ignore other tools. > I'm suggesting that if the distribution of disk usage across > directories under /opt/csw is a factor to be taken into account in our > policy, it needs to be discussed and agreed on separately, before it > can be used in policy making. I think we've wasted enough time in attempting to relegate this to a side issue. Lets just decide it, and move on to your larger proposal. Since this is a smaller issue, I think it makes sense to vote to resolve it, before the larger issue. Particularly since resolution of it, simplifies debate on the larger issue. I formally call for the start of the voting process, on the following issue: "Motion for policy: In cases where it has been determined that it is neccessary for a program to be installed in its own subprefix of /opt/csw, and the program easily supports some equivalent of configure --prefix=/opt/csw/subprefix the program should be compiled as such, and installed as such, with symlinks being made from important places in /opt/csw/(bin,lib) as warranted, into the subprefix. In such cases where the default installation to /opt/csw/subprefix results in some files being placed non-optimally, it may be allowed to move around things slightly(ie: setting up isaexec usage), but best practice is to respect the default installation strategy of the program when using $prefix=/opt/csw/subprefix, as much as possible. The reason for this is to avoid confusing other programs that may require it, and may expect the default installation layout " Since you are the secretary, I think it is technically your responsibility to write up this sort of thing and officially put it to the maintainers list as a separate email? But if you would prefer I do it, please say so, and I will do it. (or are we making Ben the official vote-caller in this board's era?) I would suggest emailing out the above quoted two paragraphs, putting a [vote] in the subject line. From skayser at opencsw.org Fri Feb 11 18:42:30 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 11 Feb 2011 18:42:30 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: <20110210005627.GA21610@sebastiankayser.de> Message-ID: <20110211174230.GC21610@sebastiankayser.de> * Philip Brown wrote: > 2011/2/11 Maciej Blizi??ski : > > 2011/2/10 Philip Brown : > > > >> > >> It's not "clearly" anything of the sort. I'm only ?proposing that we > >> keep things as simple as possible. > > > > Simple, in what sense? > > The policy. > > no one said policy *making* was simple (in any context, whether in > opencsw, or elsewhere). > The goal should be a simple, easy to read and understand _policy_, not > ease of creating new policies. > In the same way that our overall goals should be to provide a simple > easy to use experience for the _user_, not "to make maintainers lives > easier". > Quality of end product should come first. ease of production, second. There's also a time-to-market aspect and one of priorities. One can spend endless time and energy on all aspects while trying to make everything 100%, while totally missing the point. On #solaris the blastwave supporters just mentioned that they have - behind closed doors - prep'd an updated core stack. How well would you rate our level of focus, the time spent here, and progress in light of such a statement - irregardless of its validity? Sebastian From william at wbonnet.net Fri Feb 11 22:04:20 2011 From: william at wbonnet.net (William Bonnet) Date: Fri, 11 Feb 2011 22:04:20 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: <20110211174230.GC21610@sebastiankayser.de> References: <20110210005627.GA21610@sebastiankayser.de> <20110211174230.GC21610@sebastiankayser.de> Message-ID: <4D55A454.4040403@wbonnet.net> Hi > There's also a time-to-market aspect and one of priorities. One can > spend endless time and energy on all aspects while trying to make > everything 100%, while totally missing the point. > > On #solaris the blastwave supporters just mentioned that they have - > behind closed doors - prep'd an updated core stack. > > How well would you rate our level of focus, the time spent here, and > progress in light of such a statement - irregardless of its validity? > Thanks a lot Sebastian for raising this point. You are so right. The points discussed in recent threads are important, but are they important enough to spend so much time and resources debating about things that will reach no end unless a vote is triggered ? We should focus more on our users, being careful not to spend too much on debates that may sounds like theoritical exercise to many people outside of a core team. cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From bwalton at opencsw.org Sat Feb 12 01:32:32 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 11 Feb 2011 19:32:32 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> Message-ID: <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Feb 11 12:45:30 -0500 2011: > "Motion for policy: > In cases where it has been determined that it is neccessary for a > program to be installed in its own subprefix of /opt/csw, and the > program easily supports some equivalent of > configure --prefix=/opt/csw/subprefix > the program should be compiled as such, and installed as such, with > symlinks being made from important places in /opt/csw/(bin,lib) as > warranted, into the subprefix. Nack. You've spent all this time telling Maciej that his language is too explicit because it forces the opposite of your preference and then you come out with the same thing but based on your preference instead? Motion denied. The language specifying location of actual files vs symlinks must be neutral or I'll not support it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sat Feb 12 05:05:06 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Feb 2011 20:05:06 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Feb 11, 2011 at 4:32 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Feb 11 12:45:30 -0500 2011: > >> "Motion for policy: >> ?In cases where it has been determined that it is neccessary for a >> program to be installed in its own subprefix of /opt/csw, and the >> program easily supports some equivalent of >> configure --prefix=/opt/csw/subprefix >> the program should be compiled as such, and installed as such, with >> symlinks being made from important places in /opt/csw/(bin,lib) as >> warranted, into the subprefix. > > Nack. > > You've spent all this time telling Maciej that his language is too > explicit because it forces the opposite of your preference and then > you come out with the same thing but based on your preference instead? > Motion denied. excuse me? For the record, I "spend all this time telling Maciej that his language is too explicit", because he claimed that *his* goal was to write up a "neutral" policy document. But it wasnt neutral. I've spent days now, trying to help Maciej use accurate language in his proposal, to make the wording match his claimed intent. Not something I particularly wanted to do; I wanted to vote on the issue I cared about days ago, but I tried to be patient and help him out with his first. So in essence, I've been spending this time helping him, rather than pushing for the vote to settle the smaller issue that I actually cared about. But I think we've spend enough time attempting to tap-dance around an issue it is claimed we will settle with "a separate vote". ***As another member has just pointed out today****, it seems fruitless to spend more time debating this sub-issue. It's time to vote on the location/symlink issue. And for the record, this is not "the same thing". Maciej's proposal covers basically ALL packages that have ANY shared libraries. My proposal addresses only the very small set of packages requiring subprefixes. Something like 1% of our packages. > The language specifying location of actual files vs symlinks must be > neutral or I'll not support it. Then feel free to vote against it. But dont stand in the way of letting other people vote on it. This is supposed to be a democratic organization. Or are people only allowed to hold votes on issues that you personally approve? From maciej at opencsw.org Sat Feb 12 07:58:36 2011 From: maciej at opencsw.org (Maciej Blizinski) Date: Sat, 12 Feb 2011 07:58:36 +0100 Subject: [csw-maintainers] [PATCH 5/5] checkpkg: Checking if catalogname matches pkgname Message-ID: <1297493916-22493-1-git-send-email-maciej@opencsw.org> From: Maciej Blizi?ski I've recently seen some patches correcting the pkgname vs catalogname correspondence in packages. Here's a patch that makes checkpkg verify that catalognames correspond to pkgnames. Our build standards page[1] currently recommends the naming in which e.g. CSWsoftdoc corresponds to soft_doc. We've recently started to introduce more separators to pkgnames, so perhaps the standards page should be updated. I'm aware of multiple packages in which pkgname does not correspond to catalogname. If we commit this change in, maintainers will see many (overridable, as always) instances of this check triggering an error. On the plus side, the patch will make it harder to make a mistake when creating new packages or reworking the old ones. I've seen two recent code commits in our repository, dealing with exactly this - making pkgname and catalogname match. Would you, maintainers, like this check to be introduced? Maciej [1] http://www.opencsw.org/extend-it/contribute-packages/build-standards/package-creation/ --- gar/v2/lib/python/README | 4 +++- gar/v2/lib/python/package_checks.py | 12 ++++++++++++ gar/v2/lib/python/package_checks_test.py | 20 ++++++++++++++++++++ 3 files changed, 35 insertions(+), 1 deletions(-) diff --git a/gar/v2/lib/python/README b/gar/v2/lib/python/README index a09f074..40c296d 100644 --- a/gar/v2/lib/python/README +++ b/gar/v2/lib/python/README @@ -3,7 +3,6 @@ This directory contains Python libraries, mostly related to checkpkg. ==Checkpkg== Checks to implement: - - foo_bar != CSWfoo-bar -> error - *dev(el)? -> error, suggest *-devel - *-?rt -> error, suggest specific library packages - empty package without 'transitional' in the name --> error, suggest @@ -13,6 +12,9 @@ Checks to implement: ('transitional', 'stub', 'legacy') - Dependency on CSWcas-initsmf + rc* files --> error +Checks implemented: + - foo_bar != CSWfoo-bar -> error + - outside /opt/csw, /etc/opt/csw, /var/opt/csw -> error Development plan for checkpkg: - Notify maintainers when their package is available from mirrors diff --git a/gar/v2/lib/python/package_checks.py b/gar/v2/lib/python/package_checks.py index a65097b..e282544 100644 --- a/gar/v2/lib/python/package_checks.py +++ b/gar/v2/lib/python/package_checks.py @@ -26,6 +26,7 @@ import textwrap import dependency_checks as depchecks import configuration as c import sharedlib_utils as su +import struct_util from Cheetah import Template import common_constants import logging @@ -1223,6 +1224,17 @@ def CheckPrefixDirs(pkg_data, error_mgr, logger, messenger): "file=%s" % pkgmap_entry["path"]) +def CheckCatalognameMatchesPkgname(pkg_data, error_mgr, logger, messenger): + pkgname = pkg_data["basic_stats"]["pkgname"] + catalogname = pkg_data["basic_stats"]["catalogname"] + std_catalogname = struct_util.MakeCatalognameByPkgname(pkgname) + if catalogname != std_catalogname: + error_mgr.ReportError( + 'catalogname-does-not-match-pkgname', + 'pkgname=%s catalogname=%s expected-catalogname=%s' + % (pkgname, catalogname, std_catalogname)) + + def CheckSonameMustNotBeEqualToFileNameIfFilenameEndsWithSo( pkg_data, error_mgr, logger, messenger): pass diff --git a/gar/v2/lib/python/package_checks_test.py b/gar/v2/lib/python/package_checks_test.py index 98e6e70..8e3dcc5 100755 --- a/gar/v2/lib/python/package_checks_test.py +++ b/gar/v2/lib/python/package_checks_test.py @@ -1655,5 +1655,25 @@ class TestCheckPrefixDirs(CheckpkgUnitTestHelper, self.RunCheckpkgTest(self.CheckpkgTest4) +class TestCheckCatalognameMatchesPkgname(CheckpkgUnitTestHelper, + unittest.TestCase): + FUNCTION_NAME = 'CheckCatalognameMatchesPkgname' + + def CheckpkgTest(self): + self.pkg_data = copy.deepcopy(tree_stats[0]) + basic_stats = self.pkg_data["basic_stats"] + basic_stats["catalogname"] = "foo_bar" + basic_stats["pkgname"] = "CSWfoo-bar-baz" + self.error_mgr_mock.ReportError( + 'catalogname-does-not-match-pkgname', + 'pkgname=CSWfoo-bar-baz catalogname=foo_bar ' + 'expected-catalogname=foo_bar_baz') + + def CheckpkgTest2(self): + self.pkg_data = copy.deepcopy(tree_stats[0]) + + def testTwo(self): + self.RunCheckpkgTest(self.CheckpkgTest2) + if __name__ == '__main__': unittest.main() -- 1.7.1 From pfelecan at opencsw.org Sat Feb 12 10:27:02 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 12 Feb 2011 10:27:02 +0100 Subject: [csw-maintainers] [PATCH 5/5] checkpkg: Checking if catalogname matches pkgname In-Reply-To: <1297493916-22493-1-git-send-email-maciej@opencsw.org> (Maciej Blizinski's message of "Sat, 12 Feb 2011 07:58:36 +0100") References: <1297493916-22493-1-git-send-email-maciej@opencsw.org> Message-ID: Maciej Blizinski writes: > Would you, maintainers, like this check to be introduced? As far as I can interpret the patch I'm alright with it. I suggest that each check be accompanied by the citation or reference of the existing policy or the corresponding proposal if it doesn't exist or it's not explicit yet. Also, instead of presenting the patch, make a reference to the release in which the commit was made; those interested by how it is implemented can enjoy the details. -- Peter From pfelecan at opencsw.org Sat Feb 12 11:10:53 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 12 Feb 2011 11:10:53 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: (Philip Brown's message of "Fri, 11 Feb 2011 08:30:50 -0800") References: <20110210005627.GA21610@sebastiankayser.de> Message-ID: Philip Brown writes: > 2011/2/11 Maciej Blizi?ski : >> 2011/2/10 Philip Brown : >> >>> >>> It's not "clearly" anything of the sort. I'm only ?proposing that we >>> keep things as simple as possible. >> >> Simple, in what sense? > > The policy. > > no one said policy *making* was simple (in any context, whether in > opencsw, or elsewhere). > The goal should be a simple, easy to read and understand _policy_, not > ease of creating new policies. > In the same way that our overall goals should be to provide a simple > easy to use experience for the _user_, not "to make maintainers lives > easier". > Quality of end product should come first. ease of production, second. Nobody said the opposite. >> 2011-02-06 12:27 Maciej sends the first revision of the patch sent out [1] >> 2011-02-06 12:54 Peter F sends a review with a suggestion [2] >> 2011-02-06 13:23 Maciej sends the second revision [3] >> 2011-02-09 00:12 Maciej asks for feedback [4] >> 2011-02-09 05:48 Phil sends a disapproving review [5] >> 2011-02-09 09:25 Peter F confirms his approval [6] >> >> It took Peter F and me one hour to prepare a reviewed and revised >> change. ?5 days later, after exchanging many e-mails, the patch has >> neither Phil's approval nor a concrete, constructive review (see [2] >> for an example of such review) from him. > > I thought what I said was fairly concrete, in that I dont think we > need an abstract, or a license. We think that it's necessary. > And if we DO set down a license, we need to have a vote on it (becuase > it will affect ALL of our documentation, for all time. Having you just > decide on one, and having a quickie little "verbal" agreement on the > mailing list, seems grossly inappropriate for such a scope) > And before that, to have a fair vote, first evaluate all the choices > and provide a proper comparison to voters... > Now that, is the opposite of simple. You are endowed to you oppinion which we respect. > Nor is this me being "obstructionist" or other garbage: this is me > pointing out **the proper way to do things**, in any real life > business organization, particularly a supposedly democratically > founded one. I agree with you that obstructionism is garbage. A business is not a democracy. We are not a business but a community. A community should be a democracy. It's quite arrogant to think that there is only one "[...] proper way to do things". > Ironically, it's "The Secretary" who should be pushing for proper > protocol and procedure in this kind of proceeding. The introduction of a policy was presented to the community. We have discussed it. At the amazing speed of 204 characters per day or 43 characters per message in the thread. Indeed, this is an impasse. A vote can be triggered with the following, very simple content of 2 mutually exclusive questions: 1. do you agree with the proposal of policy document introduction (here Maciej give a reference to the wording) 2. No abstract or license are necessary for the policy document (or a different wording of Phil's opinion or the reference toward his vision of the introduction) -- Peter From pfelecan at opencsw.org Sat Feb 12 11:22:31 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 12 Feb 2011 11:22:31 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: (Philip Brown's message of "Fri, 11 Feb 2011 09:45:30 -0800") References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > 2011/2/11 Maciej Blizi?ski : >> 2011/2/10 Philip Brown : >>> 2011/2/9 Maciej Blizi?ski : >>>> 2011/2/10 Philip Brown : >>> sigh. >>> >>> Certainly the thing "can be compiled" that way. The problem is that we >>> need the FULL environment, to actually use it to compile things that >>> need it. >> >> Can you provide a specific example? ?One piece of software that needs >> an old version of berkeleydb, is postfix. ?I've read its build >> recipe[1], which requires two elements: >> >> 1. Include files >> 2. The .so file (with its target) >> >> It does not require anything else. ?No other parts of berkeleydb-4.2 >> are necessary. > > that in itself, should be a sufficient example. > However, I have been told by people who know berkeleydb better than I, > that you also need the version-specific utilities (binaries) because > of differences in the underlying 'database' format between versions. What you describe it's folklore, myths and legends, not a real example. >> This is a non-sequitur. ?If file conflicts are present, there are two >> things to be done: >> >> 1. Find out whether older files are actually useful ... > > All my comments are predicated with [when it is determined that it is > *neccessary* to have a subprefix]. > I am not saying it is always necessary. I am only saying that *when* > it is, that certain things should then be done. > So please stop derailing the discussion by going back to [we 'also' > need to find out if it is neccessary] > > >>>>> Unfortunately, some software has really dumb configuration. it only allows for >>>>> --with-somelib=/install/prefix/here >>>>> NOT >>>>> ?--with-somelib-lib=/path1 --with-somelib-inc=path2 --with-somelib-utils=path3 >>>>> >>>>> Not having the shared lib visible in its expected place of >>>>> $PREFIX/lib, would require some other programs to be heavily patched >>>>> to compile it properly. >>>>> So, it needs some kind of presence in *both* /opt/csw/lib and >>>>> /opt/csw/PREFIX/lib >>>> >>>> I highly doubt this is the case. >>> >>> Maciej, I'm not just talking hypothetically, I've SEEN this happen. to >>> my great irritation. with multiple pieces of software. >>> Are you going to take my word for it, or are you going to call me a >>> liar by insisting I provide "proof"? >> >> It is not possible for me to answer a question framed that way. > > meaning, you dont wish to be seen as impolite. But you ARE saying you > dont believe me. I'm saying that I don't believe you. I will believe you when you give a concrete example and not some folksy reminiscences. > >> would like to discuss ideas, not people. >> >>> "I've never seen it" != "it doesnt exist". >> >> Agreed. ?The second part of the reasoning is: if it exists, it is >> possible to come up with an example. > > Lots of things are "possible", without being easy to do. I've compiled > hundreds of pieces of software. You're asking me to go through all of > them, for the reason that you cant show me professional courtesy and > respect, by taking my word for it that I've hit this? Nobody asks you that. What we ask is a concrete example. Respect and courtesy are not arguments by themselves. >>> This is ludicrous. you are setting up absurd hurdles specifically >>> targetted to justify you ignoring this issue, with no other benefit. >>> >>> To treat it equally and fairly, would mean we would have to generate >>> an "officially approved list of user commands, with all 'approved' >>> command line switches". >>> ?And then if a user said, "well I use that command, with this other >>> switch", the maintainer could say "well sorry thats not on our >>> approved user command list, goodbye", which would be equally heinous. >> >> The argument above sets up and attacks a straw-man. ?I'm not >> suggesting anything about a list of approved command line switches. > > its close enough. you are at minimum suggesting a list of "approved > tools", outside of which, we should ignore other tools. Nobody has suggested something like that. This is a distortion of reality. -- Peter From maciej at opencsw.org Sat Feb 12 12:13:41 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 12 Feb 2011 11:13:41 +0000 Subject: [csw-maintainers] [PATCH 5/5] checkpkg: Checking if catalogname matches pkgname In-Reply-To: References: <1297493916-22493-1-git-send-email-maciej@opencsw.org> Message-ID: 2011/2/12 Peter FELECAN : > Maciej Blizinski writes: > >> Would you, maintainers, like this check to be introduced? > > As far as I can interpret the patch I'm alright with it. > > I suggest that each check be accompanied by the citation or reference of > the existing policy or the corresponding proposal if it doesn't exist or > it's not explicit yet. Good suggestion. > Also, instead of presenting the patch, make a reference to the release > in which the commit was made; those interested by how it is implemented > can enjoy the details. Right, the implementation was in a separate patch, which I haven't sent out yet. I'll do that in a moment. I send patches before committing them, so that we can agree first; this code is not yet in the repository. From maciej at opencsw.org Sat Feb 12 12:16:37 2011 From: maciej at opencsw.org (Maciej Blizinski) Date: Sat, 12 Feb 2011 12:16:37 +0100 Subject: [csw-maintainers] [PATCH 4/5] checkpkg: Adding MakeCatalognameByPkgname In-Reply-To: References: Message-ID: <1297509397-11101-1-git-send-email-maciej@opencsw.org> From: Maciej Blizi?ski This function transforms pkgname to a catalogname. --- gar/v2/lib/python/struct_util.py | 6 ++++++ gar/v2/lib/python/struct_util_test.py | 12 ++++++++++++ 2 files changed, 18 insertions(+), 0 deletions(-) diff --git a/gar/v2/lib/python/struct_util.py b/gar/v2/lib/python/struct_util.py index 389c4f8..cc02828 100644 --- a/gar/v2/lib/python/struct_util.py +++ b/gar/v2/lib/python/struct_util.py @@ -27,3 +27,9 @@ def ResolveSymlink(link_from, link_to): def IsMd5(s): # For optimization, moving the compilation to the top level. return MD5_RE.match(s) + + +def MakeCatalognameByPkgname(pkgname): + catalogname = re.sub(r'^CSW', '', pkgname) + catalogname = re.sub('[^A-Za-z0-9]', '_', catalogname) + return catalogname diff --git a/gar/v2/lib/python/struct_util_test.py b/gar/v2/lib/python/struct_util_test.py index 98d9dbd..6046ed6 100755 --- a/gar/v2/lib/python/struct_util_test.py +++ b/gar/v2/lib/python/struct_util_test.py @@ -47,5 +47,17 @@ class IndexByUnitTest(unittest.TestCase): struct_util.ResolveSymlink("/opt/csw/bin/foo", "/libexec/foo-exec")) +class MakeCatalognameByPkgnameTest(unittest.TestCase): + + def testSimple(self): + self.assertEqual("foo", struct_util.MakeCatalognameByPkgname("CSWfoo")) + + def testWithDash(self): + self.assertEqual("foo_bar", struct_util.MakeCatalognameByPkgname("CSWfoo-bar")) + + def testWithDigits(self): + self.assertEqual("libfoo1_1", struct_util.MakeCatalognameByPkgname("CSWlibfoo1-1")) + + if __name__ == '__main__': unittest.main() -- 1.7.1 From maciej at opencsw.org Sat Feb 12 12:20:04 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 12 Feb 2011 11:20:04 +0000 Subject: [csw-maintainers] [PATCH 4/5] checkpkg: Adding MakeCatalognameByPkgname In-Reply-To: <1297509397-11101-1-git-send-email-maciej@opencsw.org> References: <1297509397-11101-1-git-send-email-maciej@opencsw.org> Message-ID: This if a function referenced in the check I posted a while ago. A side note: looks like --in-reply-to is not enough, it's also necessary to make subjects match. From maciej at opencsw.org Sat Feb 12 12:40:40 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 12 Feb 2011 11:40:40 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> Message-ID: Thanks for all the feedback so far. I've addressed a couple issues (some already mentioned, some not yet) and updated the shared library proposal, making the following changes: - Changed the wording of the public libraries section, defined the availability of a library (or library having a presence) in /opt/csw/lib as open("/opt/csw/lib/"), taking into account that an architecture specific subdirectory may also be used - Added caveats section - Described how to deal with the need to link to an old version of a library - Added a section about SONAME collisions with GCC-compiled C++ libraries - Added a section about *-config scripts and their output - Removed one occurrence of "to move", and emphasized another occurrence where moving is recommended - Modified the implementation section, recommending to combine --libdir with --prefix (if --prefix is used) Updated text: http://wiki.opencsw.org/proposal:shared-library-placement Maciej From phil at bolthole.com Sat Feb 12 19:07:56 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 12 Feb 2011 10:07:56 -0800 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: <20110210005627.GA21610@sebastiankayser.de> Message-ID: On Sat, Feb 12, 2011 at 2:10 AM, Peter FELECAN wrote: > Philip Brown writes: >>> Nor is this me being "obstructionist" or other garbage: this is me >> pointing out **the proper way to do things**, in any real life >> business organization, particularly a supposedly democratically >> founded one. > > I agree with you that obstructionism is garbage. > > A business is not a democracy. We are not a business but a community. A > community should be a democracy. Perhaps 'a business' was not quite the right word. but 'a community' is not adequate either. Maybe you'd like to suggest a better one. The issue here, is that "OpenCSW" is not merely "a community", but a *legal entity*. As such, there is a higher standard to "do things properly". I thought a simple way to describe that was as "a business". From pfelecan at opencsw.org Sat Feb 12 20:05:16 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 12 Feb 2011 20:05:16 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: (Philip Brown's message of "Sat, 12 Feb 2011 10:07:56 -0800") References: <20110210005627.GA21610@sebastiankayser.de> Message-ID: Philip Brown writes: > On Sat, Feb 12, 2011 at 2:10 AM, Peter FELECAN wrote: >> Philip Brown writes: >>>> Nor is this me being "obstructionist" or other garbage: this is me >>> pointing out **the proper way to do things**, in any real life >>> business organization, particularly a supposedly democratically >>> founded one. >> >> I agree with you that obstructionism is garbage. >> >> A business is not a democracy. We are not a business but a community. A >> community should be a democracy. > > > Perhaps 'a business' was not quite the right word. but 'a community' > is not adequate either. > Maybe you'd like to suggest a better one. What I always considered is that we form a community of maintainers. Consequently, I don't have a better description. > The issue here, is that "OpenCSW" is not merely "a community", but a > *legal entity*. What that has to do with how things are decided? > As such, there is a higher standard to "do things properly". > I thought a simple way to describe that was as "a business". Sometimes is good to define a thing by what is not. And we are not engaged in a business. Because business is: 2. Any particular occupation or employment engaged in for livelihood or gain, as agriculture, trade, art, or a profession. "The business of instruction." --Prescott. [1913 Webster] The legal form of OpenCSW is a foundation, i.e. a non-profit association. Of course, that doesn't mean that we don't act professionally. Can you give an example of things that are done improperly, from a professional point of view, in our activities? -- Peter From phil at bolthole.com Sun Feb 13 00:24:35 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 12 Feb 2011 15:24:35 -0800 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: References: <20110210005627.GA21610@sebastiankayser.de> Message-ID: On Sat, Feb 12, 2011 at 11:05 AM, Peter FELECAN wrote: > Philip Brown writes: >... >> As such, there is a higher standard to "do things properly". >> I thought a simple way to describe that was as "a business". >... > The legal form of OpenCSW is a foundation, i.e. a non-profit > association. > > Of course, that doesn't mean that we don't act professionally. > > Can you give an example of things that are done improperly, from a > professional point of view, ?in our activities? > Two such examples (but not the only examples) are; 1. not following good forms for discussion of the voting ballot, before the vote ballot is actually active 2. people griping at me for pointing out "this policy document does not say what you claim you want it to do" Given that we are a legal entity, we then are sadly held to "legal (ie: lawer-proof) standards" of accuracy in our official policies and documents. Me pointing out the documents are inaccurate, and asking that they be made to match the claimed stated intent, is NOT "obstructionist". It's me showing professional levels of diligence. The professional thing for others to do, would be to recognize that. The anti-professional thing is to throw insults and insinuations at me for doing so. I understand that many people dont like dealing with that level of pickiness. That's why there is a separate "debian-policy" mailing list. So probably people who dont like dealing with minutia at opencsw, need to either kill-file emails with "policy" in the subject, or we need to have a separate opencsw policy mailing list (publically readable, of course) for policy discussions. From bwalton at opencsw.org Sun Feb 13 03:23:18 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 12 Feb 2011 21:23:18 -0500 Subject: [csw-maintainers] [PATCH 4/5] checkpkg: Adding MakeCatalognameByPkgname In-Reply-To: <1297509397-11101-1-git-send-email-maciej@opencsw.org> References: <1297509397-11101-1-git-send-email-maciej@opencsw.org> Message-ID: <1297563623-sup-223@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizinski's message of Sat Feb 12 06:16:37 -0500 2011: Hi Maciej, > +def MakeCatalognameByPkgname(pkgname): > + catalogname = re.sub(r'^CSW', '', pkgname) > + catalogname = re.sub('[^A-Za-z0-9]', '_', catalogname) > + return catalogname > diff --git a/gar/v2/lib/python/struct_util_test.py b/gar/v2/lib/python/struct_util_test.py > index 98d9dbd..6046ed6 100755 > --- a/gar/v2/lib/python/struct_util_test.py > +++ b/gar/v2/lib/python/struct_util_test.py > @@ -47,5 +47,17 @@ class IndexByUnitTest(unittest.TestCase): > struct_util.ResolveSymlink("/opt/csw/bin/foo", > "/libexec/foo-exec")) This is good. It doesn't force what the standard catalog name is, it simply ensures that they match and tosses an error otherwise. This makes a good deal of sense to me. Presumably there are other parts of the code that look at things like 'devel' vs 'dev' etc? I like the changes. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Feb 13 03:52:35 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 12 Feb 2011 21:52:35 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> Message-ID: <1297565483-sup-8477@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Feb 11 23:05:06 -0500 2011: Hi Phil, > excuse me? Maybe my wording or tone was too strong. 'Motion denied' was not meant to carry anything other than my personal disapproval of this. If you took it as having more weight than that, please don't. > But I think we've spend enough time attempting to tap-dance around > an issue it is claimed we will settle with "a separate vote". I'm not opposed to a vote, but I think that we should ratify the original policy proposal _with neutral language_ first. If people don't want special-prefix programs to have libraries visible in /opt/csw/lib, then the location/symlink issue is a non-starter anyway. > And for the record, this is not "the same thing". Maciej's proposal > covers basically ALL packages that have ANY shared libraries. My > proposal addresses only the very small set of packages requiring > subprefixes. Something like 1% of our packages. But in essence, they're both _affecting_ the same set of packages. Libraries being visible in /opt/csw/lib is the default for any non-special package. > Then feel free to vote against it. But dont stand in the way of > letting other people vote on it. I'm not standing in the way of anything. I'm voicing my disapproval that this sub-issue, which everyone (unless I missed a mail) is willing to set aside for now, is continuing to hold up the larger piece. > This is supposed to be a democratic organization. Or are people only > allowed to hold votes on issues that you personally approve? Yes, it is and no, my personal approval is not required. I think it makes sense to let people make this choice...just not until after we know if it's worthwhile or not. If the idea of forcing all libraries to be visible from /opt/csw/lib, even if binaries, etc are in /opt/csw/special/ is voted down, then why waste further time on this? In fact, as I've stated previously, although I have a personal preference on the symlink direction (as do you), it really doesn't matter all that much for anything beyond personal preference. I, personally, would be happy to have Maciej's policy ratified, with neutral language and then not even bother with the symlink/location part at all. This would allow you to do it your way (with symlink from /opt/csw/lib mandatory) while others could place actual libraries in /opt/csw/lib and symlinks from the special prefix. No vote required as you're already free to do it whichever way suits your tastes. But...if you feel so strongly that `du -k` in a special prefix is worthwhile, does it not make sense to deal with this _after_ Maciej's proposal since as things stand now, your policy is already in effect minus the optional symlinks you allowed for? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sun Feb 13 12:30:14 2011 From: maciej at opencsw.org (Maciej Blizinski) Date: Sun, 13 Feb 2011 12:30:14 +0100 Subject: [csw-maintainers] [PATCH] checkpkg: Checking if catalogname matches pkgname In-Reply-To: References: Message-ID: <1297596614-24374-1-git-send-email-maciej@opencsw.org> This patch is updated according to Peter Felecan's suggestions - it links to the standards page covering package naming. ----------------------------------------------------------------------- Adding a check that throws an error of catalogname doesn't match the pkgname. It is loosely based on the standards page[1], and more specific. [1] http://www.opencsw.org/extend-it/contribute-packages/build-standards/package-creation/ --- gar/v2/lib/python/README | 4 +++- gar/v2/lib/python/package_checks.py | 18 ++++++++++++++++++ gar/v2/lib/python/package_checks_test.py | 21 +++++++++++++++++++++ 3 files changed, 42 insertions(+), 1 deletions(-) diff --git a/gar/v2/lib/python/README b/gar/v2/lib/python/README index 8a16b45..36849a5 100644 --- a/gar/v2/lib/python/README +++ b/gar/v2/lib/python/README @@ -3,7 +3,6 @@ This directory contains Python libraries, mostly related to checkpkg. ==Checkpkg== Checks to implement: - - foo_bar != CSWfoo-bar -> error - *dev(el)? -> error, suggest *-dev - *-?rt -> error, suggest specific library packages - empty package without 'transitional' in the name --> error, suggest @@ -14,6 +13,9 @@ Checks to implement: - Dependency on CSWcas-initsmf + rc* files --> error - A package must not be incompatible with itself +Checks implemented: + - foo_bar != CSWfoo-bar -> error + - outside /opt/csw, /etc/opt/csw, /var/opt/csw -> error Development plan for checkpkg: - Notify maintainers when their package is available from mirrors diff --git a/gar/v2/lib/python/package_checks.py b/gar/v2/lib/python/package_checks.py index 38f86af..c375814 100644 --- a/gar/v2/lib/python/package_checks.py +++ b/gar/v2/lib/python/package_checks.py @@ -26,6 +26,7 @@ import textwrap import dependency_checks as depchecks import configuration as c import sharedlib_utils as su +import struct_util from Cheetah import Template import common_constants import logging @@ -1223,6 +1224,23 @@ def CheckPrefixDirs(pkg_data, error_mgr, logger, messenger): "file=%s" % pkgmap_entry["path"]) +def CheckCatalognameMatchesPkgname(pkg_data, error_mgr, logger, messenger): + pkgname = pkg_data["basic_stats"]["pkgname"] + catalogname = pkg_data["basic_stats"]["catalogname"] + std_catalogname = struct_util.MakeCatalognameByPkgname(pkgname) + if catalogname != std_catalogname: + msg = ( + "The catalogname should match the pkgname. " + "For more information, see " + "http://www.opencsw.org/extend-it/contribute-packages/" + "build-standards/package-creation/") + messenger.Message(msg) + error_mgr.ReportError( + 'catalogname-does-not-match-pkgname', + 'pkgname=%s catalogname=%s expected-catalogname=%s' + % (pkgname, catalogname, std_catalogname)) + + def CheckSonameMustNotBeEqualToFileNameIfFilenameEndsWithSo( pkg_data, error_mgr, logger, messenger): for binary_info in pkg_data["binaries_dump_info"]: diff --git a/gar/v2/lib/python/package_checks_test.py b/gar/v2/lib/python/package_checks_test.py index 0aa16b2..fac51a1 100755 --- a/gar/v2/lib/python/package_checks_test.py +++ b/gar/v2/lib/python/package_checks_test.py @@ -1678,5 +1678,26 @@ class TestCheckPrefixDirs(CheckpkgUnitTestHelper, self.RunCheckpkgTest(self.CheckpkgTest2) +class TestCheckCatalognameMatchesPkgname(CheckpkgUnitTestHelper, + unittest.TestCase): + FUNCTION_NAME = 'CheckCatalognameMatchesPkgname' + + def CheckpkgTest(self): + self.pkg_data = copy.deepcopy(tree_stats[0]) + basic_stats = self.pkg_data["basic_stats"] + basic_stats["catalogname"] = "foo_bar" + basic_stats["pkgname"] = "CSWfoo-bar-baz" + self.error_mgr_mock.ReportError( + 'catalogname-does-not-match-pkgname', + 'pkgname=CSWfoo-bar-baz catalogname=foo_bar ' + 'expected-catalogname=foo_bar_baz') + + def CheckpkgTest2(self): + self.pkg_data = copy.deepcopy(tree_stats[0]) + + def testTwo(self): + self.RunCheckpkgTest(self.CheckpkgTest2) + + if __name__ == '__main__': unittest.main() -- 1.7.3.2 From maciej at opencsw.org Sun Feb 13 12:41:38 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 13 Feb 2011 11:41:38 +0000 Subject: [csw-maintainers] [PATCH 4/5] checkpkg: Adding MakeCatalognameByPkgname In-Reply-To: <1297563623-sup-223@pinkfloyd.chass.utoronto.ca> References: <1297509397-11101-1-git-send-email-maciej@opencsw.org> <1297563623-sup-223@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/13 Ben Walton : > This is good. ?It doesn't force what the standard catalog name is, it > simply ensures that they match and tosses an error otherwise. ?This > makes a good deal of sense to me. ?Presumably there are other parts of > the code that look at things like 'devel' vs 'dev' etc? The devel vs dev issue has been recently questioned[1] and not resolved. I planned to implement that check when the issue is resolved. The conversation started on pkgsubmissions, when I sent libffi packages for release, working towards resolution of the ctypes module problem in Python. The conversation has stalled. We've established that from the people who care about this issue, 4 are for -dev and 1 is for -devel. However, Phil hasn't acknowledged that fact and still hasn't released the libffi packages. I can't say I'm happy with issues being stalled like this. Maciej [1] http://lists.opencsw.org/pipermail/pkgsubmissions/2011-February/002185.html [2] http://lists.opencsw.org/pipermail/pkgsubmissions/2011-February/002190.html From pfelecan at opencsw.org Sun Feb 13 13:32:43 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 13 Feb 2011 13:32:43 +0100 Subject: [csw-maintainers] [POLICY] Policy-team, policy docs, licenses In-Reply-To: (Philip Brown's message of "Sat, 12 Feb 2011 15:24:35 -0800") References: <20110210005627.GA21610@sebastiankayser.de> Message-ID: Philip Brown writes: > On Sat, Feb 12, 2011 at 11:05 AM, Peter FELECAN wrote: >> Philip Brown writes: >>... >>> As such, there is a higher standard to "do things properly". >>> I thought a simple way to describe that was as "a business". >>... >> The legal form of OpenCSW is a foundation, i.e. a non-profit >> association. >> >> Of course, that doesn't mean that we don't act professionally. >> >> Can you give an example of things that are done improperly, from a >> professional point of view, ?in our activities? >> > > Two such examples (but not the only examples) are; > 1. not following good forms for discussion of the voting ballot, > before the vote ballot is actually active This is not an example but an opinion. An example would be: in the message xxx the following "yyy" is not professional. > 2. people griping at me for pointing out "this policy document does > not say what you claim you want it to do" What you describe is your feelings, i.e., that people are "griping" at you. Have you envisioned that the other people feel the same way with regard to your way of discussing? > Given that we are a legal entity, we then are sadly held to "legal > (ie: lawer-proof) standards" of accuracy in our official policies and > documents. Sorry to say, but this "legal entity" argument is inappropriate. Again, we are not a business, with legal counsel, contracts, customers and everything that a business has. We are an association of volunteers, donating our work to the foundation. That is not to say that we don't have a legal context, it's to say that it's not the same as that for a business. > Me pointing out the documents are inaccurate, and asking that they be > made to match the claimed stated intent, is NOT "obstructionist". > It's me showing professional levels of diligence. Even if it would be true, which I don't think, it is felt as obstruction. Introducing regularly new arguments, e.g., "legal entity", constraints, &c. > The professional thing for others to do, would be to recognize that. If people don't agree with you they are unprofessional? How's that? > The anti-professional thing is to throw insults and insinuations at me > for doing so. Can you show examples of insults that were thrown to you? > I understand that many people dont like dealing with that level of > pickiness. That's why there is a separate "debian-policy" mailing > list. If we volunteered on the policy review is that we want to discuss. What we don't wish is to run in circles. > So probably people who dont like dealing with minutia at opencsw, need > to either kill-file emails with "policy" in the subject, or we need to > have a separate opencsw policy mailing list (publically readable, of > course) for policy discussions. I have asked, from the beginning, to have policy discussions on a separate and private list. If my memory is good you were one of those who were against. -- Peter From bwalton at opencsw.org Sun Feb 13 15:19:34 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 13 Feb 2011 09:19:34 -0500 Subject: [csw-maintainers] updated gettext packages ready for testing Message-ID: <1297606422-sup-2504@pinkfloyd.chass.utoronto.ca> Hi All, After a bit of wrangling to split the libraries up into units, provide a legacy 'rt' package and share the .mo files (as a -data package) between the various packages, I think I have a reasonably useful update ready to go. These packages include Peter Felecan's patches (as denoted by ,p,) to handle the thread bug at runtime on solaris 10. If anyone cares to test them, they're the experimental/ggettext. There are (predictably) a lot of things that depend on the old ggettextrt package, so I wouldn't mind feedback. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sun Feb 13 15:49:38 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 13 Feb 2011 14:49:38 +0000 Subject: [csw-maintainers] updated gettext packages ready for testing In-Reply-To: <1297606422-sup-2504@pinkfloyd.chass.utoronto.ca> References: <1297606422-sup-2504@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/13 Ben Walton : > If anyone cares to test them, they're the experimental/ggettext. Could you provide i386 packages as well? From bwalton at opencsw.org Sun Feb 13 16:01:02 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 13 Feb 2011 10:01:02 -0500 Subject: [csw-maintainers] updated gettext packages ready for testing In-Reply-To: References: <1297606422-sup-2504@pinkfloyd.chass.utoronto.ca> Message-ID: <1297609236-sup-2528@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Sun Feb 13 09:49:38 -0500 2011: > 2011/2/13 Ben Walton : > > If anyone cares to test them, they're the experimental/ggettext. > > Could you provide i386 packages as well? Yes. I thought I had but they're not sitting there. I'll add them shortly. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Feb 13 16:07:23 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 13 Feb 2011 10:07:23 -0500 Subject: [csw-maintainers] updated gettext packages ready for testing In-Reply-To: <1297609236-sup-2528@pinkfloyd.chass.utoronto.ca> References: <1297606422-sup-2504@pinkfloyd.chass.utoronto.ca> <1297609236-sup-2528@pinkfloyd.chass.utoronto.ca> Message-ID: <1297609610-sup-6696@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Feb 13 10:01:02 -0500 2011: > Excerpts from Maciej Blizi?ski's message of Sun Feb 13 09:49:38 -0500 2011: > > 2011/2/13 Ben Walton : > > > If anyone cares to test them, they're the experimental/ggettext. > > > > Could you provide i386 packages as well? > > Yes. I thought I had but they're not sitting there. I'll add them > shortly. They're in place now and will be installable once the catalog building cron job picks them up. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From william at wbonnet.net Sun Feb 13 19:13:57 2011 From: william at wbonnet.net (William Bonnet) Date: Sun, 13 Feb 2011 19:13:57 +0100 Subject: [csw-maintainers] Introducting uWatch 2 Message-ID: <4D581F65.5040801@wbonnet.net> Hi, I have merged the uWatch2 development branch to gar v2 trunk. This first release is fully usable ( which is not a synonym of bug free ;) ). uWatch is a tool designed to help maintainers to detect the availability of new upstream version of the software they are in charge. It can be used either as a command line tool, or as a Makefile target (recommended use). The following targets are available for packages in GAR : gmake get-gar-version This target displays the version used by GAR gmake get-uwatch-configuration This target displays the uWatch configuration gmake get-upstream-latest-version This target displays the latest version from the upstream site gmake get-upstream-version-list This target displays the list of versions available from the upstream site gmake check-upstream This target compares the GAR version to the latest available version from the upstream site gmake upgrade-to-latest-upstream This target creates and upgrade branch ( from the GAR version to the latest available version from the upstream site ) gmake update-package-version-database This target reports information version to the QA database. Unless you are running your own version database, it is not useful for you as maintainer in your everyday life :) Documentation is available from http://wiki.opencsw.org/uwatch Please don't hesitate report problems and ask for more information or documentation improvement. Version 2 is used by the uWatch bot to gather information about versions from GAR and upstream sites. These information are feeding the QA database ( http://www-mockup.opencsw.org/qa ). uWatch is available only for packages in GAR. QA pages will be pushed to the main web site really soon, and data updated daily. Certainly during one of the hacking sessions of the coming Winter Camp. Feedbacks are welcome cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From phil at bolthole.com Sun Feb 13 19:35:52 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 13 Feb 2011 10:35:52 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: <1297565483-sup-8477@pinkfloyd.chass.utoronto.ca> References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297565483-sup-8477@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Feb 12, 2011 at 6:52 PM, Ben Walton wrote: > ... > I'm not standing in the way of anything. ?I'm voicing my disapproval > that this sub-issue, which everyone (unless I missed a mail) is > willing to set aside for now 4, is continuing to hold up the larger > piece. >... >?If the idea of forcing all libraries > to be visible from /opt/csw/lib, even if binaries, etc are in > /opt/csw/special/ is voted down, then why waste further time on this? I was hoping this would actually be a timesaver in the long run. or at least a hassle saver. If we just vote on this, then if it passes, we dont have to argue so much on language for the larger proposal. We can use more direct language for it. Additionally, I actually hope the "visible from /opt/csw/lib" proposal passes. So I'm not interested in "if it doesnt pass we save time". I *want* it to pass :) Also, even if the proposal to make it mandatory does not pass... people may voluntarily do it. I'd like to make sure they do it in the way that I see as the most consistent with other packages, and generally the better way. > But...if you feel so strongly that `du -k` in a special prefix is > worthwhile, does it not make sense to deal with this _after_ Maciej's > proposal since as things stand now, your policy is already in effect > minus the optional symlinks you allowed for? I dont see it that way. The problem is that there is no "policy" on the issue at the moment. Only a "de facto" standard of all packages up until now, that subprefixed binaries stay in their subprefix. Which everyone up until now has seen as sensible, so there was no need to make policy on it previously. So I would like to make the existing behaviour, an official policy standard. From bwalton at opencsw.org Mon Feb 14 00:23:36 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 13 Feb 2011 18:23:36 -0500 Subject: [csw-maintainers] p flag in package file version strings Message-ID: <1297639256-sup-7574@pinkfloyd.chass.utoronto.ca> Hi All, FYI, I committed and documented VERSION_FLAG_PATCH to GAR this morning. Set it to 1 and you'll get things like: foo-1.2.3,p,REV=2011.02.13 instead of just foo-1.2.3,REV=... As discussed, use it for feature patches applied to the upstream source. It's not necessary when your patches are only required to make it build in the first place. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From william at wbonnet.net Mon Feb 14 00:41:13 2011 From: william at wbonnet.net (William Bonnet) Date: Mon, 14 Feb 2011 00:41:13 +0100 Subject: [csw-maintainers] p flag in package file version strings In-Reply-To: <1297639256-sup-7574@pinkfloyd.chass.utoronto.ca> References: <1297639256-sup-7574@pinkfloyd.chass.utoronto.ca> Message-ID: <4D586C19.9080405@wbonnet.net> Hi > FYI, I committed and documented VERSION_FLAG_PATCH to GAR this > morning. Set it to 1 and you'll get things like: > foo-1.2.3,p,REV=2011.02.13 instead of just foo-1.2.3,REV=... Please, would it be possible to wait a few days before pushing to catalog the first packages including this flag ? I would like to check it is not going to break version parsing in statistics tools. Let say until the opening of the Wintercamp. Committing build descriptions in GAR using this flag may also create side effects on QA and uWatch results. I would like to add this flags to unit testing. Since databases are still synchronized manually until next week, there will be no problem, you can commit stuff using this flag. cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From bwalton at opencsw.org Mon Feb 14 02:40:39 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 13 Feb 2011 20:40:39 -0500 Subject: [csw-maintainers] p flag in package file version strings In-Reply-To: <4D586C19.9080405@wbonnet.net> References: <1297639256-sup-7574@pinkfloyd.chass.utoronto.ca> <4D586C19.9080405@wbonnet.net> Message-ID: <1297647505-sup-3210@pinkfloyd.chass.utoronto.ca> Excerpts from William Bonnet's message of Sun Feb 13 18:41:13 -0500 2011: Hi William, > Please, would it be possible to wait a few days before pushing to > catalog the first packages including this flag ? Fine with me. The gettext stuff needs a bit of tire kicking before it goes out the door anyway. > Committing build descriptions in GAR using this flag may also create > side effects on QA and uWatch results. I would like to add this > flags to unit testing. I don't think this will both the QA/uWatch stuff, although I haven't looked at your code. The variable turns on an SPKG_ value that takes this flag into account now and leaves room for others to be easily added in the future. It's not touching the actual VERSION string directly at any point. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Mon Feb 14 20:27:20 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 14 Feb 2011 20:27:20 +0100 Subject: [csw-maintainers] [PATCH 4/5] checkpkg: Adding MakeCatalognameByPkgname In-Reply-To: References: <1297509397-11101-1-git-send-email-maciej@opencsw.org> <1297563623-sup-223@pinkfloyd.chass.utoronto.ca> Message-ID: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Hi, Am 13.02.2011 um 12:41 schrieb Maciej Blizi?ski: > 2011/2/13 Ben Walton : >> This is good. It doesn't force what the standard catalog name is, it >> simply ensures that they match and tosses an error otherwise. This >> makes a good deal of sense to me. Presumably there are other parts of >> the code that look at things like 'devel' vs 'dev' etc? > > The devel vs dev issue has been recently questioned[1] and not > resolved. I planned to implement that check when the issue is > resolved. The conversation started on pkgsubmissions, when I sent > libffi packages for release, working towards resolution of the ctypes > module problem in Python. The conversation has stalled. We've > established that from the people who care about this issue, 4 are for > -dev and 1 is for -devel. However, Phil hasn't acknowledged that fact > and still hasn't released the libffi packages. I can't say I'm happy > with issues being stalled like this. > > Maciej > > [1] http://lists.opencsw.org/pipermail/pkgsubmissions/2011-February/002185.html > [2] http://lists.opencsw.org/pipermail/pkgsubmissions/2011-February/002190.html Is there any new input? If no I suggest getting to a vote. (1) CSW*-dev *_dev (2) CSW*-devel *_devel While the current OpenCSW standard is (2) the solution (2) is short leaving more space for package names, is consistent with other packaging projects and without loss of meaning. Best regards -- Dago From phil at bolthole.com Tue Feb 15 01:57:30 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Feb 2011 16:57:30 -0800 Subject: [csw-maintainers] [PATCH 4/5] checkpkg: Adding MakeCatalognameByPkgname In-Reply-To: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> References: <1297509397-11101-1-git-send-email-maciej@opencsw.org> <1297563623-sup-223@pinkfloyd.chass.utoronto.ca> <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: On Mon, Feb 14, 2011 at 11:27 AM, Dagobert Michelsen wrote: > > > Is there any new input? If no I suggest getting to a vote. > (1) CSW*-dev ? *_dev > (2) CSW*-devel ?*_devel yes, lets please vote on this. I believe I suggested/requested that we have a formal vote on this, back in that thread, many days ago now. Speaking in my role as release manager, I will be happy to abide by whatever the result of the official vote is. I only ask that the ballot be written up fairly, in that the positives and negatives be adequately described for BOTH sides, not just in one direction. From bwalton at opencsw.org Tue Feb 15 02:04:17 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 14 Feb 2011 20:04:17 -0500 Subject: [csw-maintainers] [PATCH 4/5] checkpkg: Adding MakeCatalognameByPkgname In-Reply-To: References: <1297509397-11101-1-git-send-email-maciej@opencsw.org> <1297563623-sup-223@pinkfloyd.chass.utoronto.ca> <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: <1297731831-sup-4835@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Feb 14 19:57:30 -0500 2011: > On Mon, Feb 14, 2011 at 11:27 AM, Dagobert Michelsen wrote: > > > > > > Is there any new input? If no I suggest getting to a vote. > > (1) CSW*-dev ? *_dev > > (2) CSW*-devel ?*_devel > > yes, lets please vote on this. I believe I suggested/requested that we > have a formal vote on this, back in that thread, many days ago now. > Speaking in my role as release manager, I will be happy to abide by > whatever the result of the official vote is. I only ask that the > ballot be written up fairly, in that the positives and negatives be > adequately described for BOTH sides, not just in one direction. Maciej, if you don't mind, would you fire up ballotbin? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Feb 15 02:19:51 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 14 Feb 2011 20:19:51 -0500 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> Message-ID: <1297732758-sup-1871@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Tue Feb 08 20:44:28 -0500 2011: Hi Maciej, Would you please initiate a ballotbin vote for this? I didn't see any requests to alter the wording or any other tweaks, so the text below should be ok. > The GPG signing key is an important asset for OpenCSW. As a member of > OpenCSW, you are asked to make three yes or no selections, one per > board position, to indicate which, if any, of the board positions you > feel should hold a copy of the key. Selecting yes for a position > indicates that you feel this position (and consequently the person > holding this position from year to year) should be responsible for > holding a copy of the key. Selecting no indicates that you do not > want this position to hold the key. > > Question 1: Should the Secretary position hold the key? yes/no > Question 2: Should the Treasurer position hold the key? yes/no > Question 3: Should the President position hold the key? yes/no Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Tue Feb 15 02:36:22 2011 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 15 Feb 2011 02:36:22 +0100 Subject: [csw-maintainers] gar checkpkg error ? Message-ID: when building mercurial, the following error is thrown: INFO:root:Tasting candies one by one... Traceback (most recent call last):############################################################################# | File "gar//bin/checkpkg", line 180, in main() File "gar//bin/checkpkg", line 140, in main exit_code, screen_report, tags_report = check_manager.Run() File "/home/rupert/mgar/gar/v2/lib/python/checkpkg_lib.py", line 781, in Run return super(CheckpkgManager2, self).Run() File "/home/rupert/mgar/gar/v2/lib/python/checkpkg_lib.py", line 230, in Run errors, messages, gar_lines = self.GetAllTags(self.sqo_pkgs_list) File "/home/rupert/mgar/gar/v2/lib/python/checkpkg_lib.py", line 738, in GetAllTags function(pkg_data, check_interface, logger=logger, messenger=messenger) File "/home/rupert/mgar/gar/v2/lib/python/package_checks.py", line 1229, in CheckSonameMustNotBeEqualToFileNameIfFilenameEndsWithSo soname = binary_info["soname"] KeyError: 'soname' gmake: *** [pkgcheck] Error 2 From phil at bolthole.com Tue Feb 15 02:59:38 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Feb 2011 17:59:38 -0800 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: <1297732758-sup-1871@pinkfloyd.chass.utoronto.ca> References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> <1297732758-sup-1871@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Feb 14, 2011 at 5:19 PM, Ben Walton wrote: > Excerpts from Ben Walton's message of Tue Feb 08 20:44:28 -0500 2011: > > Hi Maciej, > > Would you please initiate a ballotbin vote for this? ?I didn't see any > requests to alter the wording or any other tweaks, so the text below > should be ok. Odd... I thought my emails were fairly clear in indicating that the existing wording did not adequately describe the situation So let me be explicit, with 2 wording change requests to it, to reiterate what I have already said in this email, yet has not been acknowleged in the wording :( 1. Please mention that the key is already redundantly held, by two people, not just one. 2. Please mention issues around the fact that once a person has the key, they RETAIN THE KEY, even after their period of office is over, unless we decide to revoke the key's validity globally, and thus force all of our users to get a new key for us. Additional: It also may be helpful to explicitly add a "the existing key holders are adequate" vote option People who read hurriedly, may assume that it is somehow required to vote for at least one of those three. > >> The GPG signing key is an important asset for OpenCSW. ?As a member of >> OpenCSW, you are asked to make three yes or no selections, one per >> board position, to indicate which, if any, of the board positions you >> feel should hold a copy of the key. ?Selecting yes for a position >> indicates that you feel this position (and consequently the person >> holding this position from year to year) should be responsible for >> holding a copy of the key. ?Selecting no indicates that you do not >> want this position to hold the key. >> >> Question 1: Should the Secretary position hold the key? ?yes/no >> Question 2: Should the Treasurer position hold the key? ?yes/no >> Question 3: Should the President position hold the key? ?yes/no From bwalton at opencsw.org Tue Feb 15 03:02:00 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 14 Feb 2011 21:02:00 -0500 Subject: [csw-maintainers] last call for apache2 Message-ID: <1297735261-sup-3984@pinkfloyd.chass.utoronto.ca> Hi All, If anyone has interest in testing the apache2 update that addresses the open bugs, let me know. I'm planning to push it in a few days otherwise. (Maybe Wednesday before heading to the airport?) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Feb 15 03:14:55 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 14 Feb 2011 21:14:55 -0500 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> <1297732758-sup-1871@pinkfloyd.chass.utoronto.ca> Message-ID: <1297735722-sup-5094@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Feb 14 20:59:38 -0500 2011: > Odd... I thought my emails were fairly clear in indicating that the > existing wording did not adequately describe the situation After re-reading your original post, I realize that you were pointing out changes you wished to see. I did not get that impression originally. > 1. Please mention that the key is already redundantly held, by two > people, not just one. > 2. Please mention issues around the fact that once a person has the > key, they RETAIN THE KEY, even after their period of office is over, > unless we decide to revoke the key's validity globally, and thus force > all of our users to get a new key for us. Ok. > It also may be helpful to explicitly add a "the existing key holders > are adequate" vote option > People who read hurriedly, may assume that it is somehow required to > vote for at least one of those three. (Ignoring the fact that this is attempting to dumb down the ballot on the assumption that people won't read it proerly...) I don't think this option will fit properly with the rest of the options. It would potentially let people say: Keep things the way they are (which is not part of the proposal anyway)...oh and also do XYZ. The wording just needs to be clear that it is perfectly acceptable to select 'no' on all three questions. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Feb 15 03:57:00 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 14 Feb 2011 21:57:00 -0500 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> Message-ID: <1297738402-sup-4740@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Tue Feb 08 20:44:28 -0500 2011: Proposed revision: The GPG signing key is an important asset for OpenCSW. It is currently held by the release manager (a member) and backup release manager (a non-member), but by no members of the board. As a member of OpenCSW, you are asked to make three yes or no selections, one per board position, to indicate which, if any, of the board positions you feel should hold a copy of the key. Please consider that once a person holds the key, there is no way to officially revoke it from that member on change of office, short of revoking the key. Selecting yes for a position indicates that you feel this position (and consequently the person holding this position from year to year) should be responsible for holding a copy of the key. Selecting no indicates that you do not want this position to hold the key. Question 1: Should the Secretary position hold the key? yes/no Question 2: Should the Treasurer position hold the key? yes/no Question 3: Should the President position hold the key? yes/no Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Feb 15 04:10:49 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 14 Feb 2011 22:10:49 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297565483-sup-8477@pinkfloyd.chass.utoronto.ca > Message-ID: <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sun Feb 13 13:35:52 -0500 2011: > I was hoping this would actually be a timesaver in the long run. or > at least a hassle saver. If we just vote on this, then if it passes, > we dont have to argue so much on language for the larger > proposal. We can use more direct language for it. We don't need to hassle on the language of the current proposal if we make it's language neutral either. Your proposal is not necessary currently since it's a defacto standard. It only becomes useful after we have the requirement to provide library visibility in both locations. (Nobody is rushing to move libraries around currently, although nothing prevents it either.) > Additionally, I actually hope the "visible from /opt/csw/lib" > proposal passes. So I'm not interested in "if it doesnt pass we > save time". I *want* it to pass :) Well, let's decide this issue then. Before going to a vote, is anyone against the proposal[1] as currently written? If there are no dissenters, we can simply make it policy and carry on with this matter. > Also, even if the proposal to make it mandatory does not pass... > people may voluntarily do it. Correct. > I'd like to make sure they do it in the way that I see as the most > consistent with other packages, and generally the better way. Ok, but I still don't see a need to deal with this before settling the other manner. > I dont see it that way. The problem is that there is no "policy" on > the issue at the moment. Only a "de facto" standard of all packages > up until now, that subprefixed binaries stay in their > subprefix. Which everyone up until now has seen as sensible, so > there was no need to make policy on it previously. So I would like > to make the existing behaviour, an official policy standard. Let's not derail the current effort any further until the original proposal is settled one way or the other...I'm happy to return to this after we've completed the first piece. Thanks -Ben [1] http://wiki.opencsw.org/proposal:shared-library-placement -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Feb 15 04:22:44 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Feb 2011 19:22:44 -0800 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: <1297738402-sup-4740@pinkfloyd.chass.utoronto.ca> References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> <1297738402-sup-4740@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Feb 14, 2011 at 6:57 PM, Ben Walton wrote: > Excerpts from Ben Walton's message of Tue Feb 08 20:44:28 -0500 2011: > > Proposed revision: > > The GPG signing key is an important asset for OpenCSW. ?It is > currently held by the release manager (a member) and backup release > manager (a non-member), but by no members of the board. Suggested edit: ... and backup release manager (currently a maintainer, but not a voting "member") ... > > As a member of OpenCSW, you are asked to make three yes or no > selections, one per board position, to indicate which, if any, of the > board positions you feel should hold a copy of the key. ?Please > consider that once a person holds the key, there is no way to > officially revoke it from that member on change of office, short of > revoking the key. proposed additions "Please consider..." should start its own paragraph, to improve visibility. It should also explicitly mention at the end, "this would require all users of opencsw who use gpg validation, to be aware of the change, and download a new key". From maciej at opencsw.org Tue Feb 15 09:25:56 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 15 Feb 2011 08:25:56 +0000 Subject: [csw-maintainers] gar checkpkg error ? In-Reply-To: References: Message-ID: 2011/2/15 rupert THURNER : > when building mercurial, the following error is thrown: > > 738, in GetAllTags > ? ?function(pkg_data, check_interface, logger=logger, messenger=messenger) > ?File "/home/rupert/mgar/gar/v2/lib/python/package_checks.py", line > 1229, in CheckSonameMustNotBeEqualToFileNameIfFilenameEndsWithSo > ? ?soname = binary_info["soname"] > KeyError: 'soname' Thanks for reporting the error. It was a bug in the check, in which it expected every binary to have a soname. Fixed in r13317, unit tests are also added. Maciej [1] http://sourceforge.net/apps/trac/gar/changeset/13317 From dam at opencsw.org Tue Feb 15 09:32:14 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Feb 2011 09:32:14 +0100 Subject: [csw-maintainers] Call for vote: -dev vs. -devel References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: Hi, once again with updated subject :-) Anfang der weitergeleiteten E-Mail: > Am 13.02.2011 um 12:41 schrieb Maciej Blizi?ski: >> 2011/2/13 Ben Walton : >>> This is good. It doesn't force what the standard catalog name is, it >>> simply ensures that they match and tosses an error otherwise. This >>> makes a good deal of sense to me. Presumably there are other parts of >>> the code that look at things like 'devel' vs 'dev' etc? >> >> The devel vs dev issue has been recently questioned[1] and not >> resolved. I planned to implement that check when the issue is >> resolved. The conversation started on pkgsubmissions, when I sent >> libffi packages for release, working towards resolution of the ctypes >> module problem in Python. The conversation has stalled. We've >> established that from the people who care about this issue, 4 are for >> -dev and 1 is for -devel. However, Phil hasn't acknowledged that fact >> and still hasn't released the libffi packages. I can't say I'm happy >> with issues being stalled like this. >> >> Maciej >> >> [1] http://lists.opencsw.org/pipermail/pkgsubmissions/2011-February/002185.html >> [2] http://lists.opencsw.org/pipermail/pkgsubmissions/2011-February/002190.html > > Is there any new input? If no I suggest getting to a vote. > (1) CSW*-dev *_dev > (2) CSW*-devel *_devel > While the current OpenCSW standard is (2) the solution (2) is short leaving > more space for package names, is consistent with other packaging projects > and without loss of meaning. Best regards -- Dago From pfelecan at opencsw.org Tue Feb 15 09:49:56 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 15 Feb 2011 09:49:56 +0100 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: (Philip Brown's message of "Mon, 14 Feb 2011 19:22:44 -0800") References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> <1297738402-sup-4740@pinkfloyd.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Mon, Feb 14, 2011 at 6:57 PM, Ben Walton wrote: >> Excerpts from Ben Walton's message of Tue Feb 08 20:44:28 -0500 2011: >> >> Proposed revision: >> >> The GPG signing key is an important asset for OpenCSW. ?It is >> currently held by the release manager (a member) and backup release >> manager (a non-member), but by no members of the board. > > Suggested edit: > > ... and backup release manager (currently a maintainer, but not a > voting "member") ... This edit is proposed: ... and backup release manager (currently a maintainer, but not a member of the foundation) ... -- Peter From pfelecan at opencsw.org Tue Feb 15 10:27:14 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 15 Feb 2011 10:27:14 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Mon, 14 Feb 2011 22:10:49 -0500") References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Well, let's decide this issue then. Before going to a vote, is anyone > against the proposal[1] as currently written? If there are no > dissenters, we can simply make it policy and carry on with this > matter. I agree with the proposal as currently written. Note that I modified the phrasing of the case of C++ mangling conflict and its conditional resolution if such a conflict is detected (see the edit history of http://wiki.opencsw.org/proposal:shared-library-placement ). -- Peter From phil at bolthole.com Tue Feb 15 16:13:23 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Feb 2011 07:13:23 -0800 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: On Tue, Feb 15, 2011 at 12:32 AM, Dagobert Michelsen wrote: > >> Is there any new input? If no I suggest getting to a vote. >> (1) CSW*-dev ? *_dev >> (2) CSW*-devel ?*_devel >> While the current OpenCSW standard is (2) the solution (2) is short leaving >> more space for package names, is consistent with other packaging projects >> and without loss of meaning. Reminder for the voting write-up: - a 2-char difference is trivial compared to the size of the current namespace. (32 chars?) - If the goal is "(to converge on standard naming for our development packages", then there are only *6* packages that have to be renamed for _dev -> _devel, for us to then be fully standardized in the "software name" department. This can be done in a relatively short amount of time. In contrast, there are 126 _devel packages that would have to be renamed the other way. It's all very well to say, "renaming a package isnt difficult", but someone would have to actually go out and DO 126 (x2) repackagings. and ideally bring the packages up to date, etc, etc. I'm guessing this would take far far longer. If _dev was chosen, this would effectively make our naming *less* consistent, during the transition period, for possibly a year or more. Compared to a week or two, to go the other direction. From dam at opencsw.org Tue Feb 15 16:17:52 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Feb 2011 16:17:52 +0100 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: <972DBD18-CCCB-413D-B915-1F79781ADF6A@opencsw.org> Hi Phil, Am 15.02.2011 um 16:13 schrieb Philip Brown: > On Tue, Feb 15, 2011 at 12:32 AM, Dagobert Michelsen wrote: >> >>> Is there any new input? If no I suggest getting to a vote. >>> (1) CSW*-dev *_dev >>> (2) CSW*-devel *_devel >>> While the current OpenCSW standard is (2) the solution (2) is short leaving >>> more space for package names, is consistent with other packaging projects >>> and without loss of meaning. > > Reminder for the voting write-up: > > - a 2-char difference is trivial compared to the size of the current > namespace. (32 chars?) > > - If the goal is "(to converge on standard naming for our development > packages", then there are only *6* packages that have to be renamed > for > _dev -> _devel, for us to then be fully standardized in the > "software name" department. This can be done in a relatively short > amount of time. > In contrast, there are 126 _devel packages that would have to be > renamed the other way. > > It's all very well to say, "renaming a package isnt difficult", but > someone would have to actually go out and DO 126 (x2) repackagings. > and ideally bring the packages up to date, etc, etc. > I'm guessing this would take far far longer. If _dev was chosen, this > would effectively make our naming *less* consistent, during the > transition period, for possibly a year or more. > Compared to a week or two, to go the other direction. Personally I maintain 45 of these and all packages with devel stuff in it needs to be touched anyway due to the library splitting. Best regards -- Dago From phil at bolthole.com Tue Feb 15 17:48:42 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Feb 2011 08:48:42 -0800 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: <972DBD18-CCCB-413D-B915-1F79781ADF6A@opencsw.org> References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> <972DBD18-CCCB-413D-B915-1F79781ADF6A@opencsw.org> Message-ID: On Tue, Feb 15, 2011 at 7:17 AM, Dagobert Michelsen wrote: > Hi Phil, > > Am 15.02.2011 um 16:13 schrieb Philip Brown: >>... >> In contrast, there are 126 _devel packages that would have to be >> renamed the other way. >>... > > Personally I maintain 45 of these and all packages with devel stuff in it > needs to be touched anyway due to the library splitting. "needs" is sort of overstating things. There is no urgency to it; things work as-is. And are you looking to take on the other 81 as well? :-} FYI, they are spread across 21 other maintainers. From phil at bolthole.com Tue Feb 15 18:05:18 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Feb 2011 09:05:18 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Feb 14, 2011 at 7:10 PM, Ben Walton wrote: > ... > Let's not derail the current effort any further until the original > proposal is settled one way or the other...I'm happy to return to this > after we've completed the first piece. Trouble is, its a lengthy, wordy proposal, which means that discussion may still go on for some time. (not that I particularly WANT it to.. its just that we need to be exact about policy wording!) I'm bringing up things one at a time in it,as I see them, because I think if I spent 2 hours to go over and make one exhaustive list of everything I saw, in one document, it would be impractical to discuss it all at the same time. Remember: I DO actually want this to pass. Its just that the wording has issues in some places. So we have a non-deterministic length of time until those issues are worked out in the longer doc, but the issues for the symlink stuff are pretty well known, and it is easy to kick off a vote for that and be done with it now. AAAnyways, here's some more issues I see with http://wiki.opencsw.org/proposal:shared-library-placement It discusses SONAME. But implies that ALL libraries, ALWAYS have a SONAME. Historically, we have found this is not always the case. So then there's an issue of "should we *force*" all our libraries to have a SONAME"? And what if the upstream that doesnt pay attention to SONAMES, doesnt bump filenames in future versions? This unfortunately has potential to spin off yet another sub-issue vote. Additionally, it mentions "appspecific-config" type scripts, aka "*-config", but does not mention pkg-config files . There is also a concern I have about this item: # Non-ambiguous discrimination between public and private shared libraries but I think I've reached the functional limit for this email, and only mention this here as a placeholder so I wont forget it later. From jcraig at opencsw.org Tue Feb 15 18:34:34 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Tue, 15 Feb 2011 12:34:34 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Feb 14, 2011 at 10:10 PM, Ben Walton wrote: > Well, let's decide this issue then. ?Before going to a vote, is anyone > against the proposal[1] as currently written? ?If there are no > dissenters, we can simply make it policy and carry on with this > matter. > The only section I felt was somewhat harry was the portion that spoke about linking to an older library. This portion pre-supposes a solution to this problem when it hasn't really been discussed (at least in the context of this policy). I think the subject of how to enable access to older libraries for end-user developers merits its own discussion and/or policy. The method described in the document has some serious downfalls and I would prefer a method more like the one used by ubuntu. This places the include.h and the libfoo.so link into a versioned package like libfoo2.0-dev. This allows the end-user to choose the default development version of the library to use with builds by choosing the approriate -dev package. The libfoo-rt package then would only have the libfoo.so.1 file needed by executables. Example: appfoo1 /opt/csw/bin/appfoo (depends on /opt/csw/libfoo.so.1) libfoo1rt /opt/csw/lib/libfoo.so.1 libfoo1-dev /opt/csw/include/foo.h /opt/csw/lib/libfoo.so -> libfoo.so.1 appfoo2 /opt/csw/bin/appfoo (depends on /opt/csw/libfoo.so.2) libfoo2rt /opt/csw/lib/libfoo.so.2 libfoo2-dev /opt/csw/include/foo.h /opt/csw/lib/libfoo.so -> libfoo.so.2 Now libfoo1rt and libfoo2rt can coexist and the end-user can choose which library they want to develop against by choosing the appropriate -dev package. From maciej at opencsw.org Tue Feb 15 20:56:24 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 15 Feb 2011 19:56:24 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/15 Jonathan Craig : > The only section I felt was somewhat harry was the portion that spoke > about linking to an older library. ?This portion pre-supposes a > solution to this problem when it hasn't really been discussed (at > least in the context of this policy). It's a good time to discuss it. > I think the subject of how to > enable access to older libraries for end-user developers merits its > own discussion and/or policy. ?The method described in the document > has some serious downfalls Could you outline them? > and I would prefer a method more like the > one used by ubuntu. ?This places the include.h and the libfoo.so link > into a versioned package like libfoo2.0-dev. ?This allows the end-user > to choose the default development version of the library to use with > builds by choosing the approriate -dev package. ?The libfoo-rt package > then would only have the libfoo.so.1 file needed by executables. > > Example: > appfoo1 > ?/opt/csw/bin/appfoo (depends on /opt/csw/libfoo.so.1) > > libfoo1rt I guess that would be libfoo1 / CSWlibfoo1. > ?/opt/csw/lib/libfoo.so.1 > > libfoo1-dev > ?/opt/csw/include/foo.h > ?/opt/csw/lib/libfoo.so -> libfoo.so.1 > > appfoo2 > ?/opt/csw/bin/appfoo (depends on /opt/csw/libfoo.so.2) > > libfoo2rt > ?/opt/csw/lib/libfoo.so.2 > > libfoo2-dev > ?/opt/csw/include/foo.h > ?/opt/csw/lib/libfoo.so -> libfoo.so.2 > > Now libfoo1rt and libfoo2rt can coexist and the end-user can choose > which library they want to develop against by choosing the appropriate > -dev package. In our case it can't be done by including files directly in packages. If you tried to release the -dev packages like this, your second package would be rejected with a note that it conflicts with the first one. Perhaps an approach using alternatives could be used: place files elsewhere and provide symlinks. There's one issue to be addressed: we are using shared build systems on the buildfarm (e.g. current9s). It needs to be possible to link to libfoo.so.2 as well as libfoo.so.1 on a single system, without any global package manipulation (and root / sudo access). Maciej From jcraig at opencsw.org Tue Feb 15 22:21:07 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Tue, 15 Feb 2011 16:21:07 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/15 Maciej Blizi?ski : > 2011/2/15 Jonathan Craig : >> The only section I felt was somewhat harry was the portion that spoke >> about linking to an older library. ?This portion pre-supposes a >> solution to this problem when it hasn't really been discussed (at >> least in the context of this policy). > > It's a good time to discuss it. > We can certainly discuss it but do we wish to hold up progress on library placement for a sidebar discussion on how to support multiple versions of a given runtime library for developers? One of the goals was to decouple the shared library issue from how to support multiple versions of a given application and then the proposal drives right into this issue. >> I think the subject of how to >> enable access to older libraries for end-user developers merits its >> own discussion and/or policy. ?The method described in the document >> has some serious downfalls > > Could you outline them? The original example of devoid of packaging information. I'm assuming at least two packages exist (libfoo1, libfoo2), but which one owns the /opt/csw/lib/libfoo.so -> libfoo.so.N? The example layout supposes the maintainer do a lot of monkeying about to shuffle libraries around and, pardon my emotional response, feels messy. If the library includes its own private prefix (/opt/csw/{prefix}) then some stuff is shuffled to /opt/csw/lib/{prefix} and other stuff is kept in /opt/csw/{prefix}/lib. It feels confusing and fractured, but thats just my opinion and I'm willing to hear counter arguments. Could you talk through the design choices involved with the layout shown in the proposal example over alternatives? > >> and I would prefer a method more like the >> one used by ubuntu. ?This places the include.h and the libfoo.so link >> into a versioned package like libfoo2.0-dev. ?This allows the end-user >> to choose the default development version of the library to use with >> builds by choosing the approriate -dev package. ?The libfoo-rt package >> then would only have the libfoo.so.1 file needed by executables. >> >> Example: >> appfoo1 >> ?/opt/csw/bin/appfoo (depends on /opt/csw/libfoo.so.1) >> >> libfoo1rt > > I guess that would be libfoo1 / CSWlibfoo1. > >> ?/opt/csw/lib/libfoo.so.1 >> >> libfoo1-dev >> ?/opt/csw/include/foo.h >> ?/opt/csw/lib/libfoo.so -> libfoo.so.1 >> >> appfoo2 >> ?/opt/csw/bin/appfoo (depends on /opt/csw/libfoo.so.2) >> >> libfoo2rt >> ?/opt/csw/lib/libfoo.so.2 >> >> libfoo2-dev >> ?/opt/csw/include/foo.h >> ?/opt/csw/lib/libfoo.so -> libfoo.so.2 >> >> Now libfoo1rt and libfoo2rt can coexist and the end-user can choose >> which library they want to develop against by choosing the appropriate >> -dev package. > > In our case it can't be done by including files directly in packages. > If you tried to release the -dev packages like this, your second > package would be rejected with a note that it conflicts with the first > one. ?Perhaps an approach using alternatives could be used: place > files elsewhere and provide symlinks. Cant be done given the existing implementation or cant be done at all. Should we limit our solutions to the existing code if it precludes the implementation of a more elegant solution? > > There's one issue to be addressed: we are using shared build systems > on the buildfarm (e.g. current9s). ?It needs to be possible to link to > libfoo.so.2 as well as libfoo.so.1 on a single system, without any > global package manipulation (and root / sudo access). Hmm, this is a tough one because its a situation we have as a maintainer community that isn't as much of an issue for an end user. An end user can install/re-install the -dev package as needed. Access to the shared library could be handled by creating a "lib" directory in the package build space that creates the symlink to whatever version of the shared library. This doesn't solve the issue of conflicting include files. For the build farm could we have installation of development packages into private root directories that are added to the using -L/-I options but expect to find their runtime libraries in /opt/csw/lib using -R. > > Maciej > _______________________________________________ > 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 Tue Feb 15 22:38:49 2011 From: william at wbonnet.net (William Bonnet) Date: Tue, 15 Feb 2011 22:38:49 +0100 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> <972DBD18-CCCB-413D-B915-1F79781ADF6A@opencsw.org> Message-ID: <4D5AF269.4080008@wbonnet.net> hi > And are you looking to take on the other 81 as well? :-} > > FYI, they are spread across 21 other maintainers. I have 31 of the remaining. So that's only 50 packages over 20 maintainers. cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From phil at bolthole.com Tue Feb 15 23:19:58 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Feb 2011 14:19:58 -0800 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: <4D5AF269.4080008@wbonnet.net> References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> <972DBD18-CCCB-413D-B915-1F79781ADF6A@opencsw.org> <4D5AF269.4080008@wbonnet.net> Message-ID: On Tue, Feb 15, 2011 at 1:38 PM, William Bonnet wrote: > hi > >> And are you looking to take on the other 81 as well? :-} >> >> FYI, they are spread across 21 other maintainers. > > I have 31 of the remaining. So that's only 50 packages over 20 maintainers. > "only", he says. Getting 20 maintainers to update a package in a timely manner, just because you feel like playing around with naming, is a challenge. (for that matter, it's also somewhat unreasonable) Experience says, to get a transition to _dev completed, either we will be waiting a considerable amount of time for it to finish, or you will have to formalize "hostile takeovers" of packages, as a methodology that can happen at any time, to someone's package, on the whim of some new naming policy coming along. This sort of behaviour that would further demotivate people to take on packages in the first place. From phil at bolthole.com Tue Feb 15 23:43:50 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Feb 2011 14:43:50 -0800 Subject: [csw-maintainers] the problem of imapd Message-ID: Hi folks, we're looking for suggestions/volunteers. Yann has got a pending update to cyrus imap, in newpkgs. Trouble is, we now detect we have name clashes, and inconsistencies, with the other two.. yes two.. imapd packages. There is UW imap, aka CSWimap. maintainer, retired Also, CSWcourierimap. separate maintainer, also retired. The particular issues are twofold. 1. name clash about the manpage. courier and cyrus both provide "imapd.8" 2. inconsistency about naming, and location: /opt/csw/sbin/imapd /opt/csw/libexec/cyrus/imapd /opt/csw/bin/imapd Suggestions? Volunteers to take over and clean up at least one of the non-cyrus packages? >From what I remember, there *are* particular reasons why some people would favor cyrus, but others courier. So we cant just drop one of them, sadly :( We might be able to get away with dropping the actual "imapd" part of the UW one, but the stuff that comes along with it.. the libraries, etc.. are actually critical for some other programs compiling stuff with imap clients, if I recall correctly. From william at wbonnet.net Tue Feb 15 23:47:35 2011 From: william at wbonnet.net (William Bonnet) Date: Tue, 15 Feb 2011 23:47:35 +0100 Subject: [csw-maintainers] p flag in package file version strings In-Reply-To: <1297647505-sup-3210@pinkfloyd.chass.utoronto.ca> References: <1297639256-sup-7574@pinkfloyd.chass.utoronto.ca> <4D586C19.9080405@wbonnet.net> <1297647505-sup-3210@pinkfloyd.chass.utoronto.ca> Message-ID: <4D5B0287.8080706@wbonnet.net> Hi > I don't think this will both the QA/uWatch stuff, although I haven't > looked at your code. When parsing catalog, i retrieve version from the file name by using a regular expression. This reg exp has been updated to take in account potential ,p ,i or ,s flags. This modification was needed to avoid false version detection. I have committed the patch and pushed it to both mockup and production site. Thanks for having put a hold on this for a couple days. You can know use this feature. Phil please you can also release CVS package. The first one have a ",p" flag. cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From bwalton at opencsw.org Wed Feb 16 02:10:02 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 15 Feb 2011 20:10:02 -0500 Subject: [csw-maintainers] p flag in package file version strings In-Reply-To: <4D5B0287.8080706@wbonnet.net> References: <1297639256-sup-7574@pinkfloyd.chass.utoronto.ca> <4D586C19.9080405@wbonnet.net> <1297647505-sup-3210@pinkfloyd.chass.utoronto.ca> <4D5B0287.8080706@wbonnet.net> Message-ID: <1297818572-sup-9951@pinkfloyd.chass.utoronto.ca> Excerpts from William Bonnet's message of Tue Feb 15 17:47:35 -0500 2011: > When parsing catalog, i retrieve version from the file name by using > a regular expression. This reg exp has been updated to take in > account potential ,p ,i or ,s flags. This modification was needed to > avoid false version detection. Ah. Ok. I thought you were extracting the variables from the Makefile. Makes sense. Thanks! -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Wed Feb 16 02:26:32 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 15 Feb 2011 20:26:32 -0500 Subject: [csw-maintainers] Welcome to our newest member! Message-ID: <1297819359-sup-3495@pinkfloyd.chass.utoronto.ca> Hi, The association welcomes the newly accepted members - Jonathan Craig Jonathan already maintains several packages including ntop. Please keep in mind that being a maintainer is not only about fame and glory, but also about tedious work to make sure the packages are good as possible and fixing bugs when discovered. Please check regularly at the bottom of your maintainer page if there are any open issues. If you have spare cycles please adopt an orphaned package and help bring the complete software stack to a 100% current state. Enough business: A warm welcome to you. Your membership is (soon to be) tracked at Please let us know on what are you working or are planning to work like "webpage", "maintainer", etc. If you have applied for membership and don't see your name anywhere above please let me know. [Apologies to Dago for copying his text with only minor modifications! :) ] Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Wed Feb 16 02:31:50 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 15 Feb 2011 20:31:50 -0500 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: <1297738402-sup-4740@pinkfloyd.chass.utoronto.ca> References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> <1297738402-sup-4740@pinkfloyd.chass.utoronto.ca> Message-ID: <1297819720-sup-9648@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Mon Feb 14 21:57:00 -0500 2011: Proposed revision: --snip-- The GPG signing key is an important asset for OpenCSW. It is currently held by the release manager (a member) and backup release manager (a maintainer but not a member of the foundation), but by no members of the board. As a member of OpenCSW, you are asked to make three yes or no selections, one per board position, to indicate which, if any, of the board positions you feel should hold a copy of the key. Please consider that once a person holds the key, there is no way to officially revoke it from that member on change of office, short of revoking the key. Selecting yes for a position indicates that you feel this position (and consequently the person holding this position from year to year) should be responsible for holding a copy of the key. Selecting no indicates that you do not want this position to hold the key. Question 1: Should the Secretary position hold the key? yes/no Question 2: Should the Treasurer position hold the key? yes/no Question 3: Should the President position hold the key? yes/no --snip-- Phil: I believe that our members are intelligent enough to understand what revoking the key implies. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Wed Feb 16 02:43:16 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 15 Feb 2011 20:43:16 -0500 Subject: [csw-maintainers] the problem of imapd In-Reply-To: References: Message-ID: <1297820033-sup-6719@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Feb 15 17:43:50 -0500 2011: > There is UW imap, aka CSWimap. maintainer, retired It hasn't been updated since 2003. Toss it? (See below...) > Also, CSWcourierimap. separate maintainer, also retired. Package hasn't been updated since 2008. I think this likely has wider use that the clunky old UW-imap and it's also newer. > /opt/csw/sbin/imapd > /opt/csw/libexec/cyrus/imapd > /opt/csw/bin/imapd I'd suggest that the binaries and man pages are renamed with a suffix like .uw or .cyrus, etc. We can then use alternatives on the man pages (and the binaries if appropriate). We'd still need a coordinated update on this though. > We might be able to get away with dropping the actual "imapd" part of > the UW one, but the stuff that comes along with it.. the libraries, > etc.. are actually critical for some other programs compiling stuff > with imap clients, if I recall correctly. This used to be the case, but is it still? Does anyone know? I haven't used it in ages now. Maciej: does the checkpkg db store info about consumers of libraries? As you've analyzed the entire catalog set, we could see if something is still linking against it (without declaring a dependency). Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Wed Feb 16 03:13:45 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 15 Feb 2011 21:13:45 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: <1297820917-sup-1458@pinkfloyd.chass.utoronto.ca> Excerpts from Jonathan Craig's message of Tue Feb 15 16:21:07 -0500 2011: Hi Jonathan, > Cant be done given the existing implementation or cant be done at > all. Should we limit our solutions to the existing code if it > precludes the implementation of a more elegant solution? Part of the rationale behind this is that we don't currently allow declaring an I(ncompatible) dependency on a package as a general principle. It's really only used when a package name changes to ensure the old one gets kicked out. Thus, we don't want to have two packages owning the same files if they are allowed to be installed side by side. As such, checkpkg flags it as an error. I don't know the original motivation behind this choice and my personal feeling is the for things like this it actually would make sense to use it...especially now that the catalog carries this information. (If I had to guess, I'd > Hmm, this is a tough one because its a situation we have as a > maintainer community that isn't as much of an issue for an end user. A good point, although users could hit it depending on what they're doing. > whatever version of the shared library. This doesn't solve the > issue of conflicting include files. For the build farm could we > have installation of development packages into private root > directories that are added to the using -L/-I options but expect to > find their runtime libraries in /opt/csw/lib using -R. Alternatives would make a good choice for this if combined with a private directory (eg: /opt/csw/include/bdb4{6,7,8,etc}) for fallback -I use...I think. This could also work for the .so symlinks. We'd end up with something like: include/ db.h.47 db.h.48 db.h -> db.h.48 (managed by alternatives) db47/ db.h -> ../db.h.47 db48/ dh.h -> ../db.h.48 And a similar layout for the lib/ bits. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Wed Feb 16 04:06:14 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Feb 2011 19:06:14 -0800 Subject: [csw-maintainers] the problem of imapd In-Reply-To: <1297820033-sup-6719@pinkfloyd.chass.utoronto.ca> References: <1297820033-sup-6719@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Feb 15, 2011 at 5:43 PM, Ben Walton wrote: ... >> /opt/csw/sbin/imapd >> /opt/csw/libexec/cyrus/imapd >> /opt/csw/bin/imapd > > I'd suggest that the binaries and man pages are renamed with a suffix > like .uw or .cyrus, etc. ?We can then use alternatives on the man > pages (and the binaries if appropriate). ?We'd still need a > coordinated update on this though. I'm not sure that using "alternatives" is even a good idea for these purposes. They are not particularly work-alikes. They just share the same name. I think "alternatives" is best used when there is a very high degree of functional similarity. From phil at bolthole.com Wed Feb 16 04:12:56 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Feb 2011 19:12:56 -0800 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: <1297819720-sup-9648@pinkfloyd.chass.utoronto.ca> References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> <1297738402-sup-4740@pinkfloyd.chass.utoronto.ca> <1297819720-sup-9648@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Feb 15, 2011 at 5:31 PM, Ben Walton wrote: > ... > > Phil: I believe that our members are intelligent enough to understand > ? ? ?what revoking the key implies. People often "know" things, but dont think about the ramifications unless their attention is specifically brought to it. Why are you resisting putting in this one-or-two line change, but accepting all the others? This seems a little unreasonable. Unless you think what I wrote was factually *wrong*, the fair thing seems to be to put it in. Demonstrating "fair writeup to each side", for the vote. From phil at bolthole.com Wed Feb 16 04:22:06 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Feb 2011 19:22:06 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: <1297820917-sup-1458@pinkfloyd.chass.utoronto.ca> References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> <1297820917-sup-1458@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Feb 15, 2011 at 6:13 PM, Ben Walton wrote: >... > > Alternatives would make a good choice for this if combined with a > private directory (eg: /opt/csw/include/bdb4{6,7,8,etc}) for fallback > -I use...I think. ?This could also work for the .so symlinks. > no, that is not a good idea. with berkeleydb, we do NOT want a generic db.h. We actually tried this last year or something, to track along with "latest version". It failed miserably, and we had to back it out, with much pain. For some troublesome software, you have to use a specific version, and know exactly which version you are using, to compile something else. Berkeleydb is the pinnacle of such badly written software, unfortunately. From bwalton at opencsw.org Wed Feb 16 04:38:39 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 15 Feb 2011 22:38:39 -0500 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> <1297738402-sup-4740@pinkfloyd.chass.utoronto.ca> <1297819720-sup-9648@pinkfloyd.chass.utoronto.ca> Message-ID: <1297827146-sup-3401@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Feb 15 22:12:56 -0500 2011: > People often "know" things, but dont think about the ramifications > unless their attention is specifically brought to it. Why are you > resisting putting in this one-or-two line change, but accepting all > the others? This seems a little unreasonable. Well, they've had the opportunity to read it here as well. I hardly think it's unreasonable. I do find other things a bit on the unreasonable side, but those I'll save for other discussions. > Unless you think what I wrote was factually *wrong*, the fair thing > seems to be to put it in. Demonstrating "fair writeup to each > side", for the vote. I explained why I didn't think it was necessary. The fact that it isn't factually wrong does not mean that it must be included. I'm not obliged to put in every revision you send me. That would see no end. The writeup is fair already: It is not weighted to any outcome. Does anyone else have comment on the proposed text? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Wed Feb 16 04:44:59 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 15 Feb 2011 22:44:59 -0500 Subject: [csw-maintainers] the problem of imapd In-Reply-To: References: <1297820033-sup-6719@pinkfloyd.chass.utoronto.ca> Message-ID: <1297827542-sup-2790@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Feb 15 22:06:14 -0500 2011: > They are not particularly work-alikes. They just share the same > name. I think "alternatives" is best used when there is a very high > degree of functional similarity. Fair enough. It was just a thought. On other systems, this type of 'provides similar functionality' (as opposed to 'provides similar or extended interface' [ala sendmail, sudo*, etc]) use is offered. Example from Debian/Ubuntu: $ ls -l /usr/bin/editor /etc/alternatives/editor lrwxrwxrwx 1 root root 24 2011-01-07 03:50 /usr/bin/editor -> /etc/alternatives/editor lrwxrwxrwx 1 root root 9 2011-01-07 03:50 /etc/alternatives/editor -> /bin/nano If the binaries are to be renamed then I think matching the man page with the binary name makes the most sense. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Feb 16 10:07:39 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 16 Feb 2011 09:07:39 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Jonathan, 2011/2/15 Jonathan Craig : > 2011/2/15 Maciej Blizi?ski : >> 2011/2/15 Jonathan Craig : >>> The only section I felt was somewhat harry was the portion that spoke >>> about linking to an older library. ?This portion pre-supposes a >>> solution to this problem when it hasn't really been discussed (at >>> least in the context of this policy). >> >> It's a good time to discuss it. >> > > We can certainly discuss it but do we wish to hold up progress on > library placement for a sidebar discussion on how to support multiple > versions of a given runtime library for developers? ?One of the goals > was to decouple the shared library issue from how to support multiple > versions of a given application and then the proposal drives right > into this issue. True, although the proposal only deals with shared libraries. In most cases, supporting multiple versions is about conflicting executable names, e.g. in mysql or postgresql. We could take this issue out of the proposal, but it seems to me like the two issues are so closely related, they are best covered by a single document. >>> I think the subject of how to >>> enable access to older libraries for end-user developers merits its >>> own discussion and/or policy. ?The method described in the document >>> has some serious downfalls >> >> Could you outline them? > > The original example of devoid of packaging information. ?I'm assuming > at least two packages exist (libfoo1, libfoo2), but which one owns the > /opt/csw/lib/libfoo.so -> libfoo.so.N? The libfoo.so link belongs the libfoo_dev (CSWlibfoo-dev) package, and there's only one symlink. In most cases, we don't want to link to the old library, so there's one symlink, and it points at the newest version. Therefore, in the typical (no need to link against the old library), we have: CSWlibfoo1 (lib/libfoo.so.1) CSWlibfoo2 (lib/libfoo.so.2) CSWlibfoo_dev (lib/libfoo.so -> libfoo.so.2) > The example layout supposes the maintainer do a lot of monkeying about > to shuffle libraries around and, pardon my emotional response, feels > messy. ?If the library includes its own private prefix > (/opt/csw/{prefix}) then some stuff is shuffled to > /opt/csw/lib/{prefix} and other stuff is kept in > /opt/csw/{prefix}/lib. ?It feels confusing and fractured, but thats > just my opinion and I'm willing to hear counter arguments. The fragment about linking to older libraries was meant to show an example - how it can be done without a separate prefix. I wanted to counter the argument that this is something that requires compiling the whole package in to a separate prefix. > Could you talk through the design choices ?involved with the layout > shown in the proposal example over alternatives? There are two options: using a separate prefix, and using subdirectories. The --prefix way (used with berkeleydb): CSWlibfoo1 /opt/csw/libfoo1/lib/libfoo.so.1 CSWlibfoo1_dev /opt/csw/libfoo1/include/foo.h /opt/csw/libfoo1/lib/libfoo.so -> libfoo.so.1 CSWlibfoo2 /opt/csw/libfoo1/lib/libfoo.so.2 CSWlibfoo2_dev /opt/csw/libfoo2/include/foo.h /opt/csw/libfoo2/lib/libfoo.so -> libfoo.so.2 In this scenario, you always have to specify -I/opt/csw/libfoo1/include or -I/opt/csw/libfoo2/include, and -L/opt/csw/libfoo1/lib or -L/opt/csw/libfoo2/lib, otherwise the software you're compiling will not be able to find libfoo. Even if you want to link against the newest version (the default), you still have to specify these options. If you bring 64-bit libraries into the picture, the layout needs to include the 32 and 64 links: CSWlibfoo1 /opt/csw/libfoo1/lib/libfoo.so.1 /opt/csw/libfoo1/lib/sparcv9/libfoo.so.1 /opt/csw/libfoo1/32 -> . /opt/csw/libfoo1/64 -> sparcv9 CSWlibfoo1_dev /opt/csw/libfoo1/include/foo.h /opt/csw/libfoo1/lib/libfoo.so -> libfoo.so.1 /opt/csw/libfoo1/lib/sparcv9/libfoo.so -> libfoo.so.1 CSWlibfoo2 /opt/csw/libfoo2/lib/libfoo.so.2 /opt/csw/libfoo2/lib/sparcv9/libfoo.so.2 /opt/csw/libfoo2/32 -> . /opt/csw/libfoo2/64 -> sparcv9 CSWlibfoo2_dev /opt/csw/libfoo2/include/foo.h /opt/csw/libfoo2/lib/libfoo.so -> libfoo.so.2 /opt/csw/libfoo2/lib/sparcv9/libfoo.so -> libfoo.so.2 The second option, using subdirectories (and 64-bit libs): CSWlibfoo1 /opt/csw/lib/libfoo.so.1 /opt/csw/lib/sparcv9/libfoo.so.1 CSWlibfoo1_dev /opt/csw/include/libfoo1/foo.h /opt/csw/lib/libfoo1/libfoo.so -> ../libfoo.so.1 /opt/csw/lib/libfoo1/sparcv9/libfoo.so -> ../../sparcv9/libfoo.so.1 CSWlibfoo2 /opt/csw/lib/libfoo.so.2 /opt/csw/lib/sparcv9/libfoo.so.2 CSWlibfoo_dev /opt/csw/include/foo.h /opt/csw/lib/libfoo.so -> libfoo.so.2 /opt/csw/lib/sparcv9/libfoo.so -> libfoo.so.2 In this scenario, you can pass the standard flags (-I/opt/csw/include and -L/opt/csw/lib) and your software will link to the newest version of libfoo. If an older version is necessary, you need to pass additional -I and -L. >>> and I would prefer a method more like the >>> one used by ubuntu. ?This places the include.h and the libfoo.so link >>> into a versioned package like libfoo2.0-dev. ?This allows the end-user >>> to choose the default development version of the library to use with >>> builds by choosing the approriate -dev package. ?The libfoo-rt package >>> then would only have the libfoo.so.1 file needed by executables. >>> >>> Example: >>> appfoo1 >>> ?/opt/csw/bin/appfoo (depends on /opt/csw/libfoo.so.1) >>> >>> libfoo1rt >> >> I guess that would be libfoo1 / CSWlibfoo1. >> >>> ?/opt/csw/lib/libfoo.so.1 >>> >>> libfoo1-dev >>> ?/opt/csw/include/foo.h >>> ?/opt/csw/lib/libfoo.so -> libfoo.so.1 >>> >>> appfoo2 >>> ?/opt/csw/bin/appfoo (depends on /opt/csw/libfoo.so.2) >>> >>> libfoo2rt >>> ?/opt/csw/lib/libfoo.so.2 >>> >>> libfoo2-dev >>> ?/opt/csw/include/foo.h >>> ?/opt/csw/lib/libfoo.so -> libfoo.so.2 >>> >>> Now libfoo1rt and libfoo2rt can coexist and the end-user can choose >>> which library they want to develop against by choosing the appropriate >>> -dev package. >> >> In our case it can't be done by including files directly in packages. >> If you tried to release the -dev packages like this, your second >> package would be rejected with a note that it conflicts with the first >> one. ?Perhaps an approach using alternatives could be used: place >> files elsewhere and provide symlinks. > > Cant be done given the existing implementation or cant be done at all. > ?Should we limit our solutions to the existing code if it precludes > the implementation of a more elegant solution? In short, can't be done at all, unfortunately. The issue of conflicting files stems from the workings of Solaris packages. In dpkg for example, it is not allowed for one file to be owned by two packages. IIRC, you can create two packages providing the same file, but dpkg will not allow you to install them. In Solaris, pkgadd will return a success exit code and will overwrite the existing file on disk. In this scenario, whichever package was last, wins. This is not acceptable, so we need to enforce file uniqueness by never creating packages with conflicting files. The issue surfaced not so long ago, so there still is a good deal of conflicting files in the catalog[1]. If we encounter a case of colliding files, we need to either rename one or both files, or use alternatives. >> There's one issue to be addressed: we are using shared build systems >> on the buildfarm (e.g. current9s). ?It needs to be possible to link to >> libfoo.so.2 as well as libfoo.so.1 on a single system, without any >> global package manipulation (and root / sudo access). > > Hmm, this is a tough one because its a situation we have as a > maintainer community that isn't as much of an issue for an end user. > An end user can install/re-install the -dev package as needed. ?Access > to the shared library could be handled by creating a "lib" directory > in the package build space that creates the symlink to whatever > version of the shared library. ?This doesn't solve the issue of > conflicting include files. ?For the build farm could we have > installation of development packages into private root directories > that are added to the using -L/-I options but expect to find their > runtime libraries in /opt/csw/lib using -R. It would mean that we release development packages that we don't use ourselves. We would need to have an additional testing environment. That's a relatively large amount of work, where the group benefiting from it is probably very small, since we rarely hear from people building software using packages; and when we do, they usually become maintainers. Going back to the library placement proposal - if the linking against old libraries section is going to grow more, it should be taken out to a separate document. The proposal can simply mention that it does not prevent older shared libraries from being linked to. What do you think? Maciej [1] http://buildfarm.opencsw.org/pkgdb/error-tags/file-collision/ From william at wbonnet.net Wed Feb 16 10:22:11 2011 From: william at wbonnet.net (William Bonnet) Date: Wed, 16 Feb 2011 10:22:11 +0100 Subject: [csw-maintainers] p flag in package file version strings In-Reply-To: <1297818572-sup-9951@pinkfloyd.chass.utoronto.ca> References: <1297639256-sup-7574@pinkfloyd.chass.utoronto.ca> <4D586C19.9080405@wbonnet.net> <1297647505-sup-3210@pinkfloyd.chass.utoronto.ca> <4D5B0287.8080706@wbonnet.net> <1297818572-sup-9951@pinkfloyd.chass.utoronto.ca> Message-ID: Hi > Ah. Ok. I thought you were extracting the variables from the > Makefile. Makes sense. Thanks! In fact i'm keeping track of both gar and upstream version on one side, and on the other side a track of release date in the various catalog. You can see that on qa pages like this one : http://www-mockup.opencsw.org/qa/packages/python/ Output is still a bit messy in this draft ;) but release date to testing of python 2.6.2, 2.6.4, 2.6.5 and 2.6.6 are available. The date displayed is when the bot downloaded a catalog with this given version of the package. It is executed daily. That's why i also had to patch uWatch :) cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From james at opencsw.org Wed Feb 16 11:10:26 2011 From: james at opencsw.org (James Lee) Date: Wed, 16 Feb 2011 10:10:26 GMT Subject: [csw-maintainers] the problem of imapd In-Reply-To: References: Message-ID: <20110216.10102600.1028472535@gyor.oxdrove.co.uk> On 15/02/11, 22:43:50, Philip Brown wrote regarding [csw-maintainers] the problem of imapd: > Yann has got a pending update to cyrus imap, in newpkgs. > Trouble is, we now detect we have name clashes, and inconsistencies, > with the other two.. yes two.. imapd packages. > There is UW imap, aka CSWimap. maintainer, retired > Also, CSWcourierimap. separate maintainer, also retired. > The particular issues are twofold. > 1. name clash about the manpage. courier and cyrus both provide > "imapd.8" and that's before you try to use them, they will fight for default ports. Why would anyone want to run more than one? And if anyone did the sensible solution is to put each in its own zone. Recommendation: Tag as incompatible. James. From bwalton at opencsw.org Wed Feb 16 14:53:31 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 16 Feb 2011 08:53:31 -0500 Subject: [csw-maintainers] the problem of imapd In-Reply-To: <20110216.10102600.1028472535@gyor.oxdrove.co.uk> References: <20110216.10102600.1028472535@gyor.oxdrove.co.uk> Message-ID: <1297864223-sup-2621@pinkfloyd.chass.utoronto.ca> Excerpts from James Lee's message of Wed Feb 16 05:10:26 -0500 2011: > Recommendation: Tag as incompatible. I'm ok with this. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jcraig at opencsw.org Wed Feb 16 16:14:27 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Wed, 16 Feb 2011 10:14:27 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/16 Maciej Blizi?ski : >> We can certainly discuss it but do we wish to hold up progress on >> library placement for a sidebar discussion on how to support multiple >> versions of a given runtime library for developers? ?One of the goals >> was to decouple the shared library issue from how to support multiple >> versions of a given application and then the proposal drives right >> into this issue. > > True, although the proposal only deals with shared libraries. ?In most > cases, supporting multiple versions is about conflicting executable > names, e.g. in mysql or postgresql. ?We could take this issue out of > the proposal, but it seems to me like the two issues are so closely > related, they are best covered by a single document. > I'm okay with discussing and if time pressures demand we can sever the issue into its own space. > There are two options: using a separate prefix, and using subdirectories. Actually they amount to the same thing, they only differ in approach. One creates a bundled custom prefix (lib,bin,include together) and the other creates an unbundled custom prefix (lib, bin, include could be anywhere). The biggest difference would be an application that only allows you to specify a base directory for a library rather than allow explicit naming of each component. For these applications the maintainer would need to explicitly add -L/-I flags to allow the configure script to find these libraries. (argument for/against bundled vs unbundled custom prefix). > The --prefix way (used with berkeleydb): > This is what I would call the "bundled" custom prefix. > CSWlibfoo1 > /opt/csw/libfoo1/lib/libfoo.so.1 > CSWlibfoo1_dev > /opt/csw/libfoo1/include/foo.h > /opt/csw/libfoo1/lib/libfoo.so -> libfoo.so.1 > > CSWlibfoo2 > /opt/csw/libfoo1/lib/libfoo.so.2 > CSWlibfoo2_dev > /opt/csw/libfoo2/include/foo.h > /opt/csw/libfoo2/lib/libfoo.so -> libfoo.so.2 > > In this scenario, you always have to specify > -I/opt/csw/libfoo1/include or -I/opt/csw/libfoo2/include, and > -L/opt/csw/libfoo1/lib or -L/opt/csw/libfoo2/lib, otherwise the > software you're compiling will not be able to find libfoo. ?Even if > you want to link against the newest version (the default), you still > have to specify these options. > > If you bring 64-bit libraries into the picture, the layout needs to > include the 32 and 64 links: > > CSWlibfoo1 > /opt/csw/libfoo1/lib/libfoo.so.1 > /opt/csw/libfoo1/lib/sparcv9/libfoo.so.1 > /opt/csw/libfoo1/32 -> . > /opt/csw/libfoo1/64 -> sparcv9 > CSWlibfoo1_dev > /opt/csw/libfoo1/include/foo.h > /opt/csw/libfoo1/lib/libfoo.so -> libfoo.so.1 > /opt/csw/libfoo1/lib/sparcv9/libfoo.so -> libfoo.so.1 > > CSWlibfoo2 > /opt/csw/libfoo2/lib/libfoo.so.2 > /opt/csw/libfoo2/lib/sparcv9/libfoo.so.2 > /opt/csw/libfoo2/32 -> . > /opt/csw/libfoo2/64 -> sparcv9 > CSWlibfoo2_dev > /opt/csw/libfoo2/include/foo.h > /opt/csw/libfoo2/lib/libfoo.so -> libfoo.so.2 > /opt/csw/libfoo2/lib/sparcv9/libfoo.so -> libfoo.so.2 > > > The second option, using subdirectories (and 64-bit libs): What I would call the "unbundled" custom prefix. > > CSWlibfoo1 > /opt/csw/lib/libfoo.so.1 > /opt/csw/lib/sparcv9/libfoo.so.1 > CSWlibfoo1_dev > /opt/csw/include/libfoo1/foo.h > /opt/csw/lib/libfoo1/libfoo.so -> ../libfoo.so.1 > /opt/csw/lib/libfoo1/sparcv9/libfoo.so -> ../../sparcv9/libfoo.so.1 > > CSWlibfoo2 > /opt/csw/lib/libfoo.so.2 > /opt/csw/lib/sparcv9/libfoo.so.2 > CSWlibfoo_dev > /opt/csw/include/foo.h > /opt/csw/lib/libfoo.so -> libfoo.so.2 > /opt/csw/lib/sparcv9/libfoo.so -> libfoo.so.2 > > In this scenario, you can pass the standard flags (-I/opt/csw/include > and -L/opt/csw/lib) and your software will link to the newest version > of libfoo. ?If an older version is necessary, you need to pass > additional -I and -L. > One detractor to this approach is the need to update the old package to allow the new package or you have a file conflict for the /opt/csw/lib/libfoo.so -> xxx link. I suppose this could be left to a post install script but then you have a last package wins scenario. This makes the build state non-deterministic which can be problematic for troubleshooting. >>>> and I would prefer a method more like the >>>> one used by ubuntu. ?This places the include.h and the libfoo.so link >>>> into a versioned package like libfoo2.0-dev. ?This allows the end-user >>>> to choose the default development version of the library to use with >>>> builds by choosing the approriate -dev package. ?The libfoo-rt package >>>> then would only have the libfoo.so.1 file needed by executables. >>>> >>>> Now libfoo1rt and libfoo2rt can coexist and the end-user can choose >>>> which library they want to develop against by choosing the appropriate >>>> -dev package. >>> >>> In our case it can't be done by including files directly in packages. >>> If you tried to release the -dev packages like this, your second >>> package would be rejected with a note that it conflicts with the first >>> one. ?Perhaps an approach using alternatives could be used: place >>> files elsewhere and provide symlinks. >> >> Cant be done given the existing implementation or cant be done at all. >> ?Should we limit our solutions to the existing code if it precludes >> the implementation of a more elegant solution? > > In short, can't be done at all, unfortunately. > > The issue of conflicting files stems from the workings of Solaris > packages. ?In dpkg for example, it is not allowed for one file to be > owned by two packages. ?IIRC, you can create two packages providing > the same file, but dpkg will not allow you to install them. ?In > Solaris, pkgadd will return a success exit code and will overwrite the > existing file on disk. ?In this scenario, whichever package was last, > wins. ?This is not acceptable, so we need to enforce file uniqueness > by never creating packages with conflicting files. > This is where ubuntu uses a "conflicts with" dependency and only allows one development option to be installed at a time thereby sidestepping the issue of file conflict. Could we not also create a "conflicts with" dependency? > The issue surfaced not so long ago, so there still is a good deal of > conflicting files in the catalog[1]. > > If we encounter a case of colliding files, we need to either rename > one or both files, or use alternatives. > Seems like an argument for having a "conflicts with" dependency. >>> There's one issue to be addressed: we are using shared build systems >>> on the buildfarm (e.g. current9s). ?It needs to be possible to link to >>> libfoo.so.2 as well as libfoo.so.1 on a single system, without any >>> global package manipulation (and root / sudo access). >> >> Hmm, this is a tough one because its a situation we have as a >> maintainer community that isn't as much of an issue for an end user. >> An end user can install/re-install the -dev package as needed. ?Access >> to the shared library could be handled by creating a "lib" directory >> in the package build space that creates the symlink to whatever >> version of the shared library. ?This doesn't solve the issue of >> conflicting include files. ?For the build farm could we have >> installation of development packages into private root directories >> that are added to the using -L/-I options but expect to find their >> runtime libraries in /opt/csw/lib using -R. > > It would mean that we release development packages that we don't use > ourselves. ?We would need to have an additional testing environment. > That's a relatively large amount of work, where the group benefiting > from it is probably very small, since we rarely hear from people > building software using packages; and when we do, they usually become > maintainers. > No, what I was thinking of was specifying and "alternate_root" (pkgadd -R) when installing the development packages that would allow the maintainer to bypass the issue of file conflict. This is only intended to resolve the issue that we face in the build farm. So if we choose an alternate root base directory like /csw_dev/ then libfoo1-dev could be installed in /csw_dev/libfoo1-dev. Libraries are then available as /csw_dev/libfoo1-dev/opt/csw/lib/libfoo.so. The maintainer then specifies these directories in their -I/-L arguments. We would then be using the same packages as end-users, just installed into an alternate path. > Going back to the library placement proposal - if the linking against > old libraries section is going to grow more, it should be taken out to > a separate document. ?The proposal can simply mention that it does not > prevent older shared libraries from being linked to. > > What do you think? > Its a chicken and egg situation. Saying that shared libraries must be available in the global /opt/csw/lib directory means that all of these other things will need to be answered. Choices have impact, but that shouldn't turn us from facing them. I personally don't look at policies as being written in stone and therefore require exhaustive research to fully specify them the first time. Policy simply directs our actions in achieving a given outcome. As our understanding of the desired outcome develops, so must our policy. Lets capture our perception of what the desired outcome is and then we can kraft the policies over time to see they are achieved. From pfelecan at opencsw.org Wed Feb 16 16:38:05 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 16 Feb 2011 16:38:05 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: (Jonathan Craig's message of "Wed, 16 Feb 2011 10:14:27 -0500") References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: Jonathan Craig writes: > This is where ubuntu uses a "conflicts with" dependency and only > allows one development option to be installed at a time thereby > sidestepping the issue of file conflict. Could we not also create a > "conflicts with" dependency? Isn't "I" in depends exactly that? -- Peter From pfelecan at opencsw.org Wed Feb 16 16:40:19 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 16 Feb 2011 16:40:19 +0100 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: (Jonathan Craig's message of "Wed, 16 Feb 2011 10:14:27 -0500") References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: Jonathan Craig writes: > [...] I personally don't look at policies as being written in stone > and therefore require exhaustive research to fully specify them the > first time. Policy simply directs our actions in achieving a given > outcome.[...] Agreeing on this would shorten the length of our discussion and keep its focus. -- Peter From phil at bolthole.com Wed Feb 16 18:33:49 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Feb 2011 09:33:49 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Feb 16, 2011 at 7:40 AM, Peter FELECAN wrote: > Jonathan Craig writes: > >> [...] I personally don't look at policies as being written in stone >> and therefore require exhaustive research to fully specify them the >> first time. ?Policy simply directs our actions in achieving a given >> outcome.[...] > > Agreeing on this would shorten the length of our discussion and keep its > focus. Nice theory. Unfortunately, in practice, what this usually results in, is a maintainer submitting a package, which then bumps up against an ambiguity in the policy, and then they start screaming, "There's no policy against that, let my package through NOW!!!! Stop wasting my time discussing this!!" So, if people were more polite and patient, this would be a decent way to go. But given how people actually act, better to get the discussion fully done now. I have another email coming up, addressing a question than Jonathan had, in a minute. From phil at bolthole.com Wed Feb 16 18:56:50 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Feb 2011 09:56:50 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Jonathan, it's nice to see someone else who wants to think carefully about ramifications of things. Some info for you first, and then a new issue that your questions have pointed out. Maintainers intimately familiar with stuff, might choose to skip down to "start of new issue"; however, they are encouraged to give themselves a refresher on "why we do stuff", by reading the full email anyway :) On Wed, Feb 16, 2011 at 7:14 AM, Jonathan Craig wrote: > .... > This is where ubuntu uses a "conflicts with" dependency and only > allows one development option to be installed at a time thereby > sidestepping the issue of file conflict. ?Could we not also create a > "conflicts with" dependency? The reason we don't do this, is as follows: The concept is that we only keep development packages around, that we actually *need*. If it's obsolete, we jettison it. If it's useful, then it should be installable, along with everything else in our "current" catalog at the moment. Everything in the current mirror should be able to co-exist. Consider the alternative; maintainer A wants to work on FooSoft, version 1 maintainer B wants to work on FooSoft, version 2. Both versions are deemed "useful at the moment", so are in our current distrib. Should maintainer B have to wait until A is done tweaking, before doing work on our build machines? worse yet, should they have to ask a sysadmin to reinstall/tweak stuff, before he starts his development? and then the sysadmin has to put things back when done? This is not user-(or even maintainer) friendly. So, better to set things up to peacably co-exist without admin intervention. Additional retro info, that builds on the above: we dont keep old, obsolete "dev" packages around. However, we DO keep old shared libraries around, for as long as other packages of ours actually need them. We used to keep an archived copy of the older shared libs, in the "new" lib package. More recently, we started to split off shared libs into their own specifically named package. This has some good benefits. So, when we only have multi-versions of a shared lib for historical compat reasons, we may well have in our libdir, libfoo.so.1.0 libfoo.so.1.3 libfoo.so.1.5 libfoo.so -> libfoo.so.1.5 That allows for compat support, while still giving easy "new dev" use for -lfoo Keep that in mind, for the actual "new" issue, below ------ End of retro info, start of new issue (At least I think it is new. apologies if I misunderstood) ------ Again, this issue is ***only relevant for software with subprefixes***. This means, software that we have deemed important to have multiple versions installed, and that those versions somehow require /opt/csw/foosoft-X/ type subprefixes. It has been proposed, "oh there's no problem, we can just use constructs such as ./configure --with-foosoft-lib=/opt/csw/lib --with-foosoft-inc=/opt/csw/foosoft-X" type support. But that will not work cleanly. A properly written ./configure will use BOTH -L and -R, set to the --with-lib dir specified. If they are both set to /opt/csw/lib, then it will potentially use the "wrong" version, if an older version of the shared lib is desired. (remember, /opt/csw/lib/libfoo.so always points to /opt/csw/lib/libfoo.so.latest) If on the other hand, both -L and -R are set to /opt/csw/foosoft-X/lib ... well, then the older version of the lib in /opt/csw/lib, whether "real" or symlink, will never be used, and we just completely wasted our time in putting it in /opt/csw/lib in the first place. Now yes, in theory, we could set **by hand**, -L/opt/csw/lib/foosoft-X/lib -R/opt/csw/lib But really.. why should we implement a policy that causes us to fight installers by hand like this? Seems like we need to adjust the policy some more. Or perhaps reconsider its usefulness :( From phil at bolthole.com Wed Feb 16 19:13:31 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Feb 2011 10:13:31 -0800 Subject: [csw-maintainers] the problem of imapd In-Reply-To: <1297864223-sup-2621@pinkfloyd.chass.utoronto.ca> References: <20110216.10102600.1028472535@gyor.oxdrove.co.uk> <1297864223-sup-2621@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Feb 16, 2011 at 5:53 AM, Ben Walton wrote: > Excerpts from James Lee's message of Wed Feb 16 05:10:26 -0500 2011: > >> Recommendation: Tag as incompatible. > > I'm ok with this. > I'm not. It breaks our long-standing standards that installing everything is okay. (reminder: if you use autoenable_daemons=no in csw.conf, you can install everything, but not have any port conflicts, becuase nothing is started up on any port, except what you explicitly choose to enable on that specific machine) AND, it doesnt solve our issue of filename clashes anyway. Are you also saying, we stop caring about filename clashes? Or that we're going to make some new fancy database schema about "warn about file conflicts.. EXCEPT if you cross-reference this other special database of exceptions" ? We already ship multiple things that are functionally incompatible if started on the same port. Are you also pushing to flag postfix, sendmail, and exim as incompatible? and the multiple webservers? and the multiple ftp servers? From phil at bolthole.com Wed Feb 16 19:26:22 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Feb 2011 10:26:22 -0800 Subject: [csw-maintainers] the problem of imapd In-Reply-To: References: <20110216.10102600.1028472535@gyor.oxdrove.co.uk> <1297864223-sup-2621@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Feb 16, 2011 at 10:13 AM, Philip Brown wrote: > On Wed, Feb 16, 2011 at 5:53 AM, Ben Walton wrote: >> Excerpts from James Lee's message of Wed Feb 16 05:10:26 -0500 2011: >> >>> Recommendation: Tag as incompatible. >> >> I'm ok with this. >> > > I'm not. It breaks our long-standing standards that installing > everything is okay. > > (reminder: if you use autoenable_daemons=no in csw.conf, you can > install everything, but not have any port conflicts, becuase nothing > is started up on any port, except what you explicitly choose to enable > on that specific machine) Another point why this policy makes sense, even on a relatively small, single-server installation, at a small site: Allowing the multiple types to be installed, even if only one is active at a time, allows the local sysadmin the freedom to do limited trial tests of alternatives implementations. - Start with sendmail? okay. All set up, things looking good (couple of months down the road...) Hmm.. I wonder if postfix would be better? - installs postfix, on SAME BOX, initially on different port. plays around for a few days, gets it happy, and then does an almost transparent switchover when happy with it. Cant do that if postfix conflicts with sendmail. From jcraig at opencsw.org Wed Feb 16 19:29:17 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Wed, 16 Feb 2011 13:29:17 -0500 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Feb 16, 2011 at 12:33 PM, Philip Brown wrote: > On Wed, Feb 16, 2011 at 7:40 AM, Peter FELECAN wrote: >> Jonathan Craig writes: >> >>> [...] I personally don't look at policies as being written in stone >>> and therefore require exhaustive research to fully specify them the >>> first time. ?Policy simply directs our actions in achieving a given >>> outcome.[...] >> >> Agreeing on this would shorten the length of our discussion and keep its >> focus. > > > Nice theory. Unfortunately, in practice, what this usually results in, > is a maintainer submitting a package, > which then bumps up against an ambiguity in the policy, and then they > start screaming, "There's no policy against that, let my package > through NOW!!!! Stop wasting my time discussing this!!" > > So, if people were more polite and patient, this would be a decent way > to go. But given how people actually act, better to get the discussion > fully done now. > > I have another email coming up, addressing a question than Jonathan > had, in a minute. Nice theory. Unfortunately, in practice, what this usually results in, is no policies get written at all. I'm not arguing that policy doesn't need careful consideration, just that it has to be tinged with a sense of timeliness. Nobody can game out all of the possible scenario's surrounding a policy, so the policy needs flexibility. This is achieved by leaving policy at the upper layer of architecture/design and/or by allowing the policy to be shaped through experience as the policies of governments are shaped by courts. One must capture the spirit of the law so that one can can flex the letter of the law to see that the spirit is upheld. If policies become to cumbersome, and then are administered by strict constructionist, then they are doomed to failure over time. Maintainers become impatient when policies are poorly crafted and have an arbitrary feeling. If they understand the intent then they can apply their skills and art to achieving the intent and in the process further our craft. So it was written in the "Philosophy of Policy" by Jon Craig ;) From phil at bolthole.com Wed Feb 16 19:48:42 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Feb 2011 10:48:42 -0800 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Feb 16, 2011 at 10:29 AM, Jonathan Craig wrote: >?Nobody can game out all of the possible > scenario's surrounding a policy, so the policy needs flexibility. > This is achieved by leaving policy at the upper layer of > architecture/design and/or by allowing the policy to be shaped through > experience as the policies of governments are shaped by courts. ? One > must capture the spirit of the law so that one can can flex the letter > of the law to see that the spirit is upheld. Interestingly, this is by far my preferred method of handling things. That is how things used to work, years ago. But more recently, some people have taken an attitude of, "that's not *policy*.. where's that written down? if it's not 'policy' (and written to EXACTLY ADDRESS this situation), then I'm going to do it my way, and I'm going to ignore anything you have to say. " I really dont like working that way. But people have been screaming for policy,policy, policy. So here we are. From phil at bolthole.com Thu Feb 17 05:47:53 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Feb 2011 20:47:53 -0800 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: <1297827146-sup-3401@pinkfloyd.chass.utoronto.ca> References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> <1297738402-sup-4740@pinkfloyd.chass.utoronto.ca> <1297819720-sup-9648@pinkfloyd.chass.utoronto.ca> <1297827146-sup-3401@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Feb 15, 2011 at 7:38 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Tue Feb 15 22:12:56 -0500 2011: > >> Unless you think what I wrote was factually *wrong*, the fair thing >> seems to be to put it in. ?Demonstrating "fair writeup to each >> side", for the vote. > > I explained why I didn't think it was necessary. The fact that it > isn't factually wrong does not mean that it must be included. I'm not > obliged to put in every revision you send me. That would see no end. > obliged to put in every revision you send me. ?That would see no end. > The writeup is fair already: It is not weighted to any outcome. A writeup of a topic with two equal sides, where people on one side think it is "good", and people on the other think it is "not good", is pretty much a textbook example of "unfair and biased". Your excuse about "no end of changes" is very weak. I have given you the only changes that I think are necessary to make it ready for voting, and you deliberately took out the part of them that was most convincing against your preferred voting side. You are abusing your power in the voting realm. again. From bwalton at opencsw.org Fri Feb 18 09:14:25 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 18 Feb 2011 03:14:25 -0500 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> <1297738402-sup-4740@pinkfloyd.chass.utoronto.ca> <1297819720-sup-9648@pinkfloyd.chass.utoronto.ca> <1297827146-sup-3401@pinkfloyd.chass.utoronto.ca> Message-ID: <1298016599-sup-463@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Feb 16 23:47:53 -0500 2011: Hi Phil, > A writeup of a topic with two equal sides, where people on one side > think it is "good", and people on the other think it is "not good", > is pretty much a textbook example of "unfair and biased". The problem with your text is that it's equivalent to having someone stand at the polling booth arguing for one cadidate. It's not unbiased text as it 'leads' the voter in one direction, putting a thought pattern in place as they read the ballot. I added the text that indicates that granting a key is irrevocable, which is already leaning in this direction. If you want more 'doom and gloom' text, that's going too far. > You are abusing your power in the voting realm. again. I didn't see any other member chime in saying they thought this text was necessary. I'm willing to be flexible on this and I think I already have. I'll run this past folks at the camp today and if there is any support for it, I'll add it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From skayser at opencsw.org Fri Feb 18 15:48:00 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 18 Feb 2011 15:48:00 +0100 Subject: [csw-maintainers] OT: LISA '09 / Systems can bite, if you don't care for them Message-ID: <20110218144800.GC21671@sebastiankayser.de> Hi, we've had the theme over lunch in Dublin, so here's - for reference purposes - the LISA '09 video filled with sysadmin anecdotes (related to uncared for systems). Should be an enjoyable watch for everyone who administrates computer boxes. "The Water Fountain vs. the Fire Hose: An Examination and Comparison of Two Large Enterprise Mail Service Migrations" http://www.usenix.org/event/lisa09/tech/ http://www.usenix.org/multimedia/lisa09stacey Sebastian From skayser at opencsw.org Fri Feb 18 16:37:04 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 18 Feb 2011 16:37:04 +0100 Subject: [csw-maintainers] FYI: Email notify hook added for opencsw.svn.sf.net Message-ID: <20110218153704.GD21671@sebastiankayser.de> Hi, to increase visibility for what's going on in the project, I've just added an email notification hook for our OpenCSW repository - similar to what we already have in place for our GAR repository [1,2]. Notifications are expected to be relatively low in volume and are also sent to: devel at lists.opencsw.org. Sebastian [1] http://opencsw.svn.sourceforge.net/svnroot/opencsw [2] http://gar.svn.sourceforge.net/svnroot/gar From maciej at opencsw.org Fri Feb 18 17:36:16 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 18 Feb 2011 16:36:16 +0000 Subject: [csw-maintainers] [PATCH] checkpkg: Checking if catalogname matches pkgname In-Reply-To: <1297596614-24374-1-git-send-email-maciej@opencsw.org> References: <1297596614-24374-1-git-send-email-maciej@opencsw.org> Message-ID: 2011/2/13 Maciej Blizinski : > This patch is updated according to Peter Felecan's suggestions - it links to > the standards page covering package naming. I've committed the patch, after updating your clients, your packages will be checked if their catalognames and pkgnames match. I'm aware that there are many packages which will trigger this error. If you have an existing package and you see this error, it doesn't mean you have to change it. You can rename it so it matches, but you don't have to. If you don't wish to change the name of your package, you can override the error. When creating new packages, make sure that the catalogname and pkgname are matching, and checkpkg will help you spot a mismatch. Maciej From phil at bolthole.com Fri Feb 18 17:46:37 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Feb 2011 08:46:37 -0800 Subject: [csw-maintainers] FYI: Email notify hook added for opencsw.svn.sf.net In-Reply-To: <20110218153704.GD21671@sebastiankayser.de> References: <20110218153704.GD21671@sebastiankayser.de> Message-ID: Ahh.. could you summarize the difference, please? (ie; what's the new effect with this?) On 2/18/11, Sebastian Kayser wrote: > Hi, > > to increase visibility for what's going on in the project, I've just > added an email notification hook for our OpenCSW repository - similar to > what we already have in place for our GAR repository [1,2]. > > Notifications are expected to be relatively low in volume and are also > sent to: devel at lists.opencsw.org. > > Sebastian > > [1] http://opencsw.svn.sourceforge.net/svnroot/opencsw > [2] http://gar.svn.sourceforge.net/svnroot/gar > _______________________________________________ > 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 Fri Feb 18 18:02:24 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 18 Feb 2011 12:02:24 -0500 Subject: [csw-maintainers] i cswreleasenotes Message-ID: <1298048314-sup-2560@pinkfloyd.chass.utoronto.ca> Hi All, I just committed a change to GAR that allows easy addition of the cswreleasenotes file that has been suggested on a few occassions. Add CSWfoo.cswreleasenotes to files/ with content intended for internal release issues (eg: this contains /usr/local references but they're ok) and tack it onto DISTFILES. It might be nice to standardize (informally) the formatting of this file for consistent review, but that's a whole other topic. Let me know if you have issues with it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Feb 18 18:28:25 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Feb 2011 09:28:25 -0800 Subject: [csw-maintainers] i cswreleasenotes In-Reply-To: <1298048314-sup-2560@pinkfloyd.chass.utoronto.ca> References: <1298048314-sup-2560@pinkfloyd.chass.utoronto.ca> Message-ID: On 2/18/11, Ben Walton wrote: > > Hi All, > > I just committed a change to GAR that allows easy addition of the > cswreleasenotes file that has been suggested on a few occassions. Add > CSWfoo.cswreleasenotes to files/ with content intended for internal > release issues (eg: this contains /usr/local references but they're > ok) and tack it onto DISTFILES. > great. minor issue: technically, I believe it was originally defined as "i cswreleasemgr", and was documented as such. If we want to change it, that's fine(since no one has used it yet I think), but please update the docs. ( http://www.opencsw.org/extend-it/contribute-packages/build-standards/ ) From skayser at opencsw.org Fri Feb 18 18:36:35 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 18 Feb 2011 18:36:35 +0100 Subject: [csw-maintainers] FYI: Email notify hook added for opencsw.svn.sf.net In-Reply-To: References: <20110218153704.GD21671@sebastiankayser.de> Message-ID: <4D5EAE23.30609@opencsw.org> Philip Brown wrote on 2/18/2011 5:46 PM: > Ahh.. could you summarize the difference, please? > (ie; what's the new effect with this?) The GAR repo holds GAR + the pkg build descriptions. The OpenCSW repo holds various tools used throughout the project. Up to today, repo commit diffs were sent to devel@ only for the GAR repo. Now, this happens for the OpenCSW repo also. Sebastian From phil at bolthole.com Fri Feb 18 18:50:01 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Feb 2011 09:50:01 -0800 Subject: [csw-maintainers] FYI: Email notify hook added for opencsw.svn.sf.net In-Reply-To: <4D5EAE23.30609@opencsw.org> References: <20110218153704.GD21671@sebastiankayser.de> <4D5EAE23.30609@opencsw.org> Message-ID: On 2/18/11, Sebastian Kayser wrote: > Philip Brown wrote on 2/18/2011 5:46 PM: >> Ahh.. could you summarize the difference, please? >> (ie; what's the new effect with this?) > > The GAR repo holds GAR + the pkg build descriptions. > The OpenCSW repo holds various tools used throughout the project. > > Up to today, repo commit diffs were sent to devel@ only for the GAR > repo. Now, this happens for the OpenCSW repo also. Interesting. you guys might want to update the summary pages, etc, on places like http://sourceforge.net/projects/opencsw/ It seems to imply that the "opencsw" area is where you find build recipes. So it could use a rewrite, along the lines of "For build recipes, go to [gar.sf.net]. For tools outside of our officially mirrored packages, check [our opencsw internal tool source code tree here]" From bwalton at opencsw.org Sat Feb 19 11:18:15 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Feb 2011 05:18:15 -0500 Subject: [csw-maintainers] i cswreleasenotes In-Reply-To: References: <1298048314-sup-2560@pinkfloyd.chass.utoronto.ca> Message-ID: <1298110652-sup-5292@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Feb 18 12:28:25 -0500 2011: > technically, I believe it was originally defined as "i > cswreleasemgr", and was documented as such. If we want to change it, > that's fine(since no one has used it yet I think), but please update > the docs. Yes, but I felt cswreleasenotes was more general. The docs are updated. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Feb 19 12:03:26 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Feb 2011 06:03:26 -0500 Subject: [csw-maintainers] Camp Broadcast Message-ID: <1298113313-sup-8192@pinkfloyd.chass.utoronto.ca> Hi All, For those that can tune in, we're broadcasting the camp at: http://www.ustream.tv/channel/opencswsummercamp-2010 Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Feb 19 12:10:07 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Feb 2011 06:10:07 -0500 Subject: [csw-maintainers] camp discussion document Message-ID: <1298113745-sup-4357@pinkfloyd.chass.utoronto.ca> Hi All, If you want to follow along with the camp document, we're using a google doc this time instead of a wave. If you join the opencsw-maintainers google group you can follow along. Send a request to join and we'll add you. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Feb 19 13:30:55 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Feb 2011 07:30:55 -0500 Subject: [csw-maintainers] camp discussion document In-Reply-To: <1298113745-sup-4357@pinkfloyd.chass.utoronto.ca> References: <1298113745-sup-4357@pinkfloyd.chass.utoronto.ca> Message-ID: <1298118610-sup-6166@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sat Feb 19 06:10:07 -0500 2011: > If you want to follow along with the camp document, we're using a > google doc this time instead of a wave. If you join the > opencsw-maintainers google group you can follow along. Send a > request to join and we'll add you. When you subscribe to the group, you'll see the document in the 'archives' area. In the document view, you can toggle on the live chat section of the view and get the real-time conversation 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 Feb 19 15:36:35 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 19 Feb 2011 06:36:35 -0800 Subject: [csw-maintainers] [policy] GPG Signing Key handling In-Reply-To: <1298016599-sup-463@pinkfloyd.chass.utoronto.ca> References: <1297214967-sup-1568@pinkfloyd.chass.utoronto.ca> <1297738402-sup-4740@pinkfloyd.chass.utoronto.ca> <1297819720-sup-9648@pinkfloyd.chass.utoronto.ca> <1297827146-sup-3401@pinkfloyd.chass.utoronto.ca> <1298016599-sup-463@pinkfloyd.chass.utoronto.ca> Message-ID: On Friday, February 18, 2011, Ben Walton wrote: > Excerpts from Philip Brown's message of Wed Feb 16 23:47:53 -0500 2011: > > Hi Phil, > >> A writeup of a topic with two equal sides, where people on one side >> think it is "good", and people on the other think it is "not good", >> is pretty much a textbook example of "unfair and biased". > > The problem with your text is that it's equivalent to having someone > stand at the polling booth arguing for one cadidate. ?It's not > unbiased text as it 'leads' the voter in one direction, putting a > thought pattern in place as they read the ballot. the problem with what *you* just said, is it amounts to, "your wording is too persuasive, people might actually listen to it and vote accordingly. so I'm not going to allow it" That, is the definition of bias in a voting system the whole point of a well written ballot, is that it gives all relevant facts for both sides. BOTH sides, Ben. That very much includes facts relating to (if you vote this way, then that will happen) What I wrote was 100% factual. and if one side has compelling facts, and the other does not... well then, in a fair voting system, the first side should win, should it not? that's what's supposed to happen. it's not your job to give the other side 'more of a fighting chance' if you personally favor it. From bwalton at opencsw.org Sat Feb 19 16:43:18 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Feb 2011 10:43:18 -0500 Subject: [csw-maintainers] GPG Key Vote Message-ID: <1298129678-sup-6465@pinkfloyd.chass.utoronto.ca> Hi All, We discussed yesterday briefly the GPG voting issue and arrived at two concensus points. 1. Nobody here felt the current wording was unfair. 2. As this is not something that is intended to remove control or demote or any such negative thing, we are going to add a 4th question to the ballot. That question will be a binary choice that allows the voter to say (not exact wording here): the board members will directly hold the raw key files or the board members will hold the key in shared (n out of p) escrow. So, the final vote will let you select how many and which positions should hold the key _and_ how it should be held by those people. William has asked his colleagues for good software to use for such a scenario and we'll define this before proceeding. He has already received the recommendation for a tool called ssss[1]. It's agreed by participants at the camp that using a tool such as this is a fine solution and should address most concerns. The ballot will be updated when I have a few minutes to do so. Thanks -Ben [1] http://point-at-infinity.org/ssss/ -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sat Feb 19 17:10:22 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 19 Feb 2011 08:10:22 -0800 Subject: [csw-maintainers] camp discussion document In-Reply-To: <1298118610-sup-6166@pinkfloyd.chass.utoronto.ca> References: <1298113745-sup-4357@pinkfloyd.chass.utoronto.ca> <1298118610-sup-6166@pinkfloyd.chass.utoronto.ca> Message-ID: where is this "group"? I don't see group, in google docs On Saturday, February 19, 2011, Ben Walton wrote: > Excerpts from Ben Walton's message of Sat Feb 19 06:10:07 -0500 2011: > >> If you want to follow along with the camp document, we're using a >> google doc this time instead of a wave. ?If you join the >> opencsw-maintainers google group you can follow along. ?Send a >> request to join and we'll add you. > > When you subscribe to the group, you'll see the document in the > 'archives' area. ?In the document view, you can toggle on the live > chat section of the view and get the real-time conversation too. > > 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 bwalton at opencsw.org Sat Feb 19 17:36:05 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Feb 2011 11:36:05 -0500 Subject: [csw-maintainers] OpenCSW visibility Message-ID: <1298132997-sup-2786@pinkfloyd.chass.utoronto.ca> Hi All, We've just discussed a few ideas for increasing the visibility of OpenCSW (google rankings, etc). One thing that came up is that we're not methodically attempting to have upstream projects link to their package pages in our site. Most projects will do this and some already are, but we think it's important to both a) contact upstream for packages you already look after and b) make this a part of your work flow as you package new things. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Feb 19 17:37:07 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Feb 2011 11:37:07 -0500 Subject: [csw-maintainers] camp discussion document In-Reply-To: References: <1298113745-sup-4357@pinkfloyd.chass.utoronto.ca> <1298118610-sup-6166@pinkfloyd.chass.utoronto.ca> Message-ID: <1298133398-sup-7525@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Feb 19 11:10:22 -0500 2011: > where is this "group"? > I don't see group, in google docs It's a separate entity available at: groups.google.com Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sun Feb 20 17:37:18 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 20 Feb 2011 08:37:18 -0800 Subject: [csw-maintainers] camp "stream" Message-ID: <20110220163718.GA58423@bolthole.com> Hey, can you guys see the chat thingie that goes along with the video feed? From maciej at opencsw.org Sun Feb 20 17:43:50 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 20 Feb 2011 16:43:50 +0000 Subject: [csw-maintainers] camp "stream" In-Reply-To: <20110220163718.GA58423@bolthole.com> References: <20110220163718.GA58423@bolthole.com> Message-ID: 2011/2/20 Philip Brown : > Hey, can you guys see the chat thingie that goes along with the video feed? I opened it and saw "bolthole" for a few seconds before it disappeared. Most of the time, we project the google doc (link available from the archives of opencsw-maintainers group on googlegroups[1]), and it has a chat on the side, which we see. Maciej [1] http://groups.google.com/group/opencsw-maintainers From maciej at opencsw.org Tue Feb 22 00:48:22 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 21 Feb 2011 23:48:22 +0000 Subject: [csw-maintainers] Wintercamp 2011 minutes Message-ID: I've published meeting minutes on the Wintercamp wiki page: http://wiki.opencsw.org/wintercamp-2011 Minutes are divided into 3 parts, there are separate documents for Friday, Saturday and Sunday. Links are near the bottom of the page. One of the highlights of the wintercamp meetings was a conference call with Phil on Sunday. It was something we haven't tried before on a OpenCSW camp. It worked very well! Two topics were discussed: hudson and a plan for PKI. It was a productive meeting, we've agreed about a number of points regarding key management, and produced a diagram and notes. I think that teleconferencing is a great option for project members living outside Europe. Since this worked so well, we'll plan such conference calls ahead before next camps, and plan the day so that we can make a good use of the time overlap with American time zones. Maciej From maciej at opencsw.org Thu Feb 24 09:38:37 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 24 Feb 2011 08:38:37 +0000 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: 2011/2/15 Dagobert Michelsen : >> Is there any new input? If no I suggest getting to a vote. >> (1) CSW*-dev ? *_dev >> (2) CSW*-devel ?*_devel >> While the current OpenCSW standard is (2) the solution (2) is short leaving >> more space for package names, is consistent with other packaging projects >> and without loss of meaning. I'm currently setting up the vote on ballotbin. I don't know how much writeup from my side is expected. On one hand, I feel that the ballot should contain a reference or a writeup, but on the other hand, if I start writing it, my writeup will just get criticized and will never be good enough. I'm inclined to do no writeup whatsoever, and only include a link to this thread: http://lists.opencsw.org/pipermail/maintainers/2011-February/014148.html Maciej From pfelecan at opencsw.org Thu Feb 24 10:06:58 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 24 Feb 2011 10:06:58 +0100 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 24 Feb 2011 08:38:37 +0000") References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: Maciej Blizi?ski writes: > 2011/2/15 Dagobert Michelsen : >>> Is there any new input? If no I suggest getting to a vote. >>> (1) CSW*-dev ? *_dev >>> (2) CSW*-devel ?*_devel >>> While the current OpenCSW standard is (2) the solution (2) is short leaving >>> more space for package names, is consistent with other packaging projects >>> and without loss of meaning. > > I'm currently setting up the vote on ballotbin. I don't know how much > writeup from my side is expected. On one hand, I feel that the ballot > should contain a reference or a writeup, but on the other hand, if I > start writing it, my writeup will just get criticized and will never > be good enough. I'm inclined to do no writeup whatsoever, and only > include a link to this thread: > > http://lists.opencsw.org/pipermail/maintainers/2011-February/014148.html The writeup is clearly the citation of Dagobert's message. As we discussed this in the referenced thread I think that a vote can go as soon as it is set up, no more discussion is needed. -- Peter From phil at bolthole.com Thu Feb 24 18:02:04 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Feb 2011 09:02:04 -0800 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: On 2/24/11, Maciej Blizi?ski wrote: > I'm inclined to do no writeup whatsoever, and only > include a link to this thread: > > http://lists.opencsw.org/pipermail/maintainers/2011-February/014148.html > which will ensure that some people will not read it. There is a solution to this; I already proposed it in a thread a while back, but I'll repeat it. have one person from "each side", do a part of the writeup. This is a standard real-world methodology for ballots in some places. Each "side" gets complete control over their part of the writeup. There should only be editorial fiddling, if either one side gives *factually incorrect* statements, or it is just ludicrously long. (3x the length of the other side, or something) From pfelecan at opencsw.org Thu Feb 24 18:44:39 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 24 Feb 2011 18:44:39 +0100 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: (Philip Brown's message of "Thu, 24 Feb 2011 09:02:04 -0800") References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: Philip Brown writes: > On 2/24/11, Maciej Blizi?ski wrote: >> I'm inclined to do no writeup whatsoever, and only >> include a link to this thread: >> >> http://lists.opencsw.org/pipermail/maintainers/2011-February/014148.html >> > > which will ensure that some people will not read it. Why do you think so? It's a URI accessible for everybody, isn't it? > There is a solution to this; I already proposed it in a thread a while > back, but I'll repeat it. > have one person from "each side", do a part of the writeup. > This is a standard real-world methodology for ballots in some places. > > Each "side" gets complete control over their part of the writeup. > There should only be editorial fiddling, if either one side gives > *factually incorrect* statements, or it is just ludicrously long. (3x > the length of the other side, or something) The message at the head of this thread cites a honest summary that Dagobert has done. There is nothing wrong with that. Or is it? -- Peter From phil at bolthole.com Thu Feb 24 19:08:25 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Feb 2011 10:08:25 -0800 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: On 2/24/11, Peter FELECAN wrote: > Philip Brown writes: > >> On 2/24/11, Maciej Blizi?ski wrote: >>> I'm inclined to do no writeup whatsoever, and only >>> include a link to this thread: >>> >>> http://lists.opencsw.org/pipermail/maintainers/2011-February/014148.html >>> >> >> which will ensure that some people will not read it. > > Why do you think so? It's a URI accessible for everybody, isn't it? >... >> Each "side" gets complete control over their part of the writeup. >> There should only be editorial fiddling, if either one side gives >> *factually incorrect* statements, or it is just ludicrously long. (3x >> the length of the other side, or something) > > The message at the head of this thread cites a honest summary that > Dagobert has done. There is nothing wrong with that. Or is it? > ironically, I think you just proved my point, "people wont read the thread". Because if you had (re?)read the whole thread rather than just the first article, you would already know my viewpoint on Dagobert's summary. Now, speaking of "what's wrong with that?" questions... what's wrong with my proposal about ballot writeups? From maciej at opencsw.org Thu Feb 24 19:10:13 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 24 Feb 2011 18:10:13 +0000 Subject: [csw-maintainers] Shared library placement proposal In-Reply-To: References: <1297135491-sup-6002@pinkfloyd.chass.utoronto.ca> <1297303337-sup-8721@pinkfloyd.chass.utoronto.ca> <1297470527-sup-5875@pinkfloyd.chass.utoronto.ca> <1297738731-sup-6144@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/2/16 Jonathan Craig : > I'm okay with discussing and if time pressures demand we can sever the > issue into its own space. I've moved the issue of old libraries to a separate document[1]. It needs to be expanded to include the sparcv9 subdirectories. > This is where ubuntu uses a "conflicts with" dependency and only > allows one development option to be installed at a time thereby > sidestepping the issue of file conflict. ?Could we not also create a > "conflicts with" dependency? > >> The issue surfaced not so long ago, so there still is a good deal of >> conflicting files in the catalog[1]. >> >> If we encounter a case of colliding files, we need to either rename >> one or both files, or use alternatives. >> > > Seems like an argument for having a "conflicts with" dependency. We currently have a non-codified, but enforced policy that no two packages can ship a non-directory file with the same path. AFAIK, release manager scripts are current written in such a way that they disallow registration of such package in the database. >> Going back to the library placement proposal - if the linking against >> old libraries section is going to grow more, it should be taken out to >> a separate document. ?The proposal can simply mention that it does not >> prevent older shared libraries from being linked to. >> >> What do you think? >> > > Its a chicken and egg situation. ?Saying that shared libraries must be > available in the global /opt/csw/lib directory means that all of these > other things will need to be answered. ?Choices have impact, but that > shouldn't turn us from facing them. ?I personally don't look at > policies as being written in stone and therefore require exhaustive > research to fully specify them the first time. ?Policy simply directs > our actions in achieving a given outcome. ?As our understanding of the > desired outcome develops, so must our policy. ?Lets capture our > perception of what the desired outcome is and then we can kraft the > policies over time to see they are achieved. Yes, we seem to be on the same page. The proposal allows exceptions, if they're necessary. When we tackle the old libraries issue, and we discover that the shared library placement policy needs to be amended, we'll do that. Likely, in the same patch to the opencsw-policy package. I've updated the document: http://wiki.opencsw.org/proposal:shared-library-placement Maciej [1] http://wiki.opencsw.org/shared-libraries#toc0 From pfelecan at opencsw.org Thu Feb 24 19:53:42 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 24 Feb 2011 19:53:42 +0100 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: (Philip Brown's message of "Thu, 24 Feb 2011 10:08:25 -0800") References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: Philip Brown writes: > On 2/24/11, Peter FELECAN wrote: >> Philip Brown writes: >> >>> On 2/24/11, Maciej Blizi?ski wrote: >>>> I'm inclined to do no writeup whatsoever, and only >>>> include a link to this thread: >>>> >>>> http://lists.opencsw.org/pipermail/maintainers/2011-February/014148.html >>>> >>> >>> which will ensure that some people will not read it. >> >> Why do you think so? It's a URI accessible for everybody, isn't it? >>... >>> Each "side" gets complete control over their part of the writeup. >>> There should only be editorial fiddling, if either one side gives >>> *factually incorrect* statements, or it is just ludicrously long. (3x >>> the length of the other side, or something) >> >> The message at the head of this thread cites a honest summary that >> Dagobert has done. There is nothing wrong with that. Or is it? >> > > ironically, I think you just proved my point, "people wont read the > thread". Because if you had (re?)read the whole thread rather than > just the first article, you would already know my viewpoint on > Dagobert's summary. You misunderstood my remark: I referred to the message at the head of *this* thread, the one that contains *this* message and which was cited in Maciej's call for vote: 2011/2/15 Dagobert Michelsen : >> Is there any new input? If no I suggest getting to a vote. >> (1) CSW*-dev ? *_dev >> (2) CSW*-devel ?*_devel >> While the current OpenCSW standard is (2) the solution (2) is short leaving >> more space for package names, is consistent with other packaging projects >> and without loss of meaning. In conclusion, if somebody wants to be informed can have your opinion and act upon it. > Now, speaking of "what's wrong with that?" questions... what's wrong > with my proposal about ballot writeups? In principle nothing, except that IMO this is a desultory diversion: we discussed the subject during 10 days, all the opinions were exposed, including yours, the ballot was set up after 10 additional days, which, given the circumstances is justified, viz. Dublin Camp, and it ends in 6 days, which in my opinion is to long; that is almost one month to make a relatively small decision. If, for every decision on which a vote is taken, we spend a month, our speed is that of an enraged snail... It's a clear testbed case for the processes which govern our community. So, lets try to do it without endless discussion about how. -- Peter From phil at bolthole.com Thu Feb 24 23:36:58 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Feb 2011 14:36:58 -0800 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: On 2/24/11, Peter FELECAN wrote: > Philip Brown writes: > >> >> ironically, I think you just proved my point, "people wont read the >> thread". Because if you had (re?)read the whole thread rather than >> just the first article, you would already know my viewpoint on >> Dagobert's summary. > > You misunderstood my remark: I referred to the message at the head of > *this* thread, the one that contains *this* message and which was cited > in Maciej's call for vote Same thing applies, since they both have the same shortcomings. Again, you proved my point that people dont fully read threads, when given a reference to them. > In principle nothing, except that IMO this is a desultory diversion: we > discussed the subject during 10 days,[.....]. It's a > clear testbed case for the processes which govern our community. So, > lets try to do it without endless discussion about how. Yes, I completely agree, this is a good testbed case for the process. It is a testbed as to whether OpenCSW is going to continue forward as a fair, democratic organization, or one where voices in opposition to board members, are locked out of the voting process. _I'm not looking for further discussion_. I'd like to see a vote; one in which both sides get a fair voice on the ballot. You said there is "nothing wrong" with my proposal in drawing up ballot descriptions, so lets move forward with it, unless there are any other objections? There is no reason that this will significantly 'delay' anything, since there is no need for further back-and-forth discussion. That is another reason why I specified that each side gets exclusive control over their side of the writeup, baring factual errors: To eliminate delays in voting. Unless Maciej is feeling particularly slow in writing up "his" side, I see no reason that a vote could not be started in 24 hours from now. I can certainly have my side written within that period of time. Mr. Secretary, what say you? From gadavis at opencsw.org Fri Feb 25 04:55:20 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Thu, 24 Feb 2011 19:55:20 -0800 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: <4D672828.2090906@opencsw.org> Phil, I'm inclined to agree with you that the pros and cons should be summarized neatly rather than forcing people to dig into the mailing list. However, I don't think it's necessary to recall the current ballot as it stands for a simple matter such as this one. I just re-read this entire thread, and the pro and con list is very short. Perhaps a wiki page should be put together for this vote with the pro and cons of the argument - I certainly don't see the harm in it. Since people have 6 whole days to vote, there is no reason to cancel the ballot, especially since people can change their minds up until the end of the election. Elections such as this are (at least from what I can tell from a year plus of lurking) a relatively new procedure for this group, and there are bound to be kinks in the process while it gets shaken out. ---- Now, with that out of the way, I'd like to make a more personal statement. I don't have a horse in this particular race (the -dev versus -devel issue), so please don't take this as me siding with the board in some sort of witch-hunt against you. You strike me as a very smart person who cares about the quality of the project. However, as a new maintainer, seeing how you interact with others on this list is incredibly off-putting and makes me less inclined to contribute to the project. Unfortunately, you have this habit of stalling discussions out with a slow trickle of objections over what in the end are often minor issues. I realize that you're trying to improve things, but it really comes off in an extremely negative fashion. I realize that your posts don't exist in a vacuum - there are others on this list that are combative and sometimes downright rude. However, none of them post as much as you do. Since you are a proponent of providing a summary for ballots, please also consider providing a summary of your objections at the beginning of a discussion so that others can see the entirety of your point of view at once, and perhaps let the small stuff go. Otherwise, it just looks like you are trying to kill the discussion with a thousand cuts. On 2/24/2011 2:36 PM, Philip Brown wrote: > On 2/24/11, Peter FELECAN wrote: >> Philip Brown writes: >> >>> ironically, I think you just proved my point, "people wont read the >>> thread". Because if you had (re?)read the whole thread rather than >>> just the first article, you would already know my viewpoint on >>> Dagobert's summary. >> You misunderstood my remark: I referred to the message at the head of >> *this* thread, the one that contains *this* message and which was cited >> in Maciej's call for vote > Same thing applies, since they both have the same shortcomings. > Again, you proved my point that people dont fully read threads, when > given a reference to them. > > >> In principle nothing, except that IMO this is a desultory diversion: we >> discussed the subject during 10 days,[.....]. It's a >> clear testbed case for the processes which govern our community. So, >> lets try to do it without endless discussion about how. > Yes, I completely agree, this is a good testbed case for the process. > It is a testbed as to whether OpenCSW is going to continue forward as > a fair, democratic organization, or one where voices in opposition to > board members, are locked out of the voting process. > > _I'm not looking for further discussion_. I'd like to see a vote; one > in which both sides get a fair voice on the ballot. > > You said there is "nothing wrong" with my proposal in drawing up > ballot descriptions, so lets move forward with it, unless there are > any other objections? > There is no reason that this will significantly 'delay' anything, > since there is no need for further back-and-forth discussion. That is > another reason why I specified that each side gets exclusive control > over their side of the writeup, baring factual errors: To eliminate > delays in voting. > Unless Maciej is feeling particularly slow in writing up "his" side, I > see no reason that a vote could not be started in 24 hours from now. I > can certainly have my side written within that period of time. > > Mr. Secretary, what say you? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From gadavis at opencsw.org Fri Feb 25 07:14:58 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Thu, 24 Feb 2011 22:14:58 -0800 Subject: [csw-maintainers] FreeRADIUS and it's baroque configuration Message-ID: <4D6748E2.9080408@opencsw.org> Hi all, I'm wondering if I can get a little advice on how best to handle the FreeRADIUS package. This package has been abandoned, and there are quite a few requests for a version bump. I've got a new set of packages sitting in experimental, but I'm battling it's baroque configuration files. FreeRADIUS is similar in complexity to Apache - there are a ton of ways to configure it, and no one site is going to do it the same way. The source archive includes a complicated initial configuration, which was evidently written by multiple people. It's huge: 109 separate files in this example configuration, plus 8 symlinks. It uses two different methods for enabling and disabling functionality. There is a sites-available/sites-enabled approach like Apache, which plays ok with CSWpreserveconf. The other method is far more traditional directory containing various modules, without an easy way to enable/disable them. CSWpreserveconf doesn't like this setup at all and puts in a bunch of foo and foo.CSW files, which results in the configuration for "foo" getting effectively included twice. Since this package is complex to configure, the example configuration is ridiculously huge, and I'm not quite sure what a default use case for it would be, I'm tempted to just ship it without a working configuration at all, and let the user copy the example configuration down from /opt/csw/share/doc/CSWfreeradius/exampleconf or something similar. Is shipping this package with an example config not installed in /etc/opt/csw OK to do? I seem to remember seeing a document on the wiki somewhere claming something to that effect - probably one of the auto-start daemon options, but no real formal guidance. From phil at bolthole.com Fri Feb 25 15:30:49 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 25 Feb 2011 06:30:49 -0800 Subject: [csw-maintainers] FreeRADIUS and it's baroque configuration In-Reply-To: <4D6748E2.9080408@opencsw.org> References: <4D6748E2.9080408@opencsw.org> Message-ID: >Is shipping this package with an example >config not installed in /etc/opt/csw OK to do? yes I think so From phil at bolthole.com Fri Feb 25 15:50:00 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 25 Feb 2011 06:50:00 -0800 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: <4D672828.2090906@opencsw.org> References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> <4D672828.2090906@opencsw.org> Message-ID: On Thu, Feb 24, 2011 at 7:55 PM, Geoff Davis wrote: > Phil, > > I'm inclined to agree with you that the pros and cons should be summarized > neatly rather than forcing people to dig into the mailing list. However, I > don't think it's necessary to recall the current ballot as it stands for a > simple matter such as this one. I just re-read this entire thread, and the > pro and con list is very short. yes, it is only a small amount of things. Shouldnt that be an argument in *favor* for "hey, its easy to fix, so lets do it quickly and move on"? I just want to make sure that the ballot shows the effective work impact of each way. 6 vs 120 packages long time to converge, vs short. (days vs months!) Perhaps a wiki page should be put together for this vote with the pro and > cons of the argument - I certainly don't see the harm in it. Since people > have 6 whole days to vote, there is no reason to cancel the ballot, > especially since people can change their minds up until the end of the > election. > well, this isnt a matter of "cancelling", since the "vote" has not officially started yet. I'd like this to be resolved, and start voting! :) > > Since you are a proponent of providing a summary for ballots, please also > consider providing a summary of your objections at the beginning of a > discussion so that others can see the entirety of your point of view at > once, and perhaps let the small stuff go. Otherwise, it just looks like you > are trying to kill the discussion with a thousand cuts. > > I will certainly try. At the same time, I hope its understandable that I'm not omniscient, so I dont see all possible issues at once myself! :-} -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Fri Feb 25 16:03:19 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 25 Feb 2011 07:03:19 -0800 Subject: [csw-maintainers] retire ipaudit, or take over by someone? Message-ID: A filename conflict in CSWipaudit has been found, with a newer package. ipaudit is a very old package. Its maintainer has retired. I'm seeing if anyone is interested in taking over the package, (and renaming/moving the conflicting file) or whether we should just remove it from the catalog. It seems like a useful package, but it has not had an update upstream in years, either. "IPAudit can be used to monitor network activity for a variety of purposes. It has proved useful for monitoring intrusion detection, bandwith consumption and denial of service attacks. It can be used with?IPAudit-Web?to provide web based network reports." http://ipaudit.sourceforge.net/ From maciej at opencsw.org Fri Feb 25 17:39:47 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 25 Feb 2011 16:39:47 +0000 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: 2011/2/24 Philip Brown : > On 2/24/11, Maciej Blizi?ski wrote: >> ?I'm inclined to do no writeup whatsoever, and only >> include a link to this thread: >> >> http://lists.opencsw.org/pipermail/maintainers/2011-February/014148.html >> > > which will ensure that some people will not read it. > There is a solution to this; I already proposed it in a thread a while > back, but I'll repeat it. > have one person from "each side", do a part of the writeup. > This is a standard real-world methodology for ballots in some places. > > Each "side" gets complete control over their part of the writeup. > There should only be editorial fiddling, if either one side gives > *factually incorrect* statements, or it is just ludicrously long. (3x > the length of the other side, or something) Yes we can do that. If you give me the URL of the writeup, I'll send it out from the ballotbin website. Maciej From phil at bolthole.com Fri Feb 25 19:19:26 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 25 Feb 2011 10:19:26 -0800 Subject: [csw-maintainers] Call for vote: -dev vs. -devel In-Reply-To: References: <8AC14329-8E93-4717-AFD7-F4E088C62069@opencsw.org> Message-ID: 2011/2/25 Maciej Blizi?ski : > 2011/2/24 Philip Brown : >>... >> >> Each "side" gets complete control over their part of the writeup. >> There should only be editorial fiddling, if either one side gives >> *factually incorrect* statements, or it is just ludicrously long. (3x >> the length of the other side, or something) > > Yes we can do that. ?If you give me the URL of the writeup, I'll send > it out from the ballotbin website. Great! Thank you for being flexible. generally speaking, I dont think it's a good idea to provide "a url" for the actual ballot; I think that both writeups need to be fixed when the vote starts. having things potentially change mid-vote seems to be inappropriate. Additionally, I think it is fairest that both sides, get to see what the other side is writing, at least once, before the vote starts. My side is pretty short; its basically a synopsys of one of my prior emails, in the thread you referenced. As requested, I have put it on a URL: http://www.bolthole.com/devel.txt I would suggest that you cut-n-paste it, plus your side, and the overall ballot wording, into the wiki somewheres, for a last minute glance-over by all who care about it, and then we can shortly proceed to the actual vote? From bwalton at opencsw.org Sat Feb 26 02:05:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Feb 2011 20:05:20 -0500 Subject: [csw-maintainers] GPG Key Vote In-Reply-To: <1298129678-sup-6465@pinkfloyd.chass.utoronto.ca> References: <1298129678-sup-6465@pinkfloyd.chass.utoronto.ca> Message-ID: <1298682151-sup-9235@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sat Feb 19 10:43:18 -0500 2011: Hi All, I'm back in the great white north and starting to slog through my inbox. As this is an item that's been delayed by my travels and the camp, etc, it's time to move on it. After a quick (California) civics lesson from Geoff in irc today, I understand that what Phil is attempting to push through with his 'fair write ups' thing is similar to what elections in California do. This is certainly different than what I've ever experienced and I'm sure other non-American folks may find it peculiar too (maybe not?). I still find this a bit odd as it's likely having a partisan party in the booth with you, I don't mind a pro/con list as long as it's not directly in the ballot text. So, the ballotbin vote will be binary choices with 'no frills' descriptions. The write up will be on a wiki page[1] and can list pros/cons. It will be linked from the ballotbin vote but not directly included. The vote choices will still be one per board position with a fourth question asking whether the key should be held in escrow or directly. This vote is for the _current_ gpg key. At camp, we came up with a much better solution to this whole thing but it will take time to implement properly, so it's still useful to decide on the handling of the current asset. Phil: You've got 24 hours to edit the wiki page. We're not doing a point/rebuttal system though. Keep it to bullet points. Maciej: Will you please run the vote starting anytime after midnight UTC on the 27th unless there is something obviously wrong with the wiki page at that time. Thanks -Ben [1] http://wiki.opencsw.org/vote-gpgkey -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Feb 26 02:12:28 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Feb 2011 20:12:28 -0500 Subject: [csw-maintainers] FreeRADIUS and it's baroque configuration In-Reply-To: References: <4D6748E2.9080408@opencsw.org> Message-ID: <1298682555-sup-3090@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Feb 25 09:30:49 -0500 2011: > >Is shipping this package with an example >config not installed in > >/etc/opt/csw OK to do? > yes I think so For a beast like freeradius, that's not a bad option. The current package looks to only ship sample config files too unless it does something via postinstall, etc. So this won't even be a radical change. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From gadavis at opencsw.org Sat Feb 26 02:19:15 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Fri, 25 Feb 2011 17:19:15 -0800 Subject: [csw-maintainers] FreeRADIUS and it's baroque configuration In-Reply-To: <1298682555-sup-3090@pinkfloyd.chass.utoronto.ca> References: <4D6748E2.9080408@opencsw.org> <1298682555-sup-3090@pinkfloyd.chass.utoronto.ca> Message-ID: OK thanks Ben and Phil. This should simplify my Makefile by a factor of about 30 lines. On Feb 25, 2011, at 5:12 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Feb 25 09:30:49 -0500 > 2011: > >>> Is shipping this package with an example >config not installed in >>> /etc/opt/csw OK to do? > >> yes I think so > > For a beast like freeradius, that's not a bad option. The current > package looks to only ship sample config files too unless it does > something via postinstall, etc. So this won't even be a radical > change. > > 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 phil at bolthole.com Sat Feb 26 06:47:14 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 25 Feb 2011 21:47:14 -0800 Subject: [csw-maintainers] GPG Key Vote In-Reply-To: <1298682151-sup-9235@pinkfloyd.chass.utoronto.ca> References: <1298129678-sup-6465@pinkfloyd.chass.utoronto.ca> <1298682151-sup-9235@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Feb 25, 2011 at 5:05 PM, Ben Walton wrote: >... > The vote choices will still be one per board position with a fourth > question asking whether the key should be held in escrow or directly. > > This vote is for the _current_ gpg key. ?At camp, we came up with a > much better solution to this whole thing but it will take time to > implement properly, so it's still useful to decide on the handling of > the current asset. > > Phil: You've got 24 hours to edit the wiki page. ?We're not doing a > ? ? ?point/rebuttal system though. ?Keep it to bullet points. Thank you. Not quite sure what you meant about "not doing a point/rebuttal system", but I tried to basically stick to the format you already laid out, and kept it brief. Strictly speaking, I think there are some factual errors in what you wrote, but since what I wrote mostly counterbalances them.. and in the interest of showing I can actually let some things slide :) I am okay with the writeup as it now stands. > [1] http://wiki.opencsw.org/vote-gpgkey A comment on what you also wrote: >. ?This > is certainly different than what I've ever experienced and I'm sure > other non-American folks may find it peculiar too (maybe not?). ?I > still find this a bit odd as it's likely having a partisan party in > the booth with you, I don't mind a pro/con list as long as it's not > directly in the ballot text. > > So, the ballotbin vote will be binary choices with 'no frills' > descriptions. ?The write up will be on a wiki page[1] and can list > pros/cons. ?It will be linked from the ballotbin vote but not directly > included. I'm not understanding your objection to putting the writeup directly in the ballotbin writeup. It's fairly short. I gather this is not what you are used to seeing, in your local/state/government elections; but that venue has a hinderance on it, that we do not have. What you see there, is probably for ease of tallying, to have one small "voting sheet" or whatever, handed around for vote tallying. It is expected to have multiple issues voted on, in one sheet. so space is at a premium? In contrast, our ballot is a "one issue" ballot. There's no real bonus to exclude it.. and technically, it is less efficient/makes the voter do more work, to have them click to a separate page, and then come back to "the voting page". From pfelecan at opencsw.org Sat Feb 26 10:50:49 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 26 Feb 2011 10:50:49 +0100 Subject: [csw-maintainers] Web main page Message-ID: I read the new main page and I like it. At least its upper half: the counters are better in their new position. However, the 2 section in the bottom half: "Latest news" and "Releases and updates" are ridiculously outdated. Is it not better to remove them than to give the impression that there is no news, releases or updates since August or September of the last year, which is contrary to what is in the upper left half of the page? -- Peter From pfelecan at opencsw.org Sat Feb 26 11:14:36 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 26 Feb 2011 11:14:36 +0100 Subject: [csw-maintainers] maintainer summary page Message-ID: Looking up my summary page at: http://www.opencsw.org/buglist/maintainer.cgi?maintainer=%27pfelecan%27 I observe that the summary section is not sorted by package contrary of the details section. The sorting criteria of the summary section is a concept of "points" which is not explained. I'm very curious of the equation computing the points... -- Peter From dam at opencsw.org Sat Feb 26 11:51:05 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 26 Feb 2011 11:51:05 +0100 Subject: [csw-maintainers] maintainer summary page In-Reply-To: References: Message-ID: <1285447C-03E7-46C1-A775-0101286DCA84@opencsw.org> Hi Peter, Am 26.02.2011 um 11:14 schrieb Peter FELECAN: > Looking up my summary page at: > http://www.opencsw.org/buglist/maintainer.cgi?maintainer=%27pfelecan%27 > I observe that the summary section is not sorted by package contrary of > the details section. > > The sorting criteria of the summary section is a concept of "points" > which is not explained. I'm very curious of the equation computing > the points... Unfortunately this is only explained on the summary page I hacked together some time ago: http://www.opencsw.org/buglist/buglist.cgi The points are calculated as [severity] * [weight] with Feature -> 1, Trivial -> 10, Text -> 10, Tweak -> 10, Minor -> 10, Major -> 20, Crash -> 20, Block -> 20, and New -> 10, Feedback -> 1, Acknowledged -> 5, Confirmed -> 3, Assigned -> 7, Resolved -> 0, Closed -> 0, It is meant just as a metric for sorting important things first. William: Maybe the information could better be added to the maintainer qa-page? Best regards -- Dago From pfelecan at opencsw.org Sat Feb 26 12:17:53 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 26 Feb 2011 12:17:53 +0100 Subject: [csw-maintainers] maintainer summary page In-Reply-To: <1285447C-03E7-46C1-A775-0101286DCA84@opencsw.org> (Dagobert Michelsen's message of "Sat, 26 Feb 2011 11:51:05 +0100") References: <1285447C-03E7-46C1-A775-0101286DCA84@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 26.02.2011 um 11:14 schrieb Peter FELECAN: >> Looking up my summary page at: >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=%27pfelecan%27 >> I observe that the summary section is not sorted by package contrary of >> the details section. >> >> The sorting criteria of the summary section is a concept of "points" >> which is not explained. I'm very curious of the equation computing >> the points... > > Unfortunately this is only explained on the summary page I hacked > together some time ago: > http://www.opencsw.org/buglist/buglist.cgi > > The points are calculated as [severity] * [weight] with > Feature -> 1, Trivial -> 10, Text -> 10, Tweak -> 10, Minor -> 10, Major -> 20, Crash -> 20, Block -> 20, > and > New -> 10, Feedback -> 1, Acknowledged -> 5, Confirmed -> 3, Assigned -> 7, Resolved -> 0, Closed -> 0, > > It is meant just as a metric for sorting important things first. Thank you. So this can be considered as a qualitative heuristic? It could be used for transiting a package from unstable to testing and from testing to stable. > William: Maybe the information could better be added to the maintainer > qa-page? At least, a reference to the explanation page can be given. No need to replicate the information on each page. For example, the header of the summary table can be a hyperlink toward the explanation page. -- Peter From william at wbonnet.net Sat Feb 26 22:42:07 2011 From: william at wbonnet.net (William Bonnet) Date: Sat, 26 Feb 2011 22:42:07 +0100 Subject: [csw-maintainers] Web main page In-Reply-To: References: Message-ID: <4D6973AF.50103@wbonnet.net> Hi > I read the new main page and I like it. At least its upper half: the > counters are better in their new position. However, the 2 section in the > bottom half: "Latest news" and "Releases and updates" are ridiculously > outdated. Is it not better to remove them than to give the impression > that there is no news, releases or updates since August or September of > the last year, which is contrary to what is in the upper left half of > the page? In the next days, releases and update will be generated automagically from the QA database. Latests news is more difficult. We have to do this. I think a message per week about the latest event would be enough. As example, we could post the vote results. I propose to try over March. If it is not working, we can change it. cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From pfelecan at opencsw.org Sun Feb 27 08:24:47 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 27 Feb 2011 08:24:47 +0100 Subject: [csw-maintainers] Web main page In-Reply-To: <4D6973AF.50103@wbonnet.net> (William Bonnet's message of "Sat, 26 Feb 2011 22:42:07 +0100") References: <4D6973AF.50103@wbonnet.net> Message-ID: William Bonnet writes: > Hi > >> I read the new main page and I like it. At least its upper half: the >> counters are better in their new position. However, the 2 section in the >> bottom half: "Latest news" and "Releases and updates" are ridiculously >> outdated. Is it not better to remove them than to give the impression >> that there is no news, releases or updates since August or September of >> the last year, which is contrary to what is in the upper left half of >> the page? > In the next days, releases and update will be generated automagically > from the QA database. > > Latests news is more difficult. We have to do this. I think a message > per week about the latest event would be enough. As example, we could > post the vote results. If there is not somebody or something in charge of generating the "latest news" it is not worthwhile. > I propose to try over March. If it is not working, we can change it. This can work until you are doing it. After, it will be again outdated. -- Peter From ihsan at opencsw.org Sun Feb 27 11:58:24 2011 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sun, 27 Feb 2011 11:58:24 +0100 Subject: [csw-maintainers] Website and mailing lists outage Message-ID: <4D6A2E50.2030901@opencsw.org> Dear OpenCSW users, The University of Applied Sciences in Biel (Switzerland) [1] hosted and provided the bandwidth for the web and mail server of the OpenCSW project since the beginnings. Unfortunately, the university cannot sponsor the OpenCSW project any longer and we were forced to look for a new solution. Solnet [2], an ISP based in Solothurn (Switzerland), is so kind and is going to sponsor hosting and internet connectivity for the OpenCSW project. The mail and web server will be moved to their data center on Monday, the 28th February 2010. Following services will be not available on Monday 28th February, from 9:00 UTC till 14:00 UTC: - The project website and bug tracker on www.opencsw.org - www-mockup.opencsw.org - Mailing lists - opencsw.org mail services Not affected by this outage is: - The buildfarm at Baltic Online (login.bo.opencsw.org) - wiki.opencsw.org [1] http://www.hti.bfh.ch/ [2] http://www.solnet.ch/ Thanks for your patience, Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Sun Feb 27 14:05:32 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 27 Feb 2011 08:05:32 -0500 Subject: [csw-maintainers] Web main page In-Reply-To: References: <4D6973AF.50103@wbonnet.net> Message-ID: <1298811832-sup-9242@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sun Feb 27 02:24:47 -0500 2011: > > Latests news is more difficult. We have to do this. I think a message > > per week about the latest event would be enough. As example, we could > > post the vote results. > > If there is not somebody or something in charge of generating the "latest > news" it is not worthwhile. Why don't several of us simply add news items as noteworthy things happen? Updates to packages in our 'core' set, changes in process, new feature additions to GAR, etc. It should only take a few minutes, and if the load is distributed, it won't take much effort from any one person... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Sun Feb 27 15:00:44 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 27 Feb 2011 15:00:44 +0100 Subject: [csw-maintainers] Web main page In-Reply-To: <1298811832-sup-9242@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Sun, 27 Feb 2011 08:05:32 -0500") References: <4D6973AF.50103@wbonnet.net> <1298811832-sup-9242@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Peter FELECAN's message of Sun Feb 27 02:24:47 -0500 2011: > >> > Latests news is more difficult. We have to do this. I think a message >> > per week about the latest event would be enough. As example, we could >> > post the vote results. >> >> If there is not somebody or something in charge of generating the "latest >> news" it is not worthwhile. > > Why don't several of us simply add news items as noteworthy things > happen? Updates to packages in our 'core' set, changes in process, > new feature additions to GAR, etc. It should only take a few minutes, > and if the load is distributed, it won't take much effort from any one > person... Beside people willing to do it, we need people knowing how to do it... for that to happen, the process of news publication must be documented. AFAIK, that is not the case today. -- Peter From bwalton at opencsw.org Sun Feb 27 15:09:06 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 27 Feb 2011 09:09:06 -0500 Subject: [csw-maintainers] Web main page In-Reply-To: References: <4D6973AF.50103@wbonnet.net> <1298811832-sup-9242@pinkfloyd.chass.utoronto.ca> Message-ID: <1298815718-sup-4228@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sun Feb 27 09:00:44 -0500 2011: > Beside people willing to do it, we need people knowing how to do > it... for that to happen, the process of news publication must be > documented. AFAIK, that is not the case today. A fair point, but easily overcome. If that's our only obstacle, we're in good shape, I think. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From william at wbonnet.net Sun Feb 27 18:02:24 2011 From: william at wbonnet.net (William Bonnet) Date: Sun, 27 Feb 2011 18:02:24 +0100 Subject: [csw-maintainers] Web main page In-Reply-To: <1298811832-sup-9242@pinkfloyd.chass.utoronto.ca> References: <4D6973AF.50103@wbonnet.net> <1298811832-sup-9242@pinkfloyd.chass.utoronto.ca> Message-ID: <4D6A83A0.6070202@wbonnet.net> Hi > Why don't several of us simply add news items as noteworthy things > happen? Updates to packages in our 'core' set, changes in process, > new feature additions to GAR, etc. It should only take a few minutes, > and if the load is distributed, it won't take much effort from any one > person... That's a good idea. If you are not familiar with Wordpress, then i can do the input work. We can try to setup a way to select new, and push news add requests. We don't need much information, just update on a regular basis. One per week would be sufficient. cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From pfelecan at opencsw.org Sun Feb 27 18:33:38 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 27 Feb 2011 18:33:38 +0100 Subject: [csw-maintainers] Web main page In-Reply-To: <4D6A83A0.6070202@wbonnet.net> (William Bonnet's message of "Sun, 27 Feb 2011 18:02:24 +0100") References: <4D6973AF.50103@wbonnet.net> <1298811832-sup-9242@pinkfloyd.chass.utoronto.ca> <4D6A83A0.6070202@wbonnet.net> Message-ID: William Bonnet writes: > Hi > >> Why don't several of us simply add news items as noteworthy things >> happen? Updates to packages in our 'core' set, changes in process, >> new feature additions to GAR, etc. It should only take a few minutes, >> and if the load is distributed, it won't take much effort from any one >> person... > That's a good idea. > > If you are not familiar with Wordpress, then i can do the input work. We > can try to setup a way to select new, and push news add requests. We > don't need much information, just update on a regular basis. One per > week would be sufficient. It's not a question of familiarity with WordPress per see, but how to do it with our instance. A brief document would be welcome. -- Peter From a.cervellin at acm.org Mon Feb 28 11:28:52 2011 From: a.cervellin at acm.org (Alessio) Date: Mon, 28 Feb 2011 11:28:52 +0100 Subject: [csw-maintainers] website problem In-Reply-To: References: <4D6973AF.50103@wbonnet.net> <1298811832-sup-9242@pinkfloyd.chass.utoronto.ca> <4D6A83A0.6070202@wbonnet.net> Message-ID: <4D6B78E4.7050201@acm.org> Hi, today I'm not able to access to www.opencsw.org. Is there any problem or scheduled maintenance? alessio From bonivart at opencsw.org Mon Feb 28 18:15:41 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 28 Feb 2011 18:15:41 +0100 Subject: [csw-maintainers] website problem In-Reply-To: <4D6B78E4.7050201@acm.org> References: <4D6973AF.50103@wbonnet.net> <1298811832-sup-9242@pinkfloyd.chass.utoronto.ca> <4D6A83A0.6070202@wbonnet.net> <4D6B78E4.7050201@acm.org> Message-ID: On Mon, Feb 28, 2011 at 11:28 AM, Alessio wrote: > Hi, > today I'm not able to access to www.opencsw.org. > Is there any problem or scheduled maintenance? Hi Alessio, yes, there's maintenance since some services are moving. It was announced yesterday: ==> Dear OpenCSW users, The University of Applied Sciences in Biel (Switzerland) [1] hosted and provided the bandwidth for the web and mail server of the OpenCSW project since the beginnings. Unfortunately, the university cannot sponsor the OpenCSW project any longer and we were forced to look for a new solution. Solnet [2], an ISP based in Solothurn (Switzerland), is so kind and is going to sponsor hosting and internet connectivity for the OpenCSW project. The mail and web server will be moved to their data center on Monday, the 28th February 2010. Following services will be not available on Monday 28th February, from 9:00 UTC till 14:00 UTC: - The project website and bug tracker on www.opencsw.org - www-mockup.opencsw.org - Mailing lists - opencsw.org mail services Not affected by this outage is: - The buildfarm at Baltic Online (login.bo.opencsw.org) - wiki.opencsw.org [1] http://www.hti.bfh.ch/ [2] http://www.solnet.ch/ Thanks for your patience, Ihsan <== It's a little overdue though, I hope they will be up soon. Is there something specific you're looking for? Some things can be found in places not affected by this move. /peter From ihsan at opencsw.org Mon Feb 28 18:22:05 2011 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Mon, 28 Feb 2011 18:22:05 +0100 Subject: [csw-maintainers] Website and mailing lists outage In-Reply-To: <4D6A2E50.2030901@opencsw.org> References: <4D6A2E50.2030901@opencsw.org> Message-ID: <4D6BD9BD.4050707@opencsw.org> We are olnine again. Due a broken switch, the outage was slightly longer. Ihsan Am 27.02.2011 11:58, schrieb ?hsan Do?an: > Dear OpenCSW users, > > The University of Applied Sciences in Biel (Switzerland) [1] hosted and > provided the bandwidth for the web and mail server of the OpenCSW > project since the beginnings. Unfortunately, the university cannot > sponsor the OpenCSW project any longer and we were forced to look for a > new solution. > > Solnet [2], an ISP based in Solothurn (Switzerland), is so kind and is > going to sponsor hosting and internet connectivity for the OpenCSW > project. The mail and web server will be moved to their data center on > Monday, the 28th February 2010. > > Following services will be not available on Monday 28th February, from > 9:00 UTC till 14:00 UTC: > - The project website and bug tracker on www.opencsw.org > - www-mockup.opencsw.org > - Mailing lists > - opencsw.org mail services > > Not affected by this outage is: > - The buildfarm at Baltic Online (login.bo.opencsw.org) > - wiki.opencsw.org > > [1] http://www.hti.bfh.ch/ > [2] http://www.solnet.ch/ > > > > Thanks for your patience, > Ihsan > -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Mon Feb 28 20:19:08 2011 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Mon, 28 Feb 2011 20:19:08 +0100 Subject: [csw-maintainers] Website and mailing lists outage In-Reply-To: <4D6BD9BD.4050707@opencsw.org> References: <4D6A2E50.2030901@opencsw.org> <4D6BD9BD.4050707@opencsw.org> Message-ID: <4D6BF52C.3090801@opencsw.org> Am 28.02.2011 18:22, schrieb ?hsan Do?an: > We are olnine again. Due a broken switch, the outage was slightly longer. BTW, does anybody has a 1U managed Cisco switch with 8 ports? :-) Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Mon Feb 28 22:51:19 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 28 Feb 2011 21:51:19 +0000 Subject: [csw-maintainers] Website and mailing lists outage In-Reply-To: <4D6BD9BD.4050707@opencsw.org> References: <4D6A2E50.2030901@opencsw.org> <4D6BD9BD.4050707@opencsw.org> Message-ID: 2011/2/28 ?hsan?Do?an : > We are olnine again. Due a broken switch, the outage was slightly longer. It looks like our mailing list archives are not available at http://lists.opencsw.org. Maciej From phil at opencsw.org Mon Feb 28 23:27:16 2011 From: phil at opencsw.org (Philip Brown) Date: Mon, 28 Feb 2011 14:27:16 -0800 Subject: [csw-maintainers] redundant, and seemingly redundant, packages listed Message-ID: switched from pkgsubmissions to maintainers... 2011/2/28 Maciej Blizi?ski : > 2011/2/28 Philip Brown : >> THanks. apache2c removed in current mirrors >> (change batched, anyways) > > I don't know for sure, but I think the same problem may concern the > following packages: > > CSWpmtt2-common vs CSWpmtt2 hmm. well, pmtt2 is newer, and has better name. but pmtt2-common actually has a dependancy on it, whereas the other does not :( > CSWpy-yaml vs CSWpyyaml removed pyyaml > CSWxproto vs CSWx11xproto Hmm. messy. Seems to be redundant to me. but before just removing, since both are semi-recent one is in gar as pkg/x11/proto/x11 one is pkg/x11/xproto If someone would look into verifyign that gar is "clean", (or making it so) and tell me which one to remove, I will proceed with that. > CSWfirefox-fr vs CSWffox-l10n-fr one is for version 3, one is for version 2. so, not redundant.