From maciej at opencsw.org Thu Jul 1 04:42:42 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 1 Jul 2010 03:42:42 +0100 Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at once In-Reply-To: <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> References: <4C2BA75F.5090003@wbonnet.net> <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 30 de Junho de 2010 21:31, Ben Walton escreveu: > Excerpts from William Bonnet's message of Wed Jun 30 16:21:51 -0400 2010: > > Hi William, > >> Would it be possible to display *all* the missing packages instead >> of outputing the first missing package and exiting ? > > I wonder if we shouldn't just have it look for CSWgar-dev, which > depends on all gar build deps and leave it at that? I think that William had package-specific build time dependencies in mind. As a general approach, I think that we could start offloading bits of functionality from Make to separate executables. For example: gar/bin/build-time-dep-test . The choice would largely depend on language expressiveness. If it's easy to clean to code in Make, fine. If it's not, write a separate tool in a language of choice (shell/Perl/Python) and call it from Make. From phil at bolthole.com Thu Jul 1 04:55:59 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 30 Jun 2010 19:55:59 -0700 Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at once In-Reply-To: References: <4C2BA75F.5090003@wbonnet.net> <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> Message-ID: On Wednesday, June 30, 2010, Maciej (Matchek) Blizinski .... >> I wonder if we shouldn't just have it look for e dependencies in mind. > > As a general approach, I think that we could start offloading bits of > functionality from Make to separate executables. ?For example: > gar/bin/build-time-dep-test . > oh pleease yes! then someday we could make a normal package out of gar. make is very powerfull, but it's not really supposed to be a programming language directly. ( reminds me of the old tech joke; emacs is a fine operating system, but I prefer unix) and please, make it a language that comes with a standard solaris core install From william at wbonnet.net Thu Jul 1 10:14:29 2010 From: william at wbonnet.net (William Bonnet) Date: Thu, 1 Jul 2010 10:14:29 +0200 Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at once In-Reply-To: References: <4C2BA75F.5090003@wbonnet.net> <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> Message-ID: <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net> Hi > I think that William had package-specific build time dependencies in mind. In fact i was in front of the following package gmake package pkg A is missing ! sudo pkgutil -y -i A gmake package pkg B is missing ! sudo pkgutil -y -i B gmake package pkg C is missing ! sudo pkgutil -y -i C weellll how much more ? ... it's gonna be a long way until Z ;) since all are defined in the Makefile, i was wishing to have all missing prereqs output at once. even better, to have a target to install all missing prereqs and even much more better, to have both ;) cheers W. From bwalton at opencsw.org Thu Jul 1 14:17:39 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 01 Jul 2010 08:17:39 -0400 Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at once In-Reply-To: <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net> References: <4C2BA75F.5090003@wbonnet.net> <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net> Message-ID: <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> Excerpts from William Bonnet's message of Thu Jul 01 04:14:29 -0400 2010: Hi William, > since all are defined in the Makefile, i was wishing to have all > missing prereqs output at once. I just added check_for_deps to gar/bin. It's perl script (sorry Phil, no ksh! :) ). The attached patch will, I think, integrate it properly. Can someone test the patch before I commit? It works here... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- next part -------------- A non-text attachment was scrubbed... Name: check_for_deps.patch Type: application/octet-stream Size: 1593 bytes Desc: not available URL: From bonivart at opencsw.org Thu Jul 1 14:27:25 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 1 Jul 2010 14:27:25 +0200 Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at once In-Reply-To: <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> References: <4C2BA75F.5090003@wbonnet.net> <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net> <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Jul 1, 2010 at 2:17 PM, Ben Walton wrote: > Excerpts from William Bonnet's message of Thu Jul 01 04:14:29 -0400 2010: > > Hi William, > >> since all are defined in the Makefile, i was wishing to have all >> missing prereqs output at once. > > I just added check_for_deps to gar/bin. ?It's perl script (sorry Phil, > no ksh! :) ). ?The attached patch will, I think, integrate it > properly. > > Can someone test the patch before I commit? ?It works here... Seems to work here as well: bonivart at current9x[trunk]$ gmake update [===== NOW BUILDING: tnef-1.4.7 =====] ginstall -d work/solaris9-i386/cookies/global ginstall -d work/solaris9-i386/download ginstall -d work/solaris9-i386/download/partial ==> Verifying installed package CSWxz: ok ==> Verifying installed package CSWbzip2: ok ==> Verifying installed package CSWdiffutils: ok ==> Verifying installed package CSWfindutils: ok ==> Verifying installed package CSWgawk: ok ==> Verifying installed package CSWgfile: ok ==> Verifying installed package CSWggrep: ok ==> Verifying installed package CSWgmake: ok ==> Verifying installed package CSWgsed: ok ==> Verifying installed package CSWgtar: ok ==> Verifying installed package CSWpy-cheetah: ok ==> Verifying installed package CSWpy-hachoir-core: ok ==> Verifying installed package CSWpy-hachoir-parser: ok ==> Verifying installed package CSWpy-libmagic: ok ==> Verifying installed package CSWpy-progressbar: ok ==> Verifying installed package CSWpy-sqlobject: ok ==> Verifying installed package CSWpy-yaml: ok ==> Verifying installed package CSWpython: ok ==> Verifying installed package CSWcoreutils: ok ==> Verifying installed package CSWwget: ok ==> Verifying installed package CSWgit: ok [prerequisite] complete for tnef. -- /peter From phil at bolthole.com Thu Jul 1 15:13:43 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 1 Jul 2010 06:13:43 -0700 Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at once In-Reply-To: <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> References: <4C2BA75F.5090003@wbonnet.net> <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net> <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> Message-ID: perl is in standard core solaris install now, so I'm happy with the choice :) On Thursday, July 1, 2010, Ben Walton wrote: > Excerpts from William Bonnet's message of Thu Jul 01 04:14:29 -0400 2010: > > Hi William, > >> since all are defined in the Makefile, i was wishing to have all >> missing prereqs output at once. > > I just added check_for_deps to gar/bin. ?It's perl script (sorry Phil, > no ksh! :) ). ?The attached patch will, I think, integrate it > properly. > From phil at bolthole.com Thu Jul 1 18:04:53 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 1 Jul 2010 09:04:53 -0700 Subject: [csw-maintainers] A question of naming, in our svn repository In-Reply-To: <4A430357-19CF-45CB-BB99-5F8E378E0A6A@opencsw.org> References: <9337133B-BD50-4A68-B261-2E3F2BCC779B@opencsw.org> <8FB41058-6BD3-4589-88CA-ED3C3CD349FE@opencsw.org> <4A430357-19CF-45CB-BB99-5F8E378E0A6A@opencsw.org> Message-ID: On Tue, Jun 29, 2010 at 11:28 PM, Dagobert Michelsen wrote: > ... > You see what patches and options the previous maintainer used and then make > a GAR recipe with similar options :-) I am currently struggling to rebuild > x3270 against an updated libicu and my package looks different from the > existing one - and there is no recipe for me to look at at all. > > So my prior comment still stands: the packages associated with those dirs, were not made directly from those files. (through gar, anyways). Reguardless, I take it then, that you dont object to renaming xx-yyy to xx_yyy to match catalog names, so I will do that when I come across it while building packages. From phil at bolthole.com Thu Jul 1 18:53:22 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 1 Jul 2010 09:53:22 -0700 Subject: [csw-maintainers] Define supported use cases and work from there In-Reply-To: References: Message-ID: Sorry for the late reply... On Sat, Jun 26, 2010 at 8:57 AM, Peter Bonivart wrote: > On Sat, Jun 26, 2010 at 5:53 PM, Philip Brown wrote: >> On Saturday, June 26, 2010, Peter Bonivart wrote: >> .... >>> I suggest that we define which use cases we should support and in >>> which priority. >> >> You make it sound as though this was not previously defined. But it >> has already been defined, and documented, for over 4 years, >> approximately.... > Is this documentet? Where? Should we support client utilities only or > full server daemons? The following references existed on the old website for a long time, so please ignore the apparent "newness" of the urls: http://www.opencsw.org/use-it/ "For the most part, they are suitable for deployment both locally, and on an NFS-shared filesystem. Packages usually install their software under /opt/csw" http://www.opencsw.org/use-it/sharing-optcsw/ "The comments on this page are targetted towards sharing /opt/csw read-only between multiple machines, or between zones." There are more. I trust I dont have to dig up more documentation references for you though? > > Maybe someone else than you should come forward for those "big > enterprises" using NFS since I can only remember you promoting them. > I've never seen any active maintainer other than you be interested in > this use case. There was one other maintainer who was, for quite a while, using a deployment strategy essentially identical to "shared read-only NFS". His site was using replication across thousands of machines. Dont remember his name though. As a matter of principle, though, it shouldnt matter that it is "only one maintainer" concerned about an issue. Doesnt matter if it's me, or someone else. If "one maintainer" is concerned about an issue that impacts his site, and I personaly dont care about it, i still try to look for solutions to it. Just like in the field of QA and bug reporting, where 1 bug report represents 100 silent users with the same problem; 1 maintainer potentially represents 100 other sysadmins in the same situation. > However, it's about more cases than the dreaded NFS. yes, quite. as I just mentioned above. it also covers replication, and cross zone deployment strategies of, "mount this, but I dont want to deal with the overhead of pkg-inherit garbage for 10 zones". To use one of our competitors as an example: Someone may choose to share a /usr/local read-only, populated via sunfreeware packages. They may share it via nfs, or replication, or zone machine as mentioned above. THEIR packages will not suffer degredation via this method. (any more than they already are, anyway ;-) I'd like to ensure our packages can do just as well in that sort of situation. I'll also point out that in the non-NFS cases, the argument about "you shouldnt run demons from NFS anyway" does not apply. The http://www.opencsw.org/use-it/sharing-optcsw/ mentioned above, explicitly attempts to remind both users and maintainers, of issues relating to this sort of deployment. If you have suggestions to make this stuff better visible to maintainers, please speak up. From dam at opencsw.org Thu Jul 1 19:03:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Jul 2010 19:03:12 +0200 Subject: [csw-maintainers] A question of naming, in our svn repository In-Reply-To: References: <9337133B-BD50-4A68-B261-2E3F2BCC779B@opencsw.org> <8FB41058-6BD3-4589-88CA-ED3C3CD349FE@opencsw.org> <4A430357-19CF-45CB-BB99-5F8E378E0A6A@opencsw.org> Message-ID: <3D46CE61-65EE-431B-A0F9-671D3A905454@opencsw.org> Hi Phil, Am 01.07.2010 um 18:04 schrieb Philip Brown: > On Tue, Jun 29, 2010 at 11:28 PM, Dagobert Michelsen > wrote: >> ... >> You see what patches and options the previous maintainer used and >> then make >> a GAR recipe with similar options :-) I am currently struggling to >> rebuild >> x3270 against an updated libicu and my package looks different from >> the >> existing one - and there is no recipe for me to look at at all. > > So my prior comment still stands: the packages associated with those > dirs, were not made directly from those files. (through gar, anyways). Most certainly there were, although I don't know how. The previous maintainer used them. > Reguardless, I take it then, that you dont object to renaming > > xx-yyy to xx_yyy > > to match catalog names, so I will do that when I come across it while > building packages. Sure, please continue. Best regards -- Dago From bonivart at opencsw.org Thu Jul 1 19:09:32 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 1 Jul 2010 19:09:32 +0200 Subject: [csw-maintainers] Define supported use cases and work from there In-Reply-To: References: Message-ID: On Thu, Jul 1, 2010 at 6:53 PM, Philip Brown wrote: > If you have suggestions to make this stuff better visible to > maintainers, please speak up. For me, it's not about making it more visible, it's about removing the "requirement". I wonder how it got there in the first place..? Just because we (as in you?) have documented something, it doesn't mean we should stick to it until hell freezes over. We finally dropped Solaris 8 after all. :-) I'm not asking for better documentation, I'm asking for us to rethink what we want to offer. When was the last time we did that? -- /peter From phil at bolthole.com Thu Jul 1 20:00:09 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 1 Jul 2010 11:00:09 -0700 Subject: [csw-maintainers] Define supported use cases and work from there In-Reply-To: References: Message-ID: On Thu, Jul 1, 2010 at 10:09 AM, Peter Bonivart wrote: > On Thu, Jul 1, 2010 at 6:53 PM, Philip Brown wrote: >> If you have suggestions to make this stuff better visible to >> maintainers, please speak up. > > For me, it's not about making it more visible, it's about removing the > "requirement". I wonder how it got there in the first place..? >.... > I'm not asking for better documentation, I'm asking for us to rethink > what we want to offer. When was the last time we did that? > > -- That's where I thought you were really heading, even though you muddied the waters in your original email by talking about lack of documentation :-) So, you are proposing a change in our existing documented list of what we support. I have now posted some amount of rationale as to WHY we officially support what is currently documented; the sharing of /opt/csw across machines. If you think we should change that, my suggestion is that you write a proper proposal for it. The proposal should ideally contain the following: - An analysis of benefits for the change - An analysis of negatives for the change I'll point out that 'costs' of maintainance for the existing setup are relatively low, for the average maintainer. First of all, 90%+(guesstimate) of our packages are completely non-affected by the issue either way. For the remaining stuff, maintainers just have to follow standards for where to put stuff. If they do that, they dont have to do any extra work at all. The "work" is actually done by the maintainer of the appropriate CSW utility scripts, in gar, cswclassutils, and now also in the "alternatives" implementation. I've handled one of those already: the alternatives implementation. Gar mostly just hands things off to the other scripts. So the remaining chunk is in the cswclassutils scripts. I have already said I will recode the biggest difficulty; the cswinitsmf one. So its unclear to me who is going to lose out by sticking to existing standards, and who is going to benefit, if we changed them? I will also mention an additional negative to change: We have committed, for many years, to support /opt/csw sharing. (even though we've done less than a stellar job of it lately). We also have to consider impact to our credibility, if we decide to revoke it, without even a major polling of our userbase. >Just because we (as in you?) have documented something, it doesn't >mean we should stick to it until hell freezes over. We finally dropped >Solaris 8 after all. :-) The ditching sol8 was not a random, "oh we dont feel like putting in the effort any more" change. It was part of our pre-existing, documented support life cycle, and had been known and published for years. From bwalton at opencsw.org Fri Jul 2 05:04:02 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 01 Jul 2010 23:04:02 -0400 Subject: [csw-maintainers] cswutils in experimental/bwalton Message-ID: <1278039796-sup-7331@pinkfloyd.chass.utoronto.ca> Hi All, I've placed an update of cswutils in my experimental catalog. This update included the checkpkg path issue as well as a few other fixes from Phil. If nobody gripes in the next few days, I'll push it for release. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Fri Jul 2 18:09:43 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 2 Jul 2010 18:09:43 +0200 Subject: [csw-maintainers] Define supported use cases and work from there In-Reply-To: References: Message-ID: On Thu, Jul 1, 2010 at 8:00 PM, Philip Brown wrote: > So, you are proposing a change in our existing documented list of what > we support. I'm not proposing to change what we support based on what _I_ think. What I am asking is what the community (read: maintainers) think we should support. From scratch, not tweaking what you and Dennis wrote in 2002. If we come up with the same, then fine. At least it's a community decision then. -- /peter From maciej at opencsw.org Sat Jul 3 13:13:56 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 3 Jul 2010 12:13:56 +0100 Subject: [csw-maintainers] Architecture-dependency binary placement policy Message-ID: In other words, where to put which kind of binaries. I'm finishing to integrate a binary file parser into checkpkg and would like to come up with a set of rules about the binary placement. Based on previous experience and our the page[1] about architecture optimization, the policy is as follows: - binaries in directories named 'bin', 'lib' and 'libexec' must be either sparcv8 or hardlinks to isaexec - binaries which are non sparcv8 must be placed in a subdirectory named after the architecture, with variants allowed; sparcv8plus binaries can be placed in directories named sparcv8plus, sparcv8plus+vis, or sparcv8plus+vis2 Is this correct? [1] http://www.opencsw.org/extend-it/contribute-packages/build-standards/architecture-optimization-using-isaexec-and-isalist/ From bwalton at opencsw.org Sat Jul 3 17:58:12 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 03 Jul 2010 11:58:12 -0400 Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at once In-Reply-To: References: <4C2BA75F.5090003@wbonnet.net> <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net> <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> Message-ID: <1278172673-sup-152@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Thu Jul 01 08:27:25 -0400 2010: > Seems to work here as well: Thanks Peter! I just committed the change. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sat Jul 3 20:47:26 2010 From: phil at bolthole.com (Philip Brown) Date: Sat, 3 Jul 2010 11:47:26 -0700 Subject: [csw-maintainers] Architecture-dependency binary placement policy In-Reply-To: References: Message-ID: sounds about right On Saturday, July 3, 2010, Maciej (Matchek) Blizinski wrote: > In other words, where to put which kind of binaries. ?I'm finishing to > integrate a binary file parser into checkpkg and would like to come up > with a set of rules about the binary placement. > > Based on previous experience and our the page[1] about architecture > optimization, the policy is as follows: > > - binaries in directories named 'bin', 'lib' and 'libexec' must be > either sparcv8 or hardlinks to isaexec > - binaries which are non sparcv8 must be placed in a subdirectory > named after the architecture, with variants allowed; sparcv8plus > binaries can be placed in directories named sparcv8plus, > sparcv8plus+vis, or sparcv8plus+vis2 > > Is this correct? > > [1] http://www.opencsw.org/extend-it/contribute-packages/build-standards/architecture-optimization-using-isaexec-and-isalist/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From maciej at opencsw.org Sat Jul 3 23:16:20 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 3 Jul 2010 22:16:20 +0100 Subject: [csw-maintainers] checkpkg: New feature, binary architecture vs file placement Message-ID: Dear maintainers, I've pushed[1] a new checkpkg feature: checking binary file architectures and verifying them against directories. It implements our policy described on the website[2], where sparcv8 binaries can be in bin/, lib/ and libexec/, while sparcv8+ and sparcv9 must be in respectively named subdirectories. False positives may occur if binaries reside in non-standard directories. If you encounter any, you can add overrides. However, please notify me about your case, so I can improve checkpkg. To enable the new feature, please update your GAR sources. Maciej [1] http://sourceforge.net/apps/trac/gar/changeset/10410 [2] http://bit.ly/bJOlfZ From phil at bolthole.com Sun Jul 4 00:28:54 2010 From: phil at bolthole.com (Philip Brown) Date: Sat, 3 Jul 2010 15:28:54 -0700 Subject: [csw-maintainers] checkpkg: New feature, binary architecture vs file placement In-Reply-To: References: Message-ID: one will be mysql I think. although theoretically it could be restructured to be compliant On Saturday, July 3, 2010, Maciej (Matchek) Blizinski wrote: > Dear maintainers, > > I've pushed[1] a new checkpkg feature: checking binary file > architectures and verifying them against directories. ?It implements > our policy described on the website[2], where sparcv8 binaries can be > in bin/, lib/ and libexec/, while sparcv8+ and sparcv9 must be in > respectively named subdirectories. > > False positives may occur if binaries reside in non-standard > directories. ?If you encounter any, you can add overrides. ?However, > please notify me about your case, so I can improve checkpkg. > > To enable the new feature, please update your GAR sources. > > Maciej > > [1] http://sourceforge.net/apps/trac/gar/changeset/10410 > [2] http://bit.ly/bJOlfZ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From maciej at opencsw.org Sun Jul 4 15:59:59 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 4 Jul 2010 14:59:59 +0100 Subject: [csw-maintainers] checkpkg: New feature, binary architecture vs file placement In-Reply-To: References: Message-ID: No dia 3 de Julho de 2010 23:28, Philip Brown escreveu: > one will be > mysql I think. > although theoretically it could be restructured to be compliant I'm running checkpkg over the whole catalog to find out what the error reports look like. There are about 980 false positives, I think I'll be able to fix most of them today. Maciej From bonivart at opencsw.org Mon Jul 5 00:11:05 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 5 Jul 2010 00:11:05 +0200 Subject: [csw-maintainers] Error in weekly package summary Message-ID: I just got the weekly announcement mail and it had this in it: "mailscanner:4.78.17.1,REV=2009.10.01 - A Free Anti-Virus and Anti-Spam Filter" That's the old package already released, I have just submitted 4.79 so either that version should be listed or no mailscanner entry at all. -- /peter From bonivart at opencsw.org Mon Jul 5 20:15:30 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 5 Jul 2010 20:15:30 +0200 Subject: [csw-maintainers] /testing milter-greylist Message-ID: Hi, I have built a new version of this greylisting package for Sendmail (and maybe Postfix). It supports both GeoIP and SPF2 to validate the senders. I would appreciate it if someone could help with testing on an actual mail server. All my clients have change stops during the summer so I have only done local tests on vbox. More info about milter-greylist is available here: http://milter-greylist.wikidot.com/. It uses an in-memory db and it's very flexible to configure. You can find the packages here: http://mirror.opencsw.org/experimental.html#bonivart. -- /peter From phil at bolthole.com Mon Jul 5 22:13:29 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Jul 2010 13:13:29 -0700 Subject: [csw-maintainers] Error in weekly package summary In-Reply-To: References: Message-ID: yeah I had halfway put in new one then backed it out when I wrote comments. this gave a false positive for the update scanner. I think new one is in now though? On Sunday, July 4, 2010, Peter Bonivart wrote: > I just got the weekly announcement mail and it had this in it: > > "mailscanner:4.78.17.1,REV=2009.10.01 - A Free Anti-Virus and Anti-Spam Filter" > > That's the old package already released, I have just submitted 4.79 so > either that version should be listed or no mailscanner entry at all. > > -- > /peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From bonivart at opencsw.org Mon Jul 5 22:17:22 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 5 Jul 2010 22:17:22 +0200 Subject: [csw-maintainers] Error in weekly package summary In-Reply-To: References: Message-ID: On Mon, Jul 5, 2010 at 10:13 PM, Philip Brown wrote: > yeah I had halfway put in new one then backed it out when I wrote > comments. this gave a false positive for the update scanner. > I think new one is in now though? Yes, it's in now, I just checked. :-) -- /peter From william at wbonnet.net Tue Jul 6 13:56:18 2010 From: william at wbonnet.net (William Bonnet) Date: Tue, 6 Jul 2010 13:56:18 +0200 Subject: [csw-maintainers] Proposal : decommissioning desktop support for Solaris 9 Message-ID: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> Hi, We recently experienced many problems with the CSW X11 libs I pushed forward. Especially we had to step back because of the loss of 3D acceleration. After switching back to Sun's lib, i'm still in front of several problems to compile recent applications against Sun's lib on Solaris 9 (especially Mozilla's stuff). I'm afraid that we will still have this kind of problems as long as we will keep compatibility with X11 version provided Solaris 9. As you may know, Sun's Beijing team released recent Firefox version. These builds are Solaris 10 only. On my own i made some tests with seamonkey (it was not the latest). It needs libs update on Solaris 9, but compiles almost out of the box on Solaris 10. This situation, will not improve in the next months, and i'm pretty sure it is the same for other software stacks. This lead me to the following proposal. I think it may be the time to think about dropping desktop support for Solaris 9. Or at least to focus on providing Solaris 10 only packages for desktop applications in recent version. Of course existing packages would be kept in the repository, but no longer updated. And non desktop packages are out of the scope of this proposal ! IMHO most of desktop users are Solaris 10 users. There are certainly a few Solaris 9 users. This mean they will have to stick to existing version (FF3, TB2, etc.). Anyways current situation, makes me uncertain about the possibility to deliver anything else than these versions... Thus, better update for Solaris 10 users, instead of keeping everyone at Solaris 9 level. Feedback and thoughts are welcome :) cheers W. From william at wbonnet.net Tue Jul 6 14:55:36 2010 From: william at wbonnet.net (William Bonnet) Date: Tue, 6 Jul 2010 14:55:36 +0200 Subject: [csw-maintainers] Summer camp 2010 : List of hotel available Message-ID: <1B198847-C614-4154-ADF4-8DEB3141E362@wbonnet.net> Hi I have updated the wiki page with a list of hotel. All are close to the meeting room (5 to 10 minutes walking). http://wiki.opencsw.org/summercamp-2010 cheers W. From phil at bolthole.com Tue Jul 6 17:21:40 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 6 Jul 2010 08:21:40 -0700 Subject: [csw-maintainers] Proposal : decommissioning desktop support for Solaris 9 In-Reply-To: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> Message-ID: On Tue, Jul 6, 2010 at 4:56 AM, William Bonnet wrote: > .... On my own i made some tests with seamonkey (it was not the latest). It needs libs update on Solaris 9, but compiles almost out of the box on Solaris 10. This situation, will not improve in the next months, and i'm pretty sure it is the same for other software stacks. > > This lead me to the following proposal. I think it may be the time to think about dropping desktop support for Solaris 9. Or at least to focus on providing Solaris 10 only packages for desktop applications in recent version. Ah,, wow.. that's a huge proposal! and I think a bit premature. Even **sun**(beijing) had to ship "updated libs", with its firefox! This up-to-date libs problem, is not going away. It has been around since the beginning of CSW, and is even covered in our FAQ! ( http://www.opencsw.org/about/faq/, "Why dont you guys use Sun packages of..." ) Even that aside... I think this is more of a firefox-specific problem. firefox is a disgustingly bloated,non-portably written ... beast. If you wished to only update firefox on sol10... I would allow those packages through. That being said, the majority of desktop software still compiles relatively easily on sol9, and the other stuff with some small amount of work (1-2 patches per piece of software). So long as there are people willing to tackle the "needs work" packages, I dont see why we would want to "officially" abandon sol9 desktop. It is in fact, the area where we are most needed, in a way. Since it is easier to compile that stuff directly on sol10, there is less "need" for 3rd parties to provide sol10 packages of that stuff. Sol9 users "need" us more. From bonivart at opencsw.org Tue Jul 6 23:25:47 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 6 Jul 2010 23:25:47 +0200 Subject: [csw-maintainers] Proposal : decommissioning desktop support for Solaris 9 In-Reply-To: References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> Message-ID: On Tue, Jul 6, 2010 at 5:21 PM, Philip Brown wrote: > It is in fact, the area where we are most needed, in a way. > Since it is easier to compile that stuff directly on sol10, there is > less "need" for 3rd parties to provide sol10 packages of that stuff. > Sol9 users "need" us more. By that logic we should immediately pick up Solaris 8 again... ;-) -- /peter From william at wbonnet.net Wed Jul 7 01:25:47 2010 From: william at wbonnet.net (William Bonnet) Date: Wed, 07 Jul 2010 01:25:47 +0200 Subject: [csw-maintainers] Proposal : decommissioning desktop support for Solaris 9 In-Reply-To: References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> Message-ID: <4C33BB7B.6020107@wbonnet.net> Hi > Even **sun**(beijing) had to ship "updated libs", with its firefox! > Yes, but they don't provide a full X11 stack with their Firefox, do they ? otherwise they should also provide Solaris 9 binaries... > Even that aside... I think this is more of a firefox-specific problem. > I'm not really sure about this. It's also a Qt problem, thus a KDE problem. It's also already a Xfce problem, and I'm sure soon or later it will be a gnome problem when you'll try to get the latest version. Even if some time you can patch the software to make it run under Solaris 9, i'm not really sure it's any longer worth the effort. > So long as there are people willing to tackle the "needs work" > packages, I dont see why we would want to "officially" abandon sol9 > desktop. > Because IMHO Solaris 9 desktop users are very few, regarding to Solaris 10 users, because we will not remove existing packages from catalog, and because it takes a loooonnggg time to produce Solaris 9 packages for some software. I cannot remember how many hours and night i spent patching Xfce code and mozilla stuff to finally release only FF3.0 Today the compilation of the up to date mozilla stack under solaris 9 reached a dead end if we don't update X11.Mozilla is not the only software stack which is concerned. But even if it was, it's a good reason to me. If we cannot provide a recent browser and mail agent, it's a real problem to me as a desktop user. Especially, if our policy prevent us to do the upgrade and force me to use Sun's contributed build instead of our build. Maybe dropping Solaris 9 support for desktop is a bit fast. We should take in account the number of Solaris 9 users (do we have statistics about this ? or is it time to make Lutefisk publicly available ?), and we should take in account which software can be updated under solaris 9 or not. Packages which are easy to update could be kept up to date according to the maintainer will and time, but IMHO Solaris 10 should go mainstream as desktop target. Actually i feel like if we were stuck with this version which prevent us to do some updates. So what is the worst thing ? To provide only a very few update to everyone. This means not providing up to date software to the majority of desktop users (which are running Sol10). or to go mainstream with Solaris 10, provide up to date packages for this platform, and to provide what we can for Solaris 9 BTW this would also save a lot of patching and porting effort ;) cheers W. From bwalton at opencsw.org Wed Jul 7 01:53:54 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 06 Jul 2010 19:53:54 -0400 Subject: [csw-maintainers] Proposal : decommissioning desktop support for Solaris 9 In-Reply-To: References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> Message-ID: <1278460236-sup-2831@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Jul 06 11:21:40 -0400 2010: Hi Phil, > It is in fact, the area where we are most needed, in a way. Since > it is easier to compile that stuff directly on sol10, there is less > "need" for 3rd parties to provide sol10 packages of that stuff. > Sol9 users "need" us more. This is true iff there are sol9 desktop users. Do we have any sense that there are sol9 desktop folks out there? I'd be surprised if there were many. Even if there are a few, forcing[1] a desktop upgrade to run software is less of an issue than forcing a server upgrade. Thanks -Ben [1] They can continue to run the currently available, but increasingly outdated versions if they wish. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From james at opencsw.org Wed Jul 7 10:02:08 2010 From: james at opencsw.org (James Lee) Date: Wed, 07 Jul 2010 08:02:08 GMT Subject: [csw-maintainers] Proposal : decommissioning desktop support for Solaris 9 In-Reply-To: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> Message-ID: <20100707.8020800.2956226871@gyor.oxdrove.co.uk> On 06/07/10, 12:56:18, William Bonnet wrote regarding [csw-maintainers] Proposal : decommissioning desktop support for Solaris 9: > This lead me to the following proposal. I think it may be the time > to think about dropping desktop support for Solaris 9. Or at least > to focus on providing Solaris 10 only packages for desktop > applications in recent version. > Of course existing packages would be kept in the repository, but > no longer updated. And non desktop packages are out of the scope > of this proposal ! > IMHO most of desktop users are Solaris 10 users. There are certainly > a few Solaris 9 users. This mean they will have to stick to existing > version (FF3, TB2, etc.). Anyways current situation, makes me > uncertain about the possibility to deliver anything else than these > versions... Thus, better update for Solaris 10 users, instead of > keeping everyone at Solaris 9 level. I and one other person I know run Solaris desktop on 8/9 and not 10 because CPR reboot works on 7/8/9 but not on Solaris 10. This is such a clear advantage to a desktop it's worth 2 versions of Firefox. Although I actually run my browser from a remote Solaris 10 machine so I can use a later version, also because browsers leak memory restarting daily helps. Everything else I like to have running exactly where I left it. James. From phil at bolthole.com Wed Jul 7 18:54:02 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 7 Jul 2010 09:54:02 -0700 Subject: [csw-maintainers] Proposal : decommissioning desktop support for Solaris 9 In-Reply-To: <4C33BB7B.6020107@wbonnet.net> References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> <4C33BB7B.6020107@wbonnet.net> Message-ID: On Tuesday, July 6, 2010, William Bonnet wrote: > Hi > > > Even **sun**(beijing) had to ship "updated libs", with its firefox! > > > Yes, but they don't provide a full X11 stack with their Firefox, do they ? we don't have to provide a full stack either. that was a mistake on our part . as proof of concept, would you please recompile firefox... the old 3.0 version you already had patched ... using our newer gtk libs and WITHOUT cswx11? if I'm right,this should be easy for you. perhaps this will make you feel more comfortable about things. I'd try it myself, but the odd things you did in gar made it not easy for ME to follow what you did :) From william at wbonnet.net Thu Jul 8 00:27:58 2010 From: william at wbonnet.net (William Bonnet) Date: Thu, 08 Jul 2010 00:27:58 +0200 Subject: [csw-maintainers] Proposal : decommissioning desktop support for Solaris 9 In-Reply-To: References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> <4C33BB7B.6020107@wbonnet.net> Message-ID: <4C34FF6E.3070007@wbonnet.net> Hi > we don't have to provide a full stack either. that was a mistake on our part . > well maybe... i was away for a few weeks, so i may have missed some reasons. Was there another reason than loosing 3D accel ? > as proof of concept, would you please recompile firefox... the old 3.0 > version you already had patched ... using our newer gtk libs and > WITHOUT cswx11? > Which machine should i use ? I tried to compile on current9x and testing9x it does not work on both machines. > I'd try it myself, but the odd things you did in gar made it not easy > for ME to follow what you did :) > I surely did odd things with the X11 libs :) but hopefully there was GAR ... even for you ;) cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From phil at bolthole.com Thu Jul 8 01:47:24 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 7 Jul 2010 16:47:24 -0700 Subject: [csw-maintainers] Proposal : decommissioning desktop support for Solaris 9 In-Reply-To: <4C34FF6E.3070007@wbonnet.net> References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> <4C33BB7B.6020107@wbonnet.net> <4C34FF6E.3070007@wbonnet.net> Message-ID: > I'd try it myself, but the odd things you did in gar made it not easy > for ME to follow what you did :) > > > I surely did odd things with the X11 libs :) but hopefully there was GAR ... even for you ;) > I tried using your gar stuff... or at least whatever was in trunk... and it kept gettng wierd on me. this was with cswx11 I think. maybe you could start with a "clean" gar, but with your source patches , for 3.0 and see how it goes. the one change is no xcb current9 machines should work. if not please list errors From william at wbonnet.net Thu Jul 8 11:19:43 2010 From: william at wbonnet.net (William Bonnet) Date: Thu, 8 Jul 2010 11:19:43 +0200 Subject: [csw-maintainers] Proposal : decommissioning desktop support for Solaris 9 In-Reply-To: References: <946827F0-9E0C-4F0E-82B6-57E0F9868A0C@wbonnet.net> <4C33BB7B.6020107@wbonnet.net> <4C34FF6E.3070007@wbonnet.net> Message-ID: Hi Phil > I tried using your gar stuff... or at least whatever was in trunk... > and it kept gettng wierd on me. > this was with cswx11 I think. I've started to do some cleaning and rebuild from firefox/trunk i'll send the result this evening cheers W. From maciej at opencsw.org Thu Jul 8 14:10:49 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Jul 2010 13:10:49 +0100 Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at once In-Reply-To: <1278172673-sup-152@pinkfloyd.chass.utoronto.ca> References: <4C2BA75F.5090003@wbonnet.net> <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net> <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> <1278172673-sup-152@pinkfloyd.chass.utoronto.ca> Message-ID: It seems to me that the command is run every time, there's no caching. It doesn't take much time to run, but it still could be cached, I think. Thoughts? From bwalton at opencsw.org Thu Jul 8 14:46:51 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Jul 2010 08:46:51 -0400 Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at once In-Reply-To: References: <4C2BA75F.5090003@wbonnet.net> <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net> <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> <1278172673-sup-152@pinkfloyd.chass.utoronto.ca> Message-ID: <1278593150-sup-9694@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Thu Jul 08 08:10:49 -0400 2010: > It seems to me that the command is run every time, there's no caching. > It doesn't take much time to run, but it still could be cached, I > think. Thoughts? It wasn't previously cached was it? (Hoping I didn't add a regression even though it would still run quickly...) I agree that it could be cached with a cookie. I'll have a look at that tonight. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Jul 8 15:07:39 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Jul 2010 14:07:39 +0100 Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at once In-Reply-To: <1278593150-sup-9694@pinkfloyd.chass.utoronto.ca> References: <4C2BA75F.5090003@wbonnet.net> <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net> <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> <1278172673-sup-152@pinkfloyd.chass.utoronto.ca> <1278593150-sup-9694@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 8 de Julho de 2010 13:46, Ben Walton escreveu: > Excerpts from Maciej (Matchek) Blizinski's message of Thu Jul 08 08:10:49 -0400 2010: >> It seems to me that the command is run every time, there's no caching. >> ?It doesn't take much time to run, but it still could be cached, I >> think. ?Thoughts? > > It wasn't previously cached was it? ?(Hoping I didn't add a regression > even though it would still run quickly...) ?I agree that it could be > cached with a cookie. ?I'll have a look at that tonight. It was cached, it had to be. We couldn't have stood it if it wasn't. The new check is fast enough, but I noticed the output to the screen, so I asked. From bwalton at opencsw.org Thu Jul 8 16:57:32 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Jul 2010 10:57:32 -0400 Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at once In-Reply-To: References: <4C2BA75F.5090003@wbonnet.net> <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net> <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> <1278172673-sup-152@pinkfloyd.chass.utoronto.ca> <1278593150-sup-9694@pinkfloyd.chass.utoronto.ca> Message-ID: <1278601030-sup-8536@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Thu Jul 08 09:07:39 -0400 2010: > It was cached, it had to be. We couldn't have stood it if it > wasn't. The new check is fast enough, but I noticed the output to > the screen, so I asked. Ok. I'll correct this tonight. Thanks for noticing it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Jul 8 18:31:17 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Jul 2010 17:31:17 +0100 Subject: [csw-maintainers] cswinitsmf vs custom SMF manifests vs pkgutil Message-ID: There's a problem that I discovered. The first symptom is that after an upgrade done by pkgutil, there is a SMF service that is in the maintenance state, even though all the dependencies are installed. I've pulled it apart and discovered that it's caused by a combination of 3 things: 1. If CSWfoo depends on CSWbar and both are to be upgraded, pkgutil can remove CSWbar from under CSWfoo; if CSWfoo is running from SMF, it goes into the maintenance state because it misses CSWbar 2. If a custom SMF manifest is used, r.cswinitsmf doesn't remove the manifest from SMF 3. If there is an existing manifest during installation, which is the maintenance state, i.cswinitsmf imports the new manifest, but only calls 'enable' on it. This means that the service remains in the maintenance state until 'svcadm clear' is issued. I can fix problems 2 and 3. Peter, would you mind looking at the first problem? Maciej From phil at bolthole.com Thu Jul 8 18:46:25 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Jul 2010 09:46:25 -0700 Subject: [csw-maintainers] cswinitsmf vs custom SMF manifests vs pkgutil In-Reply-To: References: Message-ID: On Thu, Jul 8, 2010 at 9:31 AM, Maciej (Matchek) Blizinski wrote: > ... I've pulled it apart and discovered that it's caused by a combination > of 3 things: > > 1. If CSWfoo depends on CSWbar and both are to be upgraded, pkgutil > can remove CSWbar from under CSWfoo; if CSWfoo is running from SMF, it > goes into the maintenance state because it misses CSWbar > 2. If a custom SMF manifest is used, r.cswinitsmf doesn't remove the > manifest from SMF > 3. If there is an existing manifest during installation, which is the > maintenance state, i.cswinitsmf imports the new manifest, but only > calls 'enable' on it. ?This means that the service remains in the > maintenance state until 'svcadm clear' is issued. > > I can fix problems 2 and 3. ?Peter, would you mind looking at the first problem? > I would suggest and request that the solution be implemented in a transport neutral fashion: ideally, it should be something that works with manual "pkgrm/pkgadd". ie: an adjustment to cswinitsmf, rather than elsewhere. From maciej at opencsw.org Fri Jul 9 10:08:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 9 Jul 2010 09:08:00 +0100 Subject: [csw-maintainers] cswinitsmf vs custom SMF manifests vs pkgutil In-Reply-To: References: Message-ID: No dia 8 de Julho de 2010 17:46, Philip Brown escreveu: > On Thu, Jul 8, 2010 at 9:31 AM, Maciej (Matchek) Blizinski > wrote: >> ... I've pulled it apart and discovered that it's caused by a combination >> of 3 things: >> >> 1. If CSWfoo depends on CSWbar and both are to be upgraded, pkgutil >> can remove CSWbar from under CSWfoo; if CSWfoo is running from SMF, it >> goes into the maintenance state because it misses CSWbar >> 2. If a custom SMF manifest is used, r.cswinitsmf doesn't remove the >> manifest from SMF >> 3. If there is an existing manifest during installation, which is the >> maintenance state, i.cswinitsmf imports the new manifest, but only >> calls 'enable' on it. ?This means that the service remains in the >> maintenance state until 'svcadm clear' is issued. >> >> I can fix problems 2 and 3. ?Peter, would you mind looking at the first problem? >> > > I would suggest and request that the solution be implemented in a > transport neutral fashion: > > ideally, it should be something that works with manual "pkgrm/pkgadd". > ie: an adjustment to cswinitsmf, rather than elsewhere. Yes, that's the idea. These are 3 independent issues, there will be 3 independent fixes. From ihsan at opencsw.org Fri Jul 9 12:46:15 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Fri, 09 Jul 2010 12:46:15 +0200 Subject: [csw-maintainers] unexpected mail server outage Message-ID: <4C36FDF7.9000802@opencsw.org> Hello, FYI: There was an unexpected mail server outage of approx. 10 minutes. Other services (website) were not affected by this. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Fri Jul 9 16:31:25 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 09 Jul 2010 10:31:25 -0400 Subject: [csw-maintainers] [gar] RFE : display all prerequisitepkg at once In-Reply-To: References: <4C2BA75F.5090003@wbonnet.net> <1277929832-sup-5707@pinkfloyd.chass.utoronto.ca> <1EF87CD8-DE0E-4F35-AAFF-95947D80E46C@wbonnet.net> <1277986547-sup-6149@pinkfloyd.chass.utoronto.ca> <1278172673-sup-152@pinkfloyd.chass.utoronto.ca> <1278593150-sup-9694@pinkfloyd.chass.utoronto.ca> Message-ID: <1278685870-sup-3099@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Thu Jul 08 09:07:39 -0400 2010: > It was cached, it had to be. We couldn't have stood it if it > wasn't. The new check is fast enough, but I noticed the output to > the screen, so I asked. This should be resolved now. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Jul 9 19:03:50 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 09 Jul 2010 13:03:50 -0400 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> Message-ID: <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Mon Jun 21 19:47:19 -0400 2010: Hi Phil, > CSWcommon is 'fixing' things the wrong way, by papering over bugs in > other packages[1]...it's cancelling an intended feature of > gettext/libintl and doing only half the job at that. Let's fix this > _properly_ instead of adding another layer of papier macher. Is there an update for CSWcommon in the pipe to address this? I'd like to get the coreutils package working properly. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Jul 9 21:02:18 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Jul 2010 12:02:18 -0700 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Jul 9, 2010 at 10:03 AM, Ben Walton wrote: > Excerpts from Ben Walton's message of Mon Jun 21 19:47:19 -0400 2010: > > Hi Phil, > >> CSWcommon is 'fixing' things the wrong way, by papering over bugs in >> other packages[1]...it's cancelling an intended feature of >> gettext/libintl and doing only half the job at that. ?Let's fix this >> _properly_ instead of adding another layer of papier macher. > > Is there an update for CSWcommon in the pipe to address this? ?I'd > like to get the coreutils package working properly. > nothing active at the moment. As I said earlier in the thread, this requires some research. its "on my list", but as a very low priority. Research should look into WHY some locales have the symlinks for LC_MESSAGES == LC_TIME, and some do not. Even in the package of your "own" that you are complaining about: some symlink, and some do not. There may be some actual known standard or something, in the realm of locales, that makes this a good idea, and actually BREAKS certain things if not done. This is my vague 7-year-fuzzy-memory of the thing. Possibly something to do with time/date comparisons and display. And honestly, can you really see me manually putting together umpteen symlinks into the common prototype package.. and NOT doing all of them... unless I had a fairly good reason at the time? I think you know me better than that by now. :) My usual preference would be to either just put in empty directories, or symlink everything. From bwalton at opencsw.org Sat Jul 10 02:05:37 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 09 Jul 2010 20:05:37 -0400 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> Message-ID: <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Jul 09 15:02:18 -0400 2010: Hi Phil, > Research should look into WHY some locales have the symlinks for > LC_MESSAGES == LC_TIME, and some do not. I suspect that you added symlinks in CSWcommon for the locales delivered by the packages that were broken and no other locales. That makes sense given what you were attempting to do. > Even in the package of your "own" that you are complaining about: > some symlink, and some do not. Use of LC_TIME is discouraged, but not invalid. Most packages won't deliver anything but LC_MESSAGES, which is why this hasn't been hit until now. The coreutils case provides symlinks to make the domains equal too. (I realize I could fix this in coreutils, I just don't think that's the best solution.) > There may be some actual known standard or something, in the realm > of locales, that makes this a good idea, and actually BREAKS certain > things if not done. Not according to the documentation I read (eg: the official libintl/gettext stuff). > This is my vague 7-year-fuzzy-memory of the thing. Possibly > something to do with time/date comparisons and display. What you did when you added the links in CSWcommon allows programs that referenced localizations in the LC_TIME domain to function even though they hadn't properly provided those files. This would have been the result of either improper programming (they used LC_TIME when LC_MESSAGES should have been used) or improper installation routines (the install should have provided either files or symlinks on its own). While it was easier to work around this in CSWcommon, that allowed the packages themselves to remain broken. I wonder if this may have originated with the original CSWtextutils, CSWgfile and CSWshutils packages...? > And honestly, can you really see me manually putting together > umpteen symlinks into the common prototype package.. and NOT doing > all of them... unless I had a fairly good reason at the time? I > think you know me better than that by now. :) My usual preference > would be to either just put in empty directories, or symlink > everything. Yes, I do. I also know that you're likely to err toward the correctness side of things rather than the easiest route in all cases...that's what I'm attempting here. While there aren't likely many programs using LC_TIME in any serious fashion, there is the possibility that they could (until it becomes officially deprecated, but that's hard to do...). I'll make the offer that if you update CSWcommon to be more correct and not break CSWcoreutils, I'll re-roll any package that breaks as a result with a _minimum_ of a manual insertion of the required proper directories and symlinks and possible a version upgrade/garification. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sat Jul 10 04:42:15 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Jul 2010 19:42:15 -0700 Subject: [csw-maintainers] [csw-buildfarm] running mkheaders for gcc4 In-Reply-To: <1278727782-sup-6502@pinkfloyd.chass.utoronto.ca> References: <1278727782-sup-6502@pinkfloyd.chass.utoronto.ca> Message-ID: hmmm this is something that probably needs to be automatically run in each zone, if there is a global zone and a sol9 container zone. I wonder if that happens on pkgadd on gcc4? hmmm... but if it's a sparse zone it would fail since output is under /opt, not var I think? oh-oh... On Friday, July 9, 2010, Ben Walton wrote: > > I'm about to run gcc4's included (news to me) mkheaders. ?I _think_ > this will get us over the hump for building things that were broken > with sol9. > > Stay tuned. > From bwalton at opencsw.org Sat Jul 10 04:53:49 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 09 Jul 2010 22:53:49 -0400 Subject: [csw-maintainers] [csw-buildfarm] running mkheaders for gcc4 In-Reply-To: References: <1278727782-sup-6502@pinkfloyd.chass.utoronto.ca> Message-ID: <1278730342-sup-7105@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Jul 09 22:42:15 -0400 2010: > this is something that probably needs to be automatically run in > each zone, if there is a global zone and a sol9 container zone. I > wonder if that happens on pkgadd on gcc4? It doesn't get triggered by pkgadd for gcc4, but Peter F's gcc3 does trigger it that way. > hmmm... but if it's a sparse zone it would fail since output is > under /opt, not var I think? oh-oh... Yes, this is true, afaik. For what it's worth, I've been able to build ruby again after running it, so aside from potential delivery issues, it's a good step forward. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Sun Jul 11 16:14:06 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 11 Jul 2010 16:14:06 +0200 Subject: [csw-maintainers] chkpkg error, or gmake clean platforms error? Message-ID: hi, when building the new version of mercurial, 1.6, i did, on build9s: 1. change the version numer from 1.5.4 to 1.6 2. gmake makesums 3. gmake clean platforms and it endet with CSWmercurial: * The package installs files into /opt/csw/lib/python. For example, '/opt/csw/lib/python/site-packages'. However, the pkgname doesn't start with 'CSWpy-'. * The package installs files into /opt/csw/lib/python. For example, '/opt/csw/lib/python/site-packages'. However, the catalogname doesn't start with 'py_'. Applying the overrides and analyzing the results. 100% |#########################################################################| If any of the reported errors were false positives, you can override them pasting the lines below to the GAR recipe. CHECKPKG_OVERRIDES_CSWmercurial += filename-version-does-not-match-pkginfo-version|filename=1.6,REV=2010.07.11|pkginfo=1.5.4,REV=2010.06.01 Please note that checkpkg isn't suggesting you should use these overrides. It only informs what the overrides could look like. You need to understand what are the reported issues about and use your best judgement to decide whether to fix the underlying problems or override them. ERROR: Modular checks are reporting errors. To run checkpkg in the debug mode, add the '-d' flag, for example: After you modify any overrides, you need to do gmake remerge repackage or gmake platforms-remerge platforms-repackage. gmake: *** [pkgcheck] Error 2 gmake: Leaving directory `/home/rupert/mgar/pkg/mercurial/trunk' Connection to current9x closed. gmake: *** [platforms] Error 2 rupert at current9s ~/mgar/pkg/mercurial/trunk where does this error come from? rupert From maciej at opencsw.org Sun Jul 11 17:38:57 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 11 Jul 2010 16:38:57 +0100 Subject: [csw-maintainers] chkpkg error, or gmake clean platforms error? In-Reply-To: References: Message-ID: No dia 11 de Julho de 2010 15:14, rupert THURNER escreveu: > hi, > > when building the new version of mercurial, 1.6, i did, on build9s: > > 1. change the version numer from 1.5.4 to 1.6 > 2. gmake makesums > 3. gmake clean platforms The 'gmake clean' command has performed clean on your current host (probably current9s), and on this host only. The error you saw was thrown on current9x. If you look at the error message you got, you'll see the sequence: the error is emitted, and the connection to current9x is closed. gmake: Leaving directory `/home/rupert/mgar/pkg/mercurial/trunk' Connection to current9x closed. gmake: *** [platforms] Error 2 rupert at current9s As a general rule, you would do: gmake makesums gmake replatforms The 'replatforms' target performs 'clean' on all hosts. Maciej From ja at opencsw.org Sun Jul 11 19:55:25 2010 From: ja at opencsw.org (Juergen Arndt) Date: Sun, 11 Jul 2010 19:55:25 +0200 Subject: [csw-maintainers] Munin 1.4.5 in experimental Message-ID: <0D0D6119-7AEC-4A83-B733-AB955BAED071@opencsw.org> Hi there, there are new packages for Munin available from http://mirror.opencsw.org/experimental.html#ja Feedback is very welcome. Juergen -- Juergen Arndt From rupert at opencsw.org Mon Jul 12 05:04:17 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 12 Jul 2010 05:04:17 +0200 Subject: [csw-maintainers] dead link on packages page Message-ID: hi, http://www.opencsw.org/packages/ contains a dead link onto the testing area, this should probably go into experimental? rupert. From maciej at opencsw.org Mon Jul 12 18:16:03 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 12 Jul 2010 17:16:03 +0100 Subject: [csw-maintainers] XML processing tools on bare Solaris 10 Message-ID: In order to resolve the problem with cswinitsmf with custom manifests, XML processing is necessary. I tried Perl, but the XML::DOM package is not installed by default. Are there any in-built XML processing tools available in CAS on Solaris 10? (Solaris 9 doesn't have SMF, so no need for XML processing there.) Maciej From phil at bolthole.com Mon Jul 12 18:54:45 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Jul 2010 09:54:45 -0700 Subject: [csw-maintainers] XML processing tools on bare Solaris 10 In-Reply-To: References: Message-ID: On 7/12/10, Maciej (Matchek) Blizinski wrote: > In order to resolve the problem with cswinitsmf with custom manifests, > XML processing is necessary. I tried Perl, but the XML::DOM package > is not installed by default. Are there any in-built XML processing > tools available in CAS on Solaris 10? (Solaris 9 doesn't have SMF, so > no need for XML processing there.) > What is the exact problem you are trying to solve? surely, [Full XML Dom-compliant buzzwordBlahBlahBlah] is not neccessary. worst case.. use the smf libraries and utils themselves? From phil at bolthole.com Mon Jul 12 23:14:51 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Jul 2010 14:14:51 -0700 Subject: [csw-maintainers] new gnome stuffs Message-ID: FYI, I released my pending libbonobo, blah blah other gnome low-level foundation stuffs that were sitting in experimental for a month. From bwalton at opencsw.org Tue Jul 13 03:06:28 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 12 Jul 2010 21:06:28 -0400 Subject: [csw-maintainers] de-listed packages...? Message-ID: <1278983109-sup-8312@pinkfloyd.chass.utoronto.ca> Hi All, I was looking at the list of packages affected by an 'update all' action on the buildfarm and found the following. I assume that these have all been pulled from the catalog, but if someone wouldn't mind piping up if they know the full story on the packages, I'd appreciate it. CSWglibmmdevel 2.16.4,REV=2008.12.03 not in catalog CSWglibmmrt 2.16.4,REV=2008.12.02 not in catalog CSWgtkmm2 2.2.12 not in catalog CSWgtkmmdevel 2.12.5,REV=2008.12.03 not in catalog CSWgtkmmrt 2.12.5,REV=2008.12.02 not in catalog CSWhachoir-parser 1.2.1,REV=2010.01.15 not in catalog CSWlibsigc++rt 2.2.3,REV=2008.12.01 not in catalog CSWpmdigest 1.16,REV=2009.08.10 not in catalog CSWpmlistmoreut 0.22,REV=2007.03.17 not in catalog CSWpmmodulebuild 0.33,REV=2009.06.08 not in catalog CSWrenderproto 0.9.3,REV=2009.05.29 not in catalog CSWxextproto 7.1.1,REV=2009.09.17 not in catalog Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Jul 13 03:12:45 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 12 Jul 2010 21:12:45 -0400 Subject: [csw-maintainers] [RFC] splitting cswclassutils Message-ID: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca> Hi All, I'd like to propose that cswclassutils be split as follows: 1. Each i/r script pair becomes a separate package named CSWcu-foo 2. CSWclassutils becomes an empty package depending on all CSWcu-foo packages. It will only change when we add/remove a CSWcu-foo package. This would make bug tracking nicer as it currently burdens Peter B even when he's not the author/maintainer of the script in question. It should also make coordination of the package easier as one person isn't repsonsible for ensuring that all separate script updates have been tested before asking for a new release, etc. (I think this was suggested a few weeks back, but I'm formalizing the rfc.) Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Tue Jul 13 09:32:09 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Jul 2010 08:32:09 +0100 Subject: [csw-maintainers] XML processing tools on bare Solaris 10 In-Reply-To: References: Message-ID: No dia 12 de Julho de 2010 17:54, Philip Brown escreveu: > On 7/12/10, Maciej (Matchek) Blizinski wrote: >> In order to resolve the problem with cswinitsmf with custom manifests, >> XML processing is necessary. ?I tried Perl, but the XML::DOM package >> is not installed by default. ?Are there any in-built XML processing >> tools available in CAS on Solaris 10? ?(Solaris 9 doesn't have SMF, so >> no need for XML processing there.) >> > > What is the exact problem you are trying to solve? `OoAwwrrrhhhhh... "Do. Or do not. there is no Try"' --Philip Brown, ca. 2010 ;-) > surely, [Full XML Dom-compliant buzzwordBlahBlahBlah] is not neccessary. > worst case.. use the smf libraries and utils themselves? Good suggestion about the SMF utilities. svccfg inventory outputs the list of service fmris. [1] http://lists.opencsw.org/pipermail/maintainers/2010-March/011569.html From maciej at opencsw.org Tue Jul 13 09:34:31 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Jul 2010 08:34:31 +0100 Subject: [csw-maintainers] de-listed packages...? In-Reply-To: <1278983109-sup-8312@pinkfloyd.chass.utoronto.ca> References: <1278983109-sup-8312@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 13 de Julho de 2010 02:06, Ben Walton escreveu: > CSWhachoir-parser ? ? ? ? 1.2.1,REV=2010.01.15 ? ? ?not in catalog Has been renamed to CSWpy-hachoir-parser. The old one can be removed. From maciej at opencsw.org Tue Jul 13 09:51:54 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Jul 2010 08:51:54 +0100 Subject: [csw-maintainers] [RFC] splitting cswclassutils In-Reply-To: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca> References: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 13 de Julho de 2010 02:12, Ben Walton escreveu: > This would make bug tracking nicer as it currently burdens Peter B > even when he's not the author/maintainer of the script in question. > It should also make coordination of the package easier as one person > isn't repsonsible for ensuring that all separate script updates have > been tested before asking for a new release, etc. I support the general idea. There's a variant of this approach that I'd suggest: instead of splitting off all the packages at once, we can be splitting them off one by one as needed. Once we do that, most of easy scripts will be in CSWcswclassutils, while CAS that benefit from well-defined ownership would live in separate packages. Thinking about checkpkg, I'd like checkpkg to verify the dependencies on CSWcu-* files. How would we detect the dependencies on specific CSWcu-* packages? I see two simple solutions: - a hardcoded mapping between class names and individual packages - cswfoo CAS always lives in CSWcu-foo, for example cswinitsmf lives in CSWcu-initsmf Maciej From james at opencsw.org Tue Jul 13 10:42:51 2010 From: james at opencsw.org (James Lee) Date: Tue, 13 Jul 2010 08:42:51 GMT Subject: [csw-maintainers] [RFC] splitting cswclassutils In-Reply-To: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca> References: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca> Message-ID: <20100713.8425100.2303544286@gyor.oxdrove.co.uk> On 13/07/10, 02:12:45, Ben Walton wrote regarding [csw-maintainers] [RFC] splitting cswclassutils: > I'd like to propose that cswclassutils be split as follows: > 1. Each i/r script pair becomes a separate package named CSWcu-foo > 2. CSWclassutils becomes an empty package depending on all CSWcu-foo > packages. It will only change when we add/remove a CSWcu-foo > package. > This would make bug tracking nicer as it currently burdens Peter B > even when he's not the author/maintainer of the script in question. > It should also make coordination of the package easier as one person > isn't repsonsible for ensuring that all separate script updates have > been tested before asking for a new release, etc. CSWcswclassutils has to be manually installed in the global zone, splitting it will make package management harder. Having a single responsible person should be a good thing, like having a prime contractor. The best way to reduce the maintainer burden is to stop fiddling with it. James. From bonivart at opencsw.org Tue Jul 13 11:40:35 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 13 Jul 2010 11:40:35 +0200 Subject: [csw-maintainers] de-listed packages...? In-Reply-To: <1278983109-sup-8312@pinkfloyd.chass.utoronto.ca> References: <1278983109-sup-8312@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Jul 13, 2010 at 3:06 AM, Ben Walton wrote: > > Hi All, > > I was looking at the list of packages affected by an 'update all' > action on the buildfarm and found the following. ?I assume that these > have all been pulled from the catalog, but if someone wouldn't mind > piping up if they know the full story on the packages, I'd appreciate > it. > > CSWpmdigest ? ? ? ? ? ? ? 1.16,REV=2009.08.10 ? ? ? not in catalog Included in Perl 5.10.1. > CSWpmlistmoreut ? ? ? ? ? 0.22,REV=2007.03.17 ? ? ? not in catalog Renamed to CSWpmlistmoreutils. > CSWpmmodulebuild ? ? ? ? ?0.33,REV=2009.06.08 ? ? ? not in catalog Included in Perl 5.10.1. You can remove all three. -- /peter From maciej at opencsw.org Tue Jul 13 16:26:49 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Jul 2010 15:26:49 +0100 Subject: [csw-maintainers] Providing parent directories for pkgmap entries Message-ID: I've found an interesting issue and I can't decide whether it's a problem or not. If you look at the list of files here: http://www.opencsw.org/search/vsftpd/ -- there is a directory named /opt/csw/var/empty/vsftpd, but the directory /opt/csw/var/empty is provided by neither vsftpd nor any of its dependencies. During installation, /opt/csw/var/empty gets created. On uninstallation, the /opt/csw/var/empty/vsftpd directory is removed, but /opt/csw/var/empty is not. Is not providing the parent directory a bug? From phil at bolthole.com Tue Jul 13 17:42:56 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 13 Jul 2010 08:42:56 -0700 Subject: [csw-maintainers] [RFC] splitting cswclassutils In-Reply-To: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca> References: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca> Message-ID: thank you for officially writing this up. I second it, with the one amendment of removing the "-" On Monday, July 12, 2010, Ben Walton wrote: > > Hi All, > > I'd like to propose that cswclassutils be split as follows: > > 1. Each i/r script pair becomes a separate package named CSWcu-foo > 2. CSWclassutils becomes an empty package depending on all CSWcu-foo > ? packages. ?It will only change when we add/remove a CSWcu-foo > ? package. > > This would make bug tracking nicer as it currently burdens Peter B > even when he's not the author/maintainer of the script in question. > It should also make coordination of the package easier as one person > isn't repsonsible for ensuring that all separate script updates have > been tested before asking for a new release, etc. > > (I think this was suggested a few weeks back, but I'm formalizing the > rfc.) > > Thoughts? > > 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 Tue Jul 13 17:55:37 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 13 Jul 2010 08:55:37 -0700 Subject: [csw-maintainers] [RFC] splitting cswclassutils In-Reply-To: <20100713.8425100.2303544286@gyor.oxdrove.co.uk> References: <1278983268-sup-400@pinkfloyd.chass.utoronto.ca> <20100713.8425100.2303544286@gyor.oxdrove.co.uk> Message-ID: On 7/13/10, James Lee wrote: > > CSWcswclassutils has to be manually installed in the global zone, > splitting it will make package management harder. > > Having a single responsible person should be a good thing, like having > a prime contractor. The best way to reduce the maintainer burden is > to stop fiddling with it. There's a tradeoff involved. Yes, there's "more stuff to install in global zone". However, once it is done initially... there is potentialy much less change. Some of the more recent additions, were very volatile in change rate. A cautious site, could have avoided any global changes whatsoever, if they did not happen to use one of the packages that used the class action script being tweaked. It also allows more choices at the site-local level. This way, it would be easier for a site to override ONE particular class action script (for example, with their own package that had date set for REV=3000.0.0), yet otherwise get normal updates for the other ones. At the moment, they would have to keep reviewing all 22 scripts, on every update to classutils. From phil at bolthole.com Tue Jul 13 18:02:01 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 13 Jul 2010 09:02:01 -0700 Subject: [csw-maintainers] Providing parent directories for pkgmap entries In-Reply-To: References: Message-ID: On 7/13/10, Maciej (Matchek) Blizinski wrote: > I've found an interesting issue and I can't decide whether it's a > problem or not. If you look at the list of files here: > http://www.opencsw.org/search/vsftpd/ -- there is a directory named > /opt/csw/var/empty/vsftpd, but the directory /opt/csw/var/empty is > provided by neither vsftpd nor any of its dependencies. During > installation, /opt/csw/var/empty gets created. On uninstallation, the > /opt/csw/var/empty/vsftpd directory is removed, but /opt/csw/var/empty > is not. > > Is not providing the parent directory a bug? Well, there's a bigger problem in that it is using "/opt/csw/var" in the first place :-/ Other than that, I think the more general question of leaving directories around, depends on where they are and what is in them. If it was somewhere else, such as /var/opt/csw, I dont think it would be much of a big deal. From phil at bolthole.com Tue Jul 13 18:25:08 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 13 Jul 2010 09:25:08 -0700 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> Message-ID: On 7/9/10, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Jul 09 15:02:18 -0400 2010: > > Hi Phil, > >> Research should look into WHY some locales have the symlinks for >> LC_MESSAGES == LC_TIME, and some do not. > > I suspect that you added symlinks in CSWcommon for the locales > delivered by the packages that were broken and no other locales. That > makes sense given what you were attempting to do. > well, trouble is, we no longer know definitively what I was "attempting to do" :-} >>[Phil wrote] >> Even in the package of your "own" that you are complaining about: >> some symlink, and some do not. Actually, I just looked in coreutils again. and... it's inconsistent. for example, it provides 1 d none /opt/csw/share/locale/nb 0755 root bin 1 d none /opt/csw/share/locale/nb/LC_MESSAGES 0755 root bin 1 f none /opt/csw/share/locale/nb/LC_MESSAGES/coreutils.mo 0644 root bin 29201 33503 1277688854 1 d none /opt/csw/share/locale/nb/LC_TIME 0755 root bin 1 s none /opt/csw/share/locale/nb/LC_TIME/coreutils.mo=../LC_MESSAGES/coreutils.mo but only 1 f none /opt/csw/share/locale/lt/LC_MESSAGES/coreutils.mo 0644 root bin 38282 41078 1277688854 1 d none /opt/csw/share/locale/lt/LC_TIME 0755 root bin 1 s none /opt/csw/share/locale/lt/LC_TIME/coreutils.mo=../LC_MESSAGES/coreutils.mo (no 'd' entry for the lt directory itself. Erm.. that's because of deduplication with cswcommon, I suppose? But still, inconsistency==not good) Yes I realize the irony of me saying that, given cswcommon. I WOULD like consistency there also. Trying to think of ways to get there. It would appear, that my initial glance and claim that coreutils only symlinked SOME LC_TIME entries, was incorrect. It seems to me note, that it symlinks ALL of them. I also think it likely that cswcommon was, as you say, tracking the locales from coreutils predecessors. Given these "new" facts, I'd like to make the following proposal, similar to the one you made: 1. cswcommon gets updated, to symlink ALL LC_TIME dirs to LC_MESSAGES 2. cswcommon gets a README file mentioning that the reason for the LC_TIME links, is to track coreutils local stuffs (and that as more locales get added, more dirs and LC_TIME symlinks should be added to it) 3. coreutils then gets to skip its LC_TIME symlinks. Hmm. there should probably also be a reverse comment in coreutils, "If new locales pop up that are not in cswcommon, then cswcommon should be updated". It might even be nice to have an AUTOMATED check, for "Hey, new locale! update cswcommon!" From maciej at opencsw.org Tue Jul 13 18:29:03 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Jul 2010 17:29:03 +0100 Subject: [csw-maintainers] Providing parent directories for pkgmap entries In-Reply-To: References: Message-ID: No dia 13 de Julho de 2010 17:02, Philip Brown escreveu: > Well, there's a bigger problem in that it is using "/opt/csw/var" in > the first place :-/ That's easy enough to catch. Will add a new check. > Other than that, I think the more general question of leaving > directories around, depends on where they are and what is in them. > If it was somewhere else, such as /var/opt/csw, I dont think it would > be much of a big deal. I would like to determine whether it makes sense to check for these. It might not be a significant issue, but still potentially nice to catch. From maciej at opencsw.org Tue Jul 13 18:31:29 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Jul 2010 17:31:29 +0100 Subject: [csw-maintainers] Check for the nrpe-like cases Message-ID: Following up on the missing directories topic and the nrpe case. The problem occurs when the three conditions are met: 1. The file is not of the 'none' class 2. It's not a directory 3. Nothing provides the parent directory I'm thinking of adding a check for this particular condition. Any thoughts? From bwalton at opencsw.org Tue Jul 13 18:51:54 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 13 Jul 2010 12:51:54 -0400 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> Message-ID: <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Jul 13 12:25:08 -0400 2010: > and... it's inconsistent. > for example, it provides > (no 'd' entry for the lt directory itself. Erm.. that's because of > deduplication with > cswcommon, I suppose? But still, inconsistency==not good) Right. The prototype provides a symlink from each LC_TIME to the corresponding LC_MESSAGES. It's only after installation that it gets inconsistent. > 1. cswcommon gets updated, to symlink ALL LC_TIME dirs to LC_MESSAGES > 2. cswcommon gets a README file mentioning that the reason for the > LC_TIME links, > is to track coreutils local stuffs (and that as more locales get added, more > dirs and LC_TIME symlinks should be added to it) > > 3. coreutils then gets to skip its LC_TIME symlinks. ...Can you re-read that and then tell me it makes sense from a maintenance point of view? So now, you're proposing that we _extend_ the current breakage (in the event some package actually needs separate LC_TIME/LC_MESSAGES which is VALID)? Not only does this continue to take away from what gettext has to offer, but it doubles the maintenance burden for these directories...in a non-automated way. I'm counter-proposing this: 1. Remove all share/locale/* from cswcommon 2. Keep coreutils as it is. 3. Fix packages (if any remaining) that break as a result, which is a rather trivial thing to do. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Jul 13 21:58:19 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 13 Jul 2010 12:58:19 -0700 Subject: [csw-maintainers] Providing parent directories for pkgmap entries In-Reply-To: References: Message-ID: Given that this was created "on the fly" (I presume), I think it would be incredibly difficult to catch with any certainty at pkg creation time. I dont think it's worth your effort. (Now, if we actually had a dedicated "QA team", who went around testing all this stuff, I might suggest putting stuff like this on their plate. But for something for "checkpkg" to catch... I dont think its worth it. On 7/13/10, Maciej (Matchek) Blizinski wrote: > No dia 13 de Julho de 2010 17:02, Philip Brown escreveu: >> Well, there's a bigger problem in that it is using "/opt/csw/var" in >> the first place :-/ > > That's easy enough to catch. Will add a new check. > >> Other than that, I think the more general question of leaving >> directories around, depends on where they are and what is in them. >> If it was somewhere else, such as /var/opt/csw, I dont think it would >> be much of a big deal. > > I would like to determine whether it makes sense to check for these. > It might not be a significant issue, but still potentially nice to > catch. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From phil at bolthole.com Tue Jul 13 21:58:56 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 13 Jul 2010 12:58:56 -0700 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> Message-ID: On 7/13/10, Ben Walton wrote: > Excerpts from Philip Brown's message of Tue Jul 13 12:25:08 -0400 2010: > >> and... it's inconsistent. >> for example, it provides > >> (no 'd' entry for the lt directory itself. Erm.. that's because of >> deduplication with >> cswcommon, I suppose? But still, inconsistency==not good) > > Right. The prototype provides a symlink from each LC_TIME to the > corresponding LC_MESSAGES. It's only after installation that it gets > inconsistent. > >> 1. cswcommon gets updated, to symlink ALL LC_TIME dirs to LC_MESSAGES >> 2. cswcommon gets a README file mentioning that the reason for the >> LC_TIME links, >> is to track coreutils local stuffs (and that as more locales get >> added, more >> dirs and LC_TIME symlinks should be added to it) >> >> 3. coreutils then gets to skip its LC_TIME symlinks. > > ...Can you re-read that and then tell me it makes sense from a > maintenance point of view? > > So now, you're proposing that we _extend_ the current breakage (in the > event some package actually needs separate LC_TIME/LC_MESSAGES which > is VALID)? Not only does this continue to take away from what gettext > has to offer, but it doubles the maintenance burden for these > directories...in a non-automated way. > > I'm counter-proposing this: > > 1. Remove all share/locale/* from cswcommon > 2. Keep coreutils as it is. > 3. Fix packages (if any remaining) that break as a result, which is a > rather trivial thing to do. > > Thoughts? > > 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 Tue Jul 13 22:02:21 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 13 Jul 2010 13:02:21 -0700 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> Message-ID: >> I'm counter-proposing this: >> >> 1. Remove all share/locale/* from cswcommon >> 2. Keep coreutils as it is. >> 3. Fix packages (if any remaining) that break as a result, which is a >> rather trivial thing to do. (again, from fuzzy memory..) I dont think its so much that "packages break". It's that when users try to do something "interesting" with LC_TIME, then almost *all* packages "break", unless there is the symlink from LC_TIME->messages. Which is presumably why I put the symlink into common, rather than having one particular package 'fix" this. odd example: Lets say you wanted your regular locale to be "X", but for some reason, wanted your time handling to be in the style of locale "Y". (For example, if you're stuck in yankee land, but actually like ISO time format standards ;-) This can only happen, if you actually HAVE "LC_TIME" directories, I think? From bwalton at opencsw.org Wed Jul 14 03:44:59 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 13 Jul 2010 21:44:59 -0400 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> Message-ID: <1279071647-sup-2856@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Jul 13 16:02:21 -0400 2010: > It's that when users try to do something "interesting" with LC_TIME, > then almost *all* packages "break", unless there is the symlink from > LC_TIME->messages. If that were true then wouldn't setting LC_TIME to a locale that isn't currently installed also "break" things? > This can only happen, if you actually HAVE "LC_TIME" directories, I > think? I don't think that's true. You're still overlooking the fact that symlinking the directories is removing the ability of a program to deliver separate .mo files for the various categories (_CTYPE, _MONETARY and _NUMERIC are also options a program might use). -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From james at opencsw.org Wed Jul 14 10:32:55 2010 From: james at opencsw.org (James Lee) Date: Wed, 14 Jul 2010 08:32:55 GMT Subject: [csw-maintainers] Providing parent directories for pkgmap entries In-Reply-To: References: Message-ID: <20100714.8325500.1948303005@gyor.oxdrove.co.uk> On 13/07/10, 15:26:49, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] Providing parent directories for pkgmap entries: > I've found an interesting issue and I can't decide whether it's a > problem or not. If you look at the list of files here: > http://www.opencsw.org/search/vsftpd/ -- there is a directory named > /opt/csw/var/empty/vsftpd, but the directory /opt/csw/var/empty is > provided by neither vsftpd nor any of its dependencies. During > installation, /opt/csw/var/empty gets created. On uninstallation, the > /opt/csw/var/empty/vsftpd directory is removed, but /opt/csw/var/empty > is not. > Is not providing the parent directory a bug? Not if the parent directory is in a parent package, notably CSWcommon. CSWcommon has directories surely to avoid duplicating directories in sub packages, eg, avoiding 1000 entries for /opt/csw/bin in the package database. Note, most don't include common directories: $ pkgchk -lp /opt/csw/bin ... James. From bonivart at opencsw.org Wed Jul 14 10:52:50 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 14 Jul 2010 10:52:50 +0200 Subject: [csw-maintainers] Providing parent directories for pkgmap entries In-Reply-To: References: Message-ID: On Tue, Jul 13, 2010 at 4:26 PM, Maciej (Matchek) Blizinski wrote: > I've found an interesting issue and I can't decide whether it's a > problem or not. If you look at the list of files here: > http://www.opencsw.org/search/vsftpd/ -- there is a directory named > /opt/csw/var/empty/vsftpd, but the directory ?/opt/csw/var/empty is > provided by neither vsftpd nor any of its dependencies. ?During > installation, /opt/csw/var/empty gets created. On uninstallation, the > /opt/csw/var/empty/vsftpd directory is removed, but /opt/csw/var/empty > is not. > > Is not providing the parent directory a bug? Sun recommends putting all needed directories in the none class so they will be created first (of course also before files in the none class). However, I think pkgadd is smart enough to create missing directories on the fly which is what happened here. Since there's no entry in the pkgmap for this directory (and pkgadd doesn't use installf for missing dirs?) pkgrm will not clean it up. This is probably only a problem when using CAS. With a simple "cp src dest" we will get in trouble with missing dirs like in the case of nrpe. -- /peter From bwalton at opencsw.org Thu Jul 15 00:33:58 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Jul 2010 18:33:58 -0400 Subject: [csw-maintainers] buildfarm updates Message-ID: <1279146726-sup-155@pinkfloyd.chass.utoronto.ca> Hi All, I'm about to update the buildfarms to current. I'll send another mail when the updates are complete. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Jul 15 01:27:54 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Jul 2010 19:27:54 -0400 Subject: [csw-maintainers] buildfarm updates In-Reply-To: <1279146726-sup-155@pinkfloyd.chass.utoronto.ca> References: <1279146726-sup-155@pinkfloyd.chass.utoronto.ca> Message-ID: <1279150063-sup-9876@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Wed Jul 14 18:33:58 -0400 2010: > I'm about to update the buildfarms to current. I'll send another mail > when the updates are complete. This is now complete. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu Jul 15 19:09:54 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 15 Jul 2010 10:09:54 -0700 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: <1279071647-sup-2856@pinkfloyd.chass.utoronto.ca> References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> <1279071647-sup-2856@pinkfloyd.chass.utoronto.ca> Message-ID: On 7/13/10, Ben Walton wrote: > Excerpts from Philip Brown's message of Tue Jul 13 16:02:21 -0400 2010: > >> It's that when users try to do something "interesting" with LC_TIME, >> then almost *all* packages "break", unless there is the symlink from >> LC_TIME->messages. > > If that were true then wouldn't setting LC_TIME to a locale that isn't > currently installed also "break" things? > yes. but there's a difference between, "It doesnt work because there's nothing to work with", vs "it doesnt work, because opencsw didnt put in a little effort to connect the dots to what's already there". > I don't think that's true. > > You're still overlooking the fact that symlinking the directories is > removing the ability of a program to deliver separate .mo files for > the various categories (_CTYPE, _MONETARY and _NUMERIC are also > options a program might use). > Show me a program that delivers a separate .mo file for LC_TIME. An actual FILE, that is different from files it delivers in other directories, rather than a symlink. From bwalton at opencsw.org Thu Jul 15 19:26:22 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 15 Jul 2010 13:26:22 -0400 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> <1279071647-sup-2856@pink floyd.chass.utoronto.ca> Message-ID: <1279214703-sup-3791@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Jul 15 13:09:54 -0400 2010: > yes. but there's a difference between, > "It doesnt work because there's nothing to work with", > vs > "it doesnt work, because opencsw didnt put in a little effort to > connect the dots to what's already there". I guess you do know better than the people that designed gettext/libintl afterall. > Show me a program that delivers a separate .mo file for LC_TIME. An > actual FILE, that is different from files it delivers in other > directories, rather than a symlink. There aren't any (you know because you searched before typing). That's not the point. The point is that there could be. The system allows for it and the kludge you're trying to hold on to breaks this. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Jul 15 19:51:31 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 15 Jul 2010 13:51:31 -0400 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> <1279071647-sup-2856@pink floyd.chass.utoronto.ca> Message-ID: <1279216215-sup-818@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Jul 15 13:09:54 -0400 2010: > > If that were true then wouldn't setting LC_TIME to a locale that isn't > > currently installed also "break" things? > > yes. but there's a difference between, You also missed what I was aiming at here...I'm saying that things _don't_ break if you set LC_TIME to a bad value. At least not anything that I tried broke. Got a counterexample that shows something that _does_ break? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Jul 16 23:43:50 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 16 Jul 2010 14:43:50 -0700 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: <1279216215-sup-818@pinkfloyd.chass.utoronto.ca> References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> <1279216215-sup-818@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Jul 15, 2010 at 10:51 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Jul 15 13:09:54 -0400 2010: > >> > If that were true then wouldn't setting LC_TIME to a locale that isn't >> > currently installed also "break" things? >> >> yes. but there's a difference between, > > You also missed what I was aiming at here...I'm saying that things > _don't_ break if you set LC_TIME to a bad value. ?At least not > anything that I tried broke. ?Got a counterexample that shows > something that _does_ break? > sorry about the misinterpretation of what you wrote. what I wrote is still basically the same either way though. Things dont technically "break" in the crash sense. But they dont "work right". they just revert to as if it was not set in the first place. Would you mind doing a little research&inquiry into why specifically the coreutils people provided those symlinks, please? As in, finding out from them what specifically works, with their links in place, and what breaks,if they are not in place? From bwalton at opencsw.org Sun Jul 18 23:32:09 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 18 Jul 2010 17:32:09 -0400 Subject: [csw-maintainers] Fwd: OpenCSW question about package docbookxsl Message-ID: <1279488689-sup-5889@pinkfloyd.chass.utoronto.ca> Hi All, Is there a good way of dealing with this type of form spam from the Wordpress side? Thanks -Ben --- Begin forwarded message from xqottf --- From: xqottf To: bwalton Date: Sun, 18 Jul 2010 16:13:10 -0400 Subject: OpenCSW question about package docbookxsl BWQWCb pxchmjoxibgh, [url=http://vgdnojivajsd.com/]vgdnojivajsd[/url], [link=http://iwrwxhlkncmn.com/]iwrwxhlkncmn[/link], http://dnogpsxnmekm.com/ --- End forwarded message --- -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Mon Jul 19 00:43:13 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 18 Jul 2010 23:43:13 +0100 Subject: [csw-maintainers] Fwd: OpenCSW question about package docbookxsl In-Reply-To: <1279488689-sup-5889@pinkfloyd.chass.utoronto.ca> References: <1279488689-sup-5889@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 18 de Julho de 2010 22:32, Ben Walton escreveu: > Is there a good way of dealing with this type of form spam from the > Wordpress side? Maybe reCaptcha? From maciej at opencsw.org Mon Jul 19 10:50:53 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 19 Jul 2010 09:50:53 +0100 Subject: [csw-maintainers] New features in checkpkg Message-ID: I've just pushed a relatively big update[1] to checkpkg. Here's the summary of changes: * understands alternative dependencies; if two packages provide foo.so.1, dependency on any of them is sufficient * offers better on-screen messages, e.g. explains the specifics of every soname-not-found error, or a needed dependency * supports $ORIGIN in RPATH, including relative paths such as "$ORIGIN/.." * performance tweaks allow it to process the whole catalog in ~90 minutes including extracting all packages, or in 30 minutes for incremental updates * uses database backend for package stats storage You may purge your whole ~/.checkpkg directories. To get the update, please update your GAR sources. As always, if there are any problems after the update, please contact me on #opencsw or via e-mail. Maciej [1] http://sourceforge.net/apps/trac/gar/changeset/10541 From bwalton at opencsw.org Mon Jul 19 17:22:31 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 19 Jul 2010 11:22:31 -0400 Subject: [csw-maintainers] Fwd: OpenCSW question about package docbookxsl In-Reply-To: References: <1279488689-sup-5889@pinkfloyd.chass.utoronto.ca> Message-ID: <1279552925-sup-7424@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sun Jul 18 18:43:13 -0400 2010: > Maybe reCaptcha? That would be a worthwhile plugin...Any of the wordpress folks think it would be ok to incorporate? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Tue Jul 20 15:43:15 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Jul 2010 14:43:15 +0100 Subject: [csw-maintainers] New features in checkpkg In-Reply-To: References: Message-ID: Just committed two new features: 1. Allowing missing libm.so.2 (64-bit binaries can't find it on Solaris 9 x86). 2. Checking the actual architecture of binaries. There are 3 places in a package which the architecture is declared: the file name, the pkginfo and the content of the binary. So far only the first two were checked. From now on, all three must be in sync for the package to pass. From bonivart at opencsw.org Tue Jul 20 18:04:30 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 20 Jul 2010 18:04:30 +0200 Subject: [csw-maintainers] Problems with ftp.df.lth.se mirror Message-ID: The Swedish mirror has had a major HW-problem and is finally up again but it seems to be unable to sync from us. This is a manual connection they did: klump% rsync rsync.opencsw.org::csw @ERROR: access denied to csw from ftp.df.lth.se (194.47.250.18) rsync error: error starting client-server protocol (code 5) at main.c(1522) [receiver=3.0.3] Do we only allow syncing from certain IP-addresses? They have switched from 194.47.250.22 to .18. -- /peter From phil at bolthole.com Tue Jul 20 18:37:36 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 20 Jul 2010 09:37:36 -0700 Subject: [csw-maintainers] Problems with ftp.df.lth.se mirror In-Reply-To: References: Message-ID: it's whatever they supplied, either name or ip. apparently they previously supplied ip instead of name. do you know if they'd like to switch to name? On Tuesday, July 20, 2010, Peter Bonivart wrote: > The Swedish mirror has had a major HW-problem and is finally up again > but it seems to be unable to sync from us. This is a manual connection > they did: > > klump% rsync rsync.opencsw.org::csw > @ERROR: access denied to csw from ftp.df.lth.se (194.47.250.18) > rsync error: error starting client-server protocol (code 5) at > main.c(1522) [receiver=3.0.3] > > Do we only allow syncing from certain IP-addresses? They have switched > from 194.47.250.22 to .18. > > -- > /peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From bonivart at opencsw.org Tue Jul 20 18:50:50 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 20 Jul 2010 18:50:50 +0200 Subject: [csw-maintainers] Problems with ftp.df.lth.se mirror In-Reply-To: References: Message-ID: On Tue, Jul 20, 2010 at 6:37 PM, Philip Brown wrote: > it's whatever they supplied, either name or ip. > apparently they previously supplied ip instead of name. do you know if > they'd like to switch to name? Name seems more robust. -- /peter From bwalton at opencsw.org Thu Jul 22 03:54:55 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 21 Jul 2010 21:54:55 -0400 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> <1279216215-sup-818@pinkfloyd.chass.utoronto.ca> Message-ID: <1279763277-sup-1503@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Jul 16 17:43:50 -0400 2010: > what I wrote is still basically the same either way though. No. It isn't. What's you've done is wrong. In the technical sense. It goes against the grain of what gettext is trying to provide. > Things dont technically "break" in the crash sense. But they dont > "work right". they just revert to as if it was not set in the first > place. Right. This is the _intended_ behaviour. > Would you mind doing a little research&inquiry into why specifically > the coreutils people provided those symlinks, please? I'm not going to bother them with this. I had previously combed through the code and there are places where they explicitly set the category to LC_TIME though. > As in, finding out from them what specifically works, with their > links in place, and what breaks,if they are not in place? This is doing nothing but wasting my time. I've already read through the gettext docs. The symlinks at the directory level are the wrong approach here. I'll pose a question for you to research instead. What happens if all of the following are true: 1. CSWcommon continues providing the directory level symlinks making LC_TIME/$foo equivalent to LC_MESSAGES/$foo. 2. A package delivers locale files for one of the locales for which #1 above is true. 3. The package in #2 intends to deliver separate .mo files, which is perfectly withing the gettext specifications. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu Jul 22 19:28:32 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 22 Jul 2010 10:28:32 -0700 Subject: [csw-maintainers] BerkeleyDB upgrade In-Reply-To: References: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> <47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org> <515B314C-A719-498C-8861-DF71A52E513B@opencsw.org> <28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org> <89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org> Message-ID: Mrrrr... accidentallysent this only to Maciej. Resending: On 7/22/10, Maciej (Matchek) Blizinski wrote: > No dia 22 de Julho de 2010 15:48, Dagobert Michelsen > escreveu: >> >> is not that exact. Maybe Maciej has a more accurate information about >> packages >> linking to /opt/csw/lib/libdb-4.7.so > > I don't have yet code to create such report, I'm not that far away > from it either. the old search webpage already included that functionality. and happily, the new search appears to have inherited it :) putting in libdb-4.7.so in the file search, and using "exact match", will give you a list of packages that have that specific name in the "NEEDED" section of the ELF header thingamajigs. Currently, that would appear to be: --------- The following packages are depending on the library libdb-4.7.so. Package CSWap2modperl CSWbdb47 CSWirssi CSWmodperl CSWooocore CSWperl CSWpmberkeleydb CSWpython CSWruby From maciej at opencsw.org Thu Jul 22 20:36:31 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 22 Jul 2010 19:36:31 +0100 Subject: [csw-maintainers] BerkeleyDB upgrade In-Reply-To: References: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> <47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org> <515B314C-A719-498C-8861-DF71A52E513B@opencsw.org> <28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org> <89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org> Message-ID: No dia 22 de Julho de 2010 18:28, Philip Brown escreveu: > Mrrrr... accidentallysent this only to Maciej. Resending: > > > On 7/22/10, Maciej (Matchek) Blizinski wrote: >> No dia 22 de Julho de 2010 15:48, Dagobert Michelsen >> escreveu: >>> >>> is not that exact. Maybe Maciej has a more accurate information about >>> packages >>> linking to /opt/csw/lib/libdb-4.7.so >> >> I don't have yet code to create such report, I'm not that far away >> from it either. > > the old search webpage already included that functionality. and > happily, the new search appears to have inherited it :) > > putting in libdb-4.7.so in the file search, and using "exact match", > will give you a list of packages that have that specific name in the > "NEEDED" section of the ELF header thingamajigs. Let's suppose you had a binary needing libdb-4.7.so, with the following RPATH: /opt/csw/lib:/opt/csw/bdb47/lib It would get listed on in your search, even though it doesn't depend on the library in /opt/csw/lib. From phil at bolthole.com Thu Jul 22 21:20:56 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 22 Jul 2010 12:20:56 -0700 Subject: [csw-maintainers] BerkeleyDB upgrade In-Reply-To: References: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> <47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org> <515B314C-A719-498C-8861-DF71A52E513B@opencsw.org> <28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org> <89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org> Message-ID: On 7/22/10, Maciej (Matchek) Blizinski wrote: > No dia 22 de Julho de 2010 18:28, Philip Brown escreveu: > >> >> the old search webpage already included that functionality. and >> happily, the new search appears to have inherited it :) >> >> putting in libdb-4.7.so in the file search, and using "exact match", >> will give you a list of packages that have that specific name in the >> "NEEDED" section of the ELF header thingamajigs. > > Let's suppose you had a binary needing libdb-4.7.so, with the following > RPATH: > > /opt/csw/lib:/opt/csw/bdb47/lib > > It would get listed on in your search, even though it doesn't depend > on the library in /opt/csw/lib. I'm not sure I understand why you are writing this. So, I will add more information and hopefully clear things up. First off, let me say that the existing library search is not "perfect". It does not cover all possible library search cases. However, it does cover a particular set of interest very well: If a library has a unique "SONAME", then it will tell you fairly accurately which packages have something depending on that SONAME. Please note: pure "SONAME". Which is a standalone filename, that has no RPATH component to it.o So, since dbd4.7 does have a unique SONAME of libdb-47.so, it accurately tells us which packages need that library. Which I thought was the original question. It is unfortunately confusing, because the current interface is through the "filename" search field, which is bad and misleading. But that being said, the library dependancy function is quite useful :) From maciej at opencsw.org Fri Jul 23 09:18:28 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 23 Jul 2010 08:18:28 +0100 Subject: [csw-maintainers] BerkeleyDB upgrade In-Reply-To: References: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> <47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org> <515B314C-A719-498C-8861-DF71A52E513B@opencsw.org> <28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org> <89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org> Message-ID: No dia 22 de Julho de 2010 20:20, Philip Brown escreveu: > I'm not sure I understand why you are writing this. So, I will add > more information and hopefully clear things up. > > First off, let me say that the existing library search is not > "perfect". It does not cover all possible library search cases. > However, it does cover a particular set of interest very well: > > If a library has a unique "SONAME", then it will tell you fairly > accurately which packages have something depending on that SONAME. > > Please note: pure "SONAME". ?Which is a standalone filename, that has > no RPATH component to it.o > > So, since dbd4.7 does have a unique SONAME of libdb-47.so, it > accurately tells us which packages need that library. ?Which I thought > was the original question. Close, but not exactly. The original question was: "can we retire CSWbdb?" The follow up question was "which packages would break if the /opt/csw/lib/libdb-4.7.so symlink were removed? The same SONAME is currently provided by two paths, and we're looking for packages with binaries that meet two criteria: 1. need libdb-47.so 2. don't have /opt/csw/bdb47/lib in the RPATH From dam at opencsw.org Fri Jul 23 12:08:30 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 23 Jul 2010 12:08:30 +0200 Subject: [csw-maintainers] Election of a new board References: <253E9EDF-0B03-4DAA-8116-F8916F379DA8@baltic-online.de> Message-ID: Fellow maintainers, first I want to apologize for not pushing the election process of the board earlier as hard as it would have been necessary. To get this thing ahead I have set up a wiki page at http://wiki.opencsw.org/BoardElection where all candidates can introduce themselves and can outline what they intend to do if they are elected. Please set up your applications timely, so the election can take place end of August. Best regards -- Dago From maciej at opencsw.org Fri Jul 23 14:35:50 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 23 Jul 2010 13:35:50 +0100 Subject: [csw-maintainers] BerkeleyDB upgrade In-Reply-To: References: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> <47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org> <515B314C-A719-498C-8861-DF71A52E513B@opencsw.org> <28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org> <89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org> Message-ID: No dia 23 de Julho de 2010 08:18, Maciej (Matchek) Blizinski escreveu: > No dia 22 de Julho de 2010 20:20, Philip Brown escreveu: >> I'm not sure I understand why you are writing this. So, I will add >> more information and hopefully clear things up. >> >> First off, let me say that the existing library search is not >> "perfect". It does not cover all possible library search cases. >> However, it does cover a particular set of interest very well: >> >> If a library has a unique "SONAME", then it will tell you fairly >> accurately which packages have something depending on that SONAME. >> >> Please note: pure "SONAME". ?Which is a standalone filename, that has >> no RPATH component to it.o >> >> So, since dbd4.7 does have a unique SONAME of libdb-47.so, it >> accurately tells us which packages need that library. ?Which I thought >> was the original question. > > Close, but not exactly. ?The original question was: "can we retire > CSWbdb?" ?The follow up question was "which packages would break if > the /opt/csw/lib/libdb-4.7.so symlink were removed?" > > The same SONAME is currently provided by two paths, and we're looking > for packages with binaries that meet two criteria: > > 1. need libdb-47.so > 2. don't have /opt/csw/bdb47/lib in the RPATH I've examined the packages and here are the two packages that would break if CSWbdb were removed: CSWap2modperl CSWmodperl Maciej From dam at opencsw.org Fri Jul 23 14:47:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 23 Jul 2010 14:47:23 +0200 Subject: [csw-maintainers] BerkeleyDB upgrade In-Reply-To: References: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> <47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org> <515B314C-A719-498C-8861-DF71A52E513B@opencsw.org> <28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org> <89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org> Message-ID: <177E6B49-37C0-436F-B247-5A26CDD9DE57@opencsw.org> Hi Maciej, Am 23.07.2010 um 14:35 schrieb Maciej (Matchek) Blizinski: > No dia 23 de Julho de 2010 08:18, Maciej (Matchek) Blizinski > escreveu: >> No dia 22 de Julho de 2010 20:20, Philip Brown >> escreveu: >>> I'm not sure I understand why you are writing this. So, I will add >>> more information and hopefully clear things up. >>> >>> First off, let me say that the existing library search is not >>> "perfect". It does not cover all possible library search cases. >>> However, it does cover a particular set of interest very well: >>> >>> If a library has a unique "SONAME", then it will tell you fairly >>> accurately which packages have something depending on that SONAME. >>> >>> Please note: pure "SONAME". Which is a standalone filename, that >>> has >>> no RPATH component to it.o >>> >>> So, since dbd4.7 does have a unique SONAME of libdb-47.so, it >>> accurately tells us which packages need that library. Which I >>> thought >>> was the original question. >> >> Close, but not exactly. The original question was: "can we retire >> CSWbdb?" The follow up question was "which packages would break if >> the /opt/csw/lib/libdb-4.7.so symlink were removed?" >> >> The same SONAME is currently provided by two paths, and we're looking >> for packages with binaries that meet two criteria: >> >> 1. need libdb-47.so >> 2. don't have /opt/csw/bdb47/lib in the RPATH > > I've examined the packages and here are the two packages that would > break if CSWbdb were removed: > > CSWap2modperl > CSWmodperl Ok, then I'll remove CSWbdb from the current/ on the buildfarm. Best regards -- Dago From phil at bolthole.com Sat Jul 24 02:47:29 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 23 Jul 2010 17:47:29 -0700 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: <1279763277-sup-1503@pinkfloyd.chass.utoronto.ca> References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> <1279216215-sup-818@pinkfloyd.chass.utoronto.ca> <1279763277-sup-1503@pinkfloyd.chass.utoronto.ca> Message-ID: On 7/21/10, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Jul 16 17:43:50 -0400 2010: > >> Would you mind doing a little research&inquiry into why specifically >> the coreutils people provided those symlinks, please? > > I'm not going to bother them with this. I had previously combed > through the code and there are places where they explicitly set the > category to LC_TIME though. Okay, so then you know for a fact that having "LC_TIME" properly supported, is useful. .... > >> As in, finding out from them what specifically works, with their >> links in place, and what breaks,if they are not in place? > > This is doing nothing but wasting my time. I've already read through > the gettext docs. The symlinks at the directory level are the wrong > approach here. that's your opinion. I have a different opinion. I am open to listening to further facts on why you have your opinion. But it seems you are not interested in gathering more facts. I'll pose a question for you to research instead. > What happens if all of the following are true: > > 1. CSWcommon continues providing the directory level symlinks making > LC_TIME/$foo equivalent to LC_MESSAGES/$foo. > 2. A package delivers locale files for one of the locales for which #1 > above is true. > 3. The package in #2 intends to deliver separate .mo files, which is > perfectly withing the gettext specifications. > Then I'd be happy to reconsider things. Given, however, that this has not happened in the (6?) (7?) years i've been doing this, I'm thinking this is quite unlikely :) So until either that happens, or you wish to dig up more information on why coreutils decided on using symlinks instead of separate files AND that information indicates the current cswcommon behaviour is bad... current behaviour will stay. WIth the addition that cswcommon should be modified to have ALL LC_TIME dirs symlinked, rather than only partially. From bonivart at opencsw.org Sat Jul 24 21:27:13 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 24 Jul 2010 21:27:13 +0200 Subject: [csw-maintainers] Problem with mirror updates? Message-ID: Despite a bunch of packages being "batched" the last few days I see no updates on the mirrors since July 15th. -- /peter From phil at bolthole.com Sun Jul 25 00:46:49 2010 From: phil at bolthole.com (Philip Brown) Date: Sat, 24 Jul 2010 15:46:49 -0700 Subject: [csw-maintainers] Problem with mirror updates? In-Reply-To: References: Message-ID: awwright. I was hoping to get a fixed version of unbound for this batch but I guess I'll release it now anyway On Saturday, July 24, 2010, Peter Bonivart wrote: > Despite a bunch of packages being "batched" the last few days I see no > updates on the mirrors since July 15th. > > -- > /peter > _______________________________________________ > 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 Sun Jul 25 17:17:11 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 25 Jul 2010 11:17:11 -0400 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> <1279216215-sup-818@pinkf loyd.chass.utoronto.ca> <1279763277-sup-1503@pinkfloyd.chass.utoronto.ca> Message-ID: <1280067662-sup-5757@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Jul 23 20:47:29 -0400 2010: > > I'm not going to bother them with this. I had previously combed > > through the code and there are places where they explicitly set the > > category to LC_TIME though. > > Okay, so then you know for a fact that having "LC_TIME" properly > supported, is useful. > .... Right. The key word here is properly. I'm aiming for a solution that is both functional _and_ future proof. The proposal is also in the spirit of how gettext is intended to work. > >> As in, finding out from them what specifically works, with their > >> links in place, and what breaks,if they are not in place? > > > > This is doing nothing but wasting my time. I've already read through > > the gettext docs. The symlinks at the directory level are the wrong > > approach here. > > > that's your opinion. I have a different opinion. > I am open to listening to further facts on why you have your opinion. > But it seems you are not interested in gathering more facts. What are you talking about? I'm the only one that has brought facts into this discussion. You're resorting to hand-waving, undefined references to vague memories of why you added these links and decisions by fiat. (Sadly the third is expected behaviour...the first two are what I find out of character here.) I on the other hand have read the gettext docs, an action which I think is more germane to the issue than pestering the coreutils folks about their specific use of gettext. After all, we're discussing a gettext problem here, not a coreutils problem. The coreutils package simply brought to light the error. Have you, by the way, read the gettext docs? Recently? I've clearly outlined why your solution is wrong, why it hasn't yet harmed anything and why my proposed solution is better technically. (That is in addition to being less work overall, btw.) You seem stuck on the fact that providing symlinks at the directory level is somehow going to magically improve the gettext capability of all packages. It won't. It only 'fixes' packages which have a defect in that they set a category for gettext and then fail to provide .mo files there. This is a package bug. In every day use though, it's no different than when a program is only partially translated. Programs don't crash when you set the locale to a value for which your app hasn't provided .mo files...regardless of the category. > > 1. CSWcommon continues providing the directory level symlinks making > > LC_TIME/$foo equivalent to LC_MESSAGES/$foo. > > 2. A package delivers locale files for one of the locales for which #1 > > above is true. > > 3. The package in #2 intends to deliver separate .mo files, which is > > perfectly withing the gettext specifications. > > > > Then I'd be happy to reconsider things. > > Given, however, that this has not happened in the (6?) (7?) years i've > been doing this, I'm thinking this is quite unlikely :) It has happened now. CSWcoreutils is using the gettext system in a valid manner and your actions in CSWcommon have caused a conflict. A symlink is a separate file. The directory level symlinks prevent a package from delivering files in a manner consistent with what gettext allows for. > So until either that happens, or you wish to dig up more information > on why coreutils decided on using symlinks instead of separate files > AND that information indicates the current cswcommon behaviour is > bad... current behaviour will stay. WIth the addition that > cswcommon should be modified to have ALL LC_TIME dirs symlinked, > rather than only partially. Why short change the system here? What makes LC_TIME more special than LC_NUMERIC and the other various categories? Your argument is flaky. It's like saying: I know this function has a segfault but nobody calls this function with arguments that trigger the crash. I'm not fixing the segfault... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Mon Jul 26 13:00:28 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 26 Jul 2010 13:00:28 +0200 Subject: [csw-maintainers] BerkeleyDB upgrade In-Reply-To: <177E6B49-37C0-436F-B247-5A26CDD9DE57@opencsw.org> References: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> <47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org> <515B314C-A719-498C-8861-DF71A52E513B@opencsw.org> <28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org> <89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org> <177E6B49-37C0-436F-B247-5A26CDD9DE57@opencsw.org> Message-ID: many thanks, now it gets one step further. the error is that configure tries to use an old db_open (dbopen) ... but i could not figure out where it gets the idea to try this: rupert at current9s:~/mgar/pkg/apr-util/trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9 $ /opt/studio/SOS12/SUNWspro/bin/cc -o conftest -xO3 -m32 -xarch=v8 -xnorunpath -mt -I/opt/csw/include -DSOLARIS2=9 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE -I/opt/csw/bdb47/include -m32 -xarch=v8 -norunpath -L/opt/csw/lib -L/opt/csw/bdb47/lib conftest.c -ldb -lrt cc: Warning: illegal option -norunpath "conftest.c", line 33: warning: statement not reached Undefined first referenced symbol in file dbopen conftest.o ld: fatal: Symbol referencing errors. No output written to conftest and one hint was there: http://old.nabble.com/undefined-symbol-dbopen-for-BerkeleyDB.4.7-td20439750.html and another hint here: http://monkey.org/~dugsong/dsniff/faq.html#Make%20dies%20with%20undefined%20symbol%20{{EX:dbopen}}%20or%20{{EX:__db185_open}}%22 2.5. Make dies with undefined symbol dbopen or __db185_open"? Be sure to build Berkeley DB with ./configure --enable-compat185. the program is: $ cat conftest.c /* confdefs.h. */ #define PACKAGE_NAME "" #define PACKAGE_TARNAME "" #define PACKAGE_VERSION "" #define PACKAGE_STRING "" #define PACKAGE_BUGREPORT "" #define STDC_HEADERS 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_MEMORY_H 1 #define HAVE_STRINGS_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_UNISTD_H 1 #define HAVE_LBER_H 1 #define HAVE_LDAP_H 1 #define LDAP_SET_REBIND_PROC_THREE 1 /* end confdefs.h. */ /* Override any GCC internal prototype to avoid an error. Use char because int might match the return type of a GCC builtin and then its argument prototype would still apply. */ #ifdef __cplusplus extern "C" #endif char dbopen (); int main () { return dbopen (); ; return 0; } On Fri, Jul 23, 2010 at 14:47, Dagobert Michelsen wrote: > Hi Maciej, > > Am 23.07.2010 um 14:35 schrieb Maciej (Matchek) Blizinski: >> >> No dia 23 de Julho de 2010 08:18, Maciej (Matchek) Blizinski >> escreveu: >>> >>> No dia 22 de Julho de 2010 20:20, Philip Brown >>> escreveu: >>>> >>>> I'm not sure I understand why you are writing this. So, I will add >>>> more information and hopefully clear things up. >>>> >>>> First off, let me say that the existing library search is not >>>> "perfect". It does not cover all possible library search cases. >>>> However, it does cover a particular set of interest very well: >>>> >>>> If a library has a unique "SONAME", then it will tell you fairly >>>> accurately which packages have something depending on that SONAME. >>>> >>>> Please note: pure "SONAME". ?Which is a standalone filename, that has >>>> no RPATH component to it.o >>>> >>>> So, since dbd4.7 does have a unique SONAME of libdb-47.so, it >>>> accurately tells us which packages need that library. ?Which I thought >>>> was the original question. >>> >>> Close, but not exactly. ?The original question was: "can we retire >>> CSWbdb?" ?The follow up question was "which packages would break if >>> the /opt/csw/lib/libdb-4.7.so symlink were removed?" >>> >>> The same SONAME is currently provided by two paths, and we're looking >>> for packages with binaries that meet two criteria: >>> >>> 1. need libdb-47.so >>> 2. don't have /opt/csw/bdb47/lib in the RPATH >> >> I've examined the packages and here are the two packages that would >> break if CSWbdb were removed: >> >> CSWap2modperl >> CSWmodperl > > Ok, then I'll remove CSWbdb from the current/ on the buildfarm. > > > Best regards > > ?-- Dago > > From dam at opencsw.org Mon Jul 26 13:14:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 26 Jul 2010 13:14:00 +0200 Subject: [csw-maintainers] BerkeleyDB upgrade In-Reply-To: References: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> <47B9E89A-9C18-442E-958F-7AF486387A7D@opencsw.org> <515B314C-A719-498C-8861-DF71A52E513B@opencsw.org> <28D3717A-89F4-4FF7-9C25-FEAC80002BB7@opencsw.org> <89934547-D626-4CBA-92EC-F816834AE55E@opencsw.org> <177E6B49-37C0-436F-B247-5A26CDD9DE57@opencsw.org> Message-ID: <91F3A15F-74C5-4248-A017-11B73F7D4AF1@opencsw.org> Hi Rupert, Am 26.07.2010 um 13:00 schrieb rupert THURNER: > many thanks, now it gets one step further. the error is that configure > tries to use an old db_open (dbopen) ... but i could not figure out > where it gets the idea to try this: Please commit what you have and tell me the svn path so I can have a look. Best regards -- Dago From maciej at opencsw.org Wed Jul 28 00:50:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 27 Jul 2010 23:50:00 +0100 Subject: [csw-maintainers] unixodbc-2.3.0 is available for testing Message-ID: Are there any unixodbc users here? Version 2.3.0 (updated from 2.2.14) is available for testing: http://mirror.opencsw.org/experimental.html#maciej Maciej From bwalton at opencsw.org Wed Jul 28 01:50:07 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 27 Jul 2010 19:50:07 -0400 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> <1279216215-sup-818@pinkf loyd.chass.utoronto.ca> <1279763277-sup-1503@pinkfloyd.chass.utoronto.ca> Message-ID: <1280274477-sup-699@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Jul 23 20:47:29 -0400 2010: > that's your opinion. I have a different opinion. > I am open to listening to further facts on why you have your opinion. > But it seems you are not interested in gathering more facts. More facts have now been gathered. This is from the gettext list: --snip-- From: Bruno Haible Subject: Re: a question about distribution packaging Date: Wed, 28 Jul 2010 01:31:56 +0200 References: <1280191508-sup-3360 at pinkfloyd.chass.utoronto.ca> In-Reply-To: <1280191508-sup-3360 at pinkfloyd.chass.utoronto.ca> Message-Id: <201007280131.57776.bruno at clisp.org> Hi, Ben Walton wrote: > I'm hoping that someone can provide an authoritative answer on whether > or not it is valid to ship $share_dir/locale/$LANG/LC_TIME (or > LC_NUMERIC, etc) as a symlink pointed at LC_MESSAGES. > > My viewpoint after reading the docs is that the symlink at the > directory level is not valid. While it's rare (and somewhat > discouraged) that a package would deliver a separate .mo file in the > LC_TIME directory, it is valid for the package to do so. The > directory-level symlink would prevent distributing separate .mo files. I agree with your viewpoint. In a private discussion with Paul Eggert from 2002-01-15 to 2002-01-17, I came to the same conclusion and added the EXTRA_LOCALE_CATEGORIES to the Makevars file for po/ directories. coreutils uses this hook as a way of installing a file into $share_dir/locale/$LANG/LC_TIME since November 2002. > The alternate viewpoint is that LC_TIME symlinks haven't harmed > anything in the 6+ years they've been shipped this way, so continuing > (and expanding) the practice is acceptable. A package can decide to install different .mo files in $share_dir/locale/$LANG/LC_MESSAGES/domain.mo $share_dir/locale/$LANG/LC_TIME/domain.mo The gettext Makefile infrastructure currently does not support this situation (it only supports installing the same .mo file as $share_dir/locale/$LANG/LC_MESSAGES/domain.mo $share_dir/locale/$LANG/LC_TIME/domain.mo) but packages could get into this situation if they use their own Makefiles. A single package that puts a symlink from LC_TIME to LC_MESSAGES breaks all other packages that want to use this approach. Therefore it is not a good idea to put this symlink. Bruno --snip-- Good enough? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Jul 28 09:26:13 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Jul 2010 09:26:13 +0200 Subject: [csw-maintainers] Packaging up OraToolkit In-Reply-To: <4C4F0F0C.5000205@opencsw.org> References: <4C4A011F.40304@opencsw.org> <15137A99-519A-4DCA-9F4D-9EC91318BD31@opencsw.org> <4C4F0F0C.5000205@opencsw.org> Message-ID: Hi David, (adding maintainers@ to see if more people are interested in the package) Am 27.07.2010 um 18:53 schrieb David D'Acquisto: > Dagobert Michelsen wrote: >> Am 23.07.2010 um 22:52 schrieb David D'Acquisto: >>> i was considering packing my open source project www.oratoolkit.ch >>> with OpenCSW. >>> >>> Unfortunately I came to the result that I do not have many benefits. >> >> What kind of benefits did you expect? Of course your package will >> be much easier to >> install for admins using OpenCSW. >> > > Yes, this could be but when I meet Ihsan once he told me that with > OpenCSW there are some constraints which you have to follow. As far > as I know the installation directory has to be in /opt/opencsw or > whereever and the thing is that i am supporting different platforms > like Linux, AIX, HP-UX and Solaris. To make it easy I kept the > installation path for all platforms the same and choosed /opt/oracle/ > otk as the base install directory. Correct. This is for consistency of the OpenCSW environment in total. > This also because I am using appctl framework (http://appctl.sourceforge.net > ) which I am quite familiar. I see. On Solaris the integration in the system-wide SMF would be favorable as all Solaris admins must know that anyway and the functionality is comparable. > When I say that I don't see many benefits from it then you should > also look it from package maintainer / developer point of view. This > is related with some work effort and I see there not many benefits > of supporting two packaging frameworks for Solaris. Time is precious > and therefore it makes for me only sense that someone who is > familiar with OpenCSW and Oracle should be responsible for the > package maintenance. I have the feeling that I am definitely the > wrong one. I understand your problem. For myself I maintain the SE Toolkit and indeed make two kinds of packages: the "legacy" one which installs into /opt/RICHPse as it always has been and an OpenCSW one with OpenCSW standard pathes. > As written in the last email I am however willing to contribute and > to make software changes to support it but not willing to take the > lead in the package maintenance. So, tell me how we proceed. This is great. I'll see that we find someone to package it. Jochen? ;-) >>> With this email I would like to say that you can delete my >>> account daviddac. Furthermore if there will be one day a package >>> maintainer interested in maintaining oratoolkit with OpenCSW then >>> feel free to contact me. >> >> This my indeed be the case. Best regards -- Dago From dam at opencsw.org Wed Jul 28 09:31:13 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Jul 2010 09:31:13 +0200 Subject: [csw-maintainers] Updating libfaad2 and mpeg4ip In-Reply-To: <1280278827-sup-1945@pinkfloyd.chass.utoronto.ca> References: <1280278827-sup-1945@pinkfloyd.chass.utoronto.ca> Message-ID: Hi, Am 28.07.2010 um 03:01 schrieb Ben Walton: > Excerpts from Maciej (Matchek) Blizinski's message of Tue Jul 27 > 02:11:27 -0400 2010: > >> Can we remove the xmms package from the buildfarm? > > It's now removed, but this left a dangling dependency. CSWfaad2 > depends on xmms which I found strange. Then I looked at the file list > delivered. faad2 is dropping in: > > /opt/csw/lib/xmms > /opt/csw/lib/xmms/Input > /opt/csw/lib/xmms/Input/libmp4.a > /opt/csw/lib/xmms/Input/libmp4.la > /opt/csw/lib/xmms/Input/libmp4.so > > This should have been shipped as a separate faad2-xmms package. I'm > not going to worry about this. Right. I made an approach to redo it but mpeg4ip is missing which needs some in-depth know how about autoconf as some serious patching is required. If someone is interested to help just let me know and I can point out the specific issue there. Best regards -- Dago From dam at opencsw.org Wed Jul 28 09:42:15 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Jul 2010 09:42:15 +0200 Subject: [csw-maintainers] packaging gems In-Reply-To: <1280286258-sup-3785@pinkfloyd.chass.utoronto.ca> References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca> <1280286258-sup-3785@pinkfloyd.chass.utoronto.ca> Message-ID: <672BC96C-3532-4397-8C56-569621C38FC0@opencsw.org> Hi Ben, Am 28.07.2010 um 05:05 schrieb Ben Walton: > Excerpts from Ben Walton's message of Tue Jul 27 20:47:49 -0400 2010: > >> http://fedoraproject.org/wiki/Packaging/Ruby > > I've done some more groundwork (based on the rbgems category you > started this morning Dago) toward getting gem packages. > > More to be done yet, but I was able to crank out a package from > gem-rake/trunk. Like for the CPAN stuff I introduced a new directory pkg/rbgems so the directory names can keep the original GEM name. I noticed you removed the forced addition of the GEM name to SPKG_DESC. I added that to conform to the CPAN convention. Did you have a specific reason for removing it? I find it valuable to have the original GEM name in the description so I can grep for it on "pkginfo". Best regards -- Dago From dam at opencsw.org Wed Jul 28 09:45:33 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Jul 2010 09:45:33 +0200 Subject: [csw-maintainers] packaging gems In-Reply-To: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca> References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca> Message-ID: <9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org> Hi Ben, Am 28.07.2010 um 02:47 schrieb Ben Walton: > Since you've both expressed interest in this recently, would you mind > reading the gem-specific bits of the following guide from the fedora > project? > > http://fedoraproject.org/wiki/Packaging/Ruby > > I'm curious about why they move the .so files out of the gemdir and > into the sitearch dir. Do you have any ideas about why this would be > beneficial...? Sorry, no clue. We could easily mimic this by looking into ARCHALL and then setting the parameter accordingly. BTW, there is http://rubyforge.org/projects/gem2rpm/ Maybe this can be used to rip out the dependencies and stuff to make an initial GAR Makefile? Best regards -- Dago From dam at opencsw.org Wed Jul 28 12:19:25 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Jul 2010 12:19:25 +0200 Subject: [csw-maintainers] Packaging Ruby GEMs Message-ID: Hi, I just started a new project: http://mirror.opencsw.org/experimental.html#rubygems Anybody feel free to jump in! Best regards -- Dago From bwalton at opencsw.org Thu Jul 29 05:07:56 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 28 Jul 2010 23:07:56 -0400 Subject: [csw-maintainers] packaging gems In-Reply-To: <1280367168-sup-198@pinkfloyd.chass.utoronto.ca> References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca> <9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org> <1280367168-sup-198@pinkfloyd.chass.utoronto.ca> Message-ID: <1280372747-sup-1107@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Wed Jul 28 22:07:08 -0400 2010: > How about the attached script? It likely needs a bit of work yet, but > it hits the basics. A small update to use the exposed Gems api to grab the spec file instead of spawning `gem specification ...` externally. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- next part -------------- A non-text attachment was scrubbed... Name: gem2pkg Type: application/octet-stream Size: 871 bytes Desc: not available URL: From phil at bolthole.com Fri Jul 30 02:19:09 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 29 Jul 2010 17:19:09 -0700 Subject: [csw-maintainers] Updating libfaad2 and mpeg4ip In-Reply-To: References: <1280278827-sup-1945@pinkfloyd.chass.utoronto.ca> Message-ID: xmms is ugly. and somewhat orphaned I heard. and there is xmms2. and... its messy. so anyone else is hereby cordially invited to take it over :-D On 7/28/10, Dagobert Michelsen wrote: > Hi, > > Am 28.07.2010 um 03:01 schrieb Ben Walton: >> Excerpts from Maciej (Matchek) Blizinski's message of Tue Jul 27 >> 02:11:27 -0400 2010: >> >>> Can we remove the xmms package from the buildfarm? >> >> It's now removed, but this left a dangling dependency. CSWfaad2 >> depends on xmms which I found strange. Then I looked at the file list >> delivered. faad2 is dropping in: >> >> /opt/csw/lib/xmms >> /opt/csw/lib/xmms/Input >> /opt/csw/lib/xmms/Input/libmp4.a >> /opt/csw/lib/xmms/Input/libmp4.la >> /opt/csw/lib/xmms/Input/libmp4.so >> >> This should have been shipped as a separate faad2-xmms package. I'm >> not going to worry about this. > > Right. I made an approach to redo it but mpeg4ip is missing which > needs some > in-depth know how about autoconf as some serious patching is required. > If someone is interested to help just let me know and I can point out > the > specific issue there. > > > Best regards > > -- Dago > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From phil at bolthole.com Fri Jul 30 02:29:02 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 29 Jul 2010 17:29:02 -0700 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: <1280067662-sup-5757@pinkfloyd.chass.utoronto.ca> References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> <1279763277-sup-1503@pinkfloyd.chass.utoronto.ca> <1280067662-sup-5757@pinkfloyd.chass.utoronto.ca> Message-ID: On 7/25/10, Ben Walton wrote: > > I on the other hand have read the gettext docs, an action which I > think is more germane to the issue than pestering the coreutils folks > about their specific use of gettext. I see that you didnt seem to want to "bother" them about why they are doing what they do, but you seem fine bothering them to ask an opinion about what I'm doing. This seems inappropriate to me. >... >> Given, however, that this has not happened in the (6?) (7?) years i've >> been doing this, I'm thinking this is quite unlikely :) > > It has happened now. CSWcoreutils is using the gettext system in a > valid manner and your actions in CSWcommon have caused a conflict. A > symlink is a separate file. No it is not a "file". it is a symlink. I chose my words very specifically. While what you say is true in the context of OS implementation, we're talking about packaging. In the context of packaging, a file is not a symlink. "s" vs "f", after all. >> So until either that happens, or you wish to dig up more information >> on why coreutils decided on using symlinks instead of separate files >> AND that information indicates the current cswcommon behaviour is >> bad... current behaviour will stay. WIth the addition that >> cswcommon should be modified to have ALL LC_TIME dirs symlinked, >> rather than only partially. > > Why short change the system here? What makes LC_TIME more special > than LC_NUMERIC and the other various categories? Go ask the coreutils people that first, why THEY decide to add a symlink for it, and thus *they* think LC_TIME is "more special than LC_NUMERIC and the other various categories". You've already seen fit to bug them once already now. You seem to think their opinion is more valid than mine here; so then, ask them their opinion on why THEY think this also! Meanwhile, I'm updating common to at least be consistent with the symlinks, as I said i would. From dam at opencsw.org Fri Jul 30 15:33:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 30 Jul 2010 15:33:00 +0200 Subject: [csw-maintainers] bad interactions with CSWcommon In-Reply-To: References: <1276917687-sup-6307@pinkfloyd.chass.utoronto.ca> <1276994755-sup-5700@pinkfloyd.chass.utoronto.ca> <1277040073-sup-8018@pinkfloyd.chass.utoronto.ca> <1277042624-sup-3749@pinkfloyd.chass.utoronto.ca> <1277047002-sup-479@pinkfloyd.chass.utoronto.ca> <1277163839-sup-3934@pinkfloyd.chass.utoronto.ca> <1278694982-sup-8536@pinkfloyd.chass.utoronto.ca> <1278720335-sup-4347@pinkfloyd.chass.utoronto.ca> <1279039635-sup-5121@pinkfloyd.chass.utoronto.ca> <1279763277-sup-1503@pinkfloyd.chass.utoronto.ca> <1280067662-sup-5757@pinkfloyd.chass.utoronto.ca> Message-ID: <1C65B122-CECE-49F7-8C83-784091BBCB3C@opencsw.org> Hi, Am 30.07.2010 um 02:29 schrieb Philip Brown: > On 7/25/10, Ben Walton wrote: >> >> I on the other hand have read the gettext docs, an action which I >> think is more germane to the issue than pestering the coreutils folks >> about their specific use of gettext. > > I see that you didnt seem to want to "bother" them about why they are > doing what they do, > but you seem fine bothering them to ask an opinion about what I'm > doing. > This seems inappropriate to me. Bruno has a vast knowledge in this area (to be exact, he is the upstream maintainer of GNU gettext). If he says "don't make symlinks" than it is definitely the right thing to not make symlinks. At least this sounds like a better argument than "we introduced it for reasons long forgotten and never had a problem until now and therefore spread what we have and ignore the problem that just arose as it can be worked around". Best regards -- Dago From maciej at opencsw.org Fri Jul 30 15:42:54 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 30 Jul 2010 14:42:54 +0100 Subject: [csw-maintainers] Maciej on vacations until the 11th of August Message-ID: I'm going for vacations starting today, and I'll be back on-line on the 11th of August. Maciej From bwalton at opencsw.org Thu Jul 29 04:07:08 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 28 Jul 2010 22:07:08 -0400 Subject: [csw-maintainers] packaging gems In-Reply-To: <9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org> References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca> <9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org> Message-ID: <1280367168-sup-198@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Jul 28 03:45:33 -0400 2010: > BTW, there is > http://rubyforge.org/projects/gem2rpm/ > Maybe this can be used to rip out the dependencies and stuff to make > an initial GAR Makefile? How about the attached script? It likely needs a bit of work yet, but it hits the basics. There is a wrinkle with gem packaging that I alluded to in irc...dependency hell the likes the world hasn't seen in a long time. Gems can declare dependencies on other gems, including locking down to a specific version of that gem. While it's easy to say "ok, we'll just ensure we always update in steps that 'fit'" that won't work in practice as you may find things like (encountered today): redmine depends on the gem rack = 1.0.1 and complains loudly if you have some other version. It also depends on rails 2.3.5 and does the same. So...ok, no problem, we'll package multiple versions of gems. How do we do this sanely? Would our rails gem be rails235? Would our rails gems simply deliver rails 2.3.5 and 2.3.8 (current) in a single package? The first is nasty and ambiguous. The second may work, but makes it hard to know when versions can be dropped from the package. We could make the argument that we only package gems that will play nicely with each other, but this could rule out various gems from being packaged. Think of the case where we've already pushed rails (at 2.3.8) and now somebody wants to package redmine[1]. Thoughts? Thanks -Ben [1] This can be worked around as redmine will ship release tarballs with the full rails stack in the vendor/ dir, but that's not the point here. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- next part -------------- A non-text attachment was scrubbed... Name: gem2pkg Type: application/octet-stream Size: 881 bytes Desc: not available URL: