From jeff at cjsa.com Fri Apr 1 22:57:17 2011 From: jeff at cjsa.com (Jeffery Small) Date: Fri, 1 Apr 2011 20:57:17 GMT Subject: [csw-maintainers] apache2 installation issue Message-ID: FYI: I just ran a CSW update. I have apache2 installed here but it is disabled. The update removed CSWapache2rt and CSWapache2 and then installed CSWapache2c and CSWapache2. Apparently CSWWapache2rt is no longer necessary as it contains only two text files. (Aside: apache2 may have been previously installed due to some other package dependency from long ago, but I just checked and currently there does not seem to be anything depending upon it, so I should probably just uninstall the package.) I haven't examined things closely, but apparently there is a post-install script for CSWapache2 that tries to do something, and displayed a message something like: Examining configuration files: and then hung. I'm guessing an expected config file was missing or else the problem was in some attempt to manipulate the service which was not actually running: # svcs -a | grep cswapache2 disabled 13:14:16 svc:/network/cswapache2:default I terminated the installation, which appears to have otherwise been successful. I mention this only so that the post-install script can be examined and improved so as not to hang under these conditions. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From bwalton at opencsw.org Sat Apr 2 02:23:50 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 01 Apr 2011 20:23:50 -0400 Subject: [csw-maintainers] updating buildfarm Message-ID: <1301703740-sup-65@pinkfloyd.chass.utoronto.ca> Hi All, I'm pushing in several updates to the buildfarm... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Apr 2 16:41:39 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 02 Apr 2011 10:41:39 -0400 Subject: [csw-maintainers] apache2 installation issue In-Reply-To: References: Message-ID: <1301753778-sup-1502@pinkfloyd.chass.utoronto.ca> Excerpts from jeff's message of Fri Apr 01 16:57:17 -0400 2011: Hi Jeff, > FYI: I just ran a CSW update. I have apache2 installed here but it > is disabled. The update removed CSWapache2rt and CSWapache2 and > then installed CSWapache2c and CSWapache2. Apparently CSWWapache2rt > is no longer necessary as it contains only two text files. But it did get installed, right? Packages depend on it still, so it can't go away. If it didn't get pulled in, that's an error. > (Aside: apache2 may have been previously installed due to some other > package dependency from long ago, but I just checked and currently > there does not seem to be anything depending upon it, so I should > probably just uninstall the package.) This was one hurdle in getting my update out the door. There are packages that depend on all of: CSWapache2 CSWapache2c CSWapache2rt CSWap2prefork The interdependencies among those made for lots of fun. > I haven't examined things closely, but apparently there is a > post-install script for CSWapache2 that tries to do something, and > displayed a message something like: > > Examining configuration files: The postinstall script for CSWapache2 does: 1. Install config files from .CSW templates if live version not found. 2. Generates a dummy ssl key. 3. Creates the var/run directory if it's not there (in the bad location). There really isn't anything going on that should cause a hang. The service manipulation is done by cswinitsmf when the init script is delivered. That should happen before the postinstall script[1] runs. I need to move template handling to a CAS, but that's something I wanted to address separately since I had enough open issues to deal with for this update. > I terminated the installation, which appears to have otherwise been > successful. I mention this only so that the post-install script can > be examined and improved so as not to hang under these conditions. I don't see anything in your description of this that immediately stands out as a problem. Can you reproduce this on another system? Thanks -Ben [1] If autoenable_daemons is on, starting cswapache2 could fail on a clean installation as the live versions of the config wouldn't be in place, but that doesn't describe your scenario, I don't think. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jeff at cjsa.com Mon Apr 4 02:43:09 2011 From: jeff at cjsa.com (Jeffery Small) Date: Mon, 4 Apr 2011 00:43:09 GMT Subject: [csw-maintainers] apache2 installation issue References: <1301753778-sup-1502@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: >But it did get installed, right? Packages depend on it still, so it >can't go away. If it didn't get pulled in, that's an error. Yes, it appears to have been fully installed -- as best as I can tell without actually running it. >> I haven't examined things closely, but apparently there is a >> post-install script for CSWapache2 that tries to do something, and >> displayed a message something like: >> >> Examining configuration files: >The postinstall script for CSWapache2 does: >1. Install config files from .CSW templates if live version not found. >2. Generates a dummy ssl key. >3. Creates the var/run directory if it's not there (in the bad > location). >There really isn't anything going on that should cause a hang. The >service manipulation is done by cswinitsmf when the init script is >delivered. That should happen before the postinstall script[1] runs. >I need to move template handling to a CAS, but that's something I >wanted to address separately since I had enough open issues to deal >with for this update. I think the best clue is something following the message "Examining configuration files:" or something close to that. Do you see that being printed anywhere during the installation? >I don't see anything in your description of this that immediately >stands out as a problem. >Can you reproduce this on another system? Sorry, but I do not have any other system to try installing this on. If no one else is reporting a problem, then it may just have been a fluke here. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From bwalton at opencsw.org Mon Apr 4 02:50:09 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 03 Apr 2011 20:50:09 -0400 Subject: [csw-maintainers] apache2 installation issue In-Reply-To: References: <1301753778-sup-1502@pinkfloyd.chass.utoronto.ca> Message-ID: <1301878036-sup-5130@pinkfloyd.chass.utoronto.ca> Excerpts from jeff's message of Sun Apr 03 20:43:09 -0400 2011: > >There really isn't anything going on that should cause a hang. The > >service manipulation is done by cswinitsmf when the init script is > >delivered. That should happen before the postinstall script[1] runs. > >I need to move template handling to a CAS, but that's something I > >wanted to address separately since I had enough open issues to deal > >with for this update. > > I think the best clue is something following the message > > "Examining configuration files:" > > or something close to that. Do you see that being printed anywhere > during the installation? Here is the tail end of the script. I guess there is potential to stall if there isn't enough entropy on the system to generate the ssl cert...? I plan to drop the cert generation in a future update, but left it in to reduce the changes in this update as I was focused only on fixing update related bugs with the 2.2.16 release. HTH. -Ben --snip-- echo Copying CSW templates: for file in $template_list do filepath=$AP2_PREFIX/$file if [ -f "$filepath" ]; then echo " preserving $filepath" elif [ -f "$filepath.CSW" ]; then echo " creating $filepath" cp $filepath.CSW $filepath fi done if [ ! -f $AP2_CONFDIR/server.crt -a ! -f $AP2_CONFDIR/server.key ]; then echo Generating dummy ssl key and certificate... # this is likely overkill for a dummy cert, but why not umask 0077 cat </dev/null 2>&1 TS Westfarthing Hobbiton $hostname bilbo at example.net EOF fi --snip-- -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Apr 4 16:13:50 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 04 Apr 2011 10:13:50 -0400 Subject: [csw-maintainers] apache2 installation issue In-Reply-To: References: <1301753778-sup-1502@pinkfloyd.chass.utoronto.ca> Message-ID: <1301926417-sup-5471@pinkfloyd.chass.utoronto.ca> Excerpts from jeff's message of Sun Apr 03 20:43:09 -0400 2011: Hi Jeff, This wasn't by any chance a VM where entropy could be a real issue, was it? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jeff at cjsa.com Mon Apr 4 18:55:10 2011 From: jeff at cjsa.com (Jeffery Small) Date: Mon, 4 Apr 2011 16:55:10 GMT Subject: [csw-maintainers] apache2 installation issue References: <1301753778-sup-1502@pinkfloyd.chass.utoronto.ca> <1301926417-sup-5471@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: >This wasn't by any chance a VM where entropy could be a real issue, >was it? No. This is a straight Solaris 10 installation with no zones. I am running a full set of mirrored disks, but that shouldn't be causing any problem. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From bwalton at opencsw.org Mon Apr 4 19:51:18 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 04 Apr 2011 13:51:18 -0400 Subject: [csw-maintainers] apache2 installation issue In-Reply-To: References: <1301753778-sup-1502@pinkfloyd.chass.utoronto.ca> <1301926417-sup-5471@pinkfloyd.chass.utoronto.ca> Message-ID: <1301939387-sup-5262@pinkfloyd.chass.utoronto.ca> Excerpts from jeff's message of Mon Apr 04 12:55:10 -0400 2011: > No. This is a straight Solaris 10 installation with no zones. I am > running a full set of mirrored disks, but that shouldn't be causing > any problem. Ok. Would have been a nice (easy) explanation, but oh well. Once I get a few other things squared away I'll come back to apache and tackle the directory moves. Some of the changes that will be added then should make the postinstall script smaller, so this might just disappear. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Apr 7 21:23:09 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 07 Apr 2011 15:23:09 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs rb18_libxml_1_1_4 In-Reply-To: References: <201104061427.p36ERL8Z007069@login.bo.opencsw.org> Message-ID: <1302204001-sup-2534@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Apr 07 14:20:33 -0400 2011: > This is a new naming scheme. Yes, it's borne out of the ruby dublin discussions. > seems like we should have documentation for, and agreement on, this > new standard, before releasing stuff like that. http://wiki.opencsw.org/ruby-dublin > Or, if you want to just release something without need for discussion, > seems like > ruby18_libxml_ The rb_ standard was good and this is the logical extension of the prefix for a world where a gem will be for 1.8 or 1.9. The new naming scheme also allows for multiple gem versions to live on the system at once (the same capability that gem offers if you install manually). This eases the update burden over time as we don't need to provide a transition path from one set of gems (think rails) to another, where the upstream community has made incompatible changes. It's basically the same idea that drives our library splitting. Discuss. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu Apr 7 23:08:19 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 7 Apr 2011 14:08:19 -0700 Subject: [csw-maintainers] newpkgs rb18_libxml_1_1_4 In-Reply-To: <1302204001-sup-2534@pinkfloyd.chass.utoronto.ca> References: <201104061427.p36ERL8Z007069@login.bo.opencsw.org> <1302204001-sup-2534@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Apr 7, 2011 at 12:23 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Apr 07 14:20:33 -0400 2011: >... > >> seems like we should have documentation for, and agreement on, this >> new standard, before releasing stuff like that. > > http://wiki.opencsw.org/ruby-dublin Thanks for the ref... That page is very short. I would suggest that in a complex topic such as this, it is best for such writeups to have as much "why" details, as "what". Did you guys compare to what debian is doing in this space? There are some interesting comments on that, at http://stackoverflow.com/questions/2846804/whats-the-deal-with-rubygems-on-debian-its-different-and-strange > The rb_ standard was good and this is the logical extension of the > prefix for a world where a gem will be for 1.8 or 1.9. > > The new naming scheme also allows for multiple gem versions to live on > the system at once (the same capability that gem offers if you install > manually). ?This eases the update burden over time as we don't need to > provide a transition path from one set of gems (think rails) to > another, where the upstream community has made incompatible changes. > It's basically the same idea that drives our library splitting. I think it's worth noticing, that not even debian, with its "lets try to cater to everything, and everyone", attempts to support rubygems for two completely different versions of ruby. This suggests to me, that this is potentially Not A Good Idea. It may be better to simply declare, "Right now, we support version [X] of ruby+rubygems. If you want to go your own way,with a different version /combination of ruby+rubygems... we suggest you use rubygems, AS rubygems: ie: as its own package management and download system. [and we might optionally provide some kind of convenience package for that]" the comment on the URL I reference above, has this to say on the topic: "In general, you should avoid mixing package managers. Either use RubyGems for everything (in which case it is best to install RubyGems from source instead of using the Debian package) or use APT for everything, in which case you might be interested in DebGem, a service by the Phusion guys (makers of Ruby Enterprise Edition and Phusion Passenger) which provides Debian and Ubuntu packages for pretty much all Gems." This would match with our perl/cpan strategy. we dont attempt to support multiple versions of cpan, with multiple versions of perl. For any particular cpan module, we have ONE version of it, for our ONE version of officially suported perl. From rupert at opencsw.org Sat Apr 9 13:16:27 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 9 Apr 2011 13:16:27 +0200 Subject: [csw-maintainers] CSWpy_mercurial - checkpkg gone wild? Message-ID: hi, when doing a minor upgrade to mercurial, checkpackage somehow got the idea mercurial should be named now py_mercurial. was there an issue filed against py_checkpackage that says it should get english_implemented like this, or in other english_words, english_who english_checks py_checkpackage? name_rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Apr 9 14:42:39 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 09 Apr 2011 08:42:39 -0400 Subject: [csw-maintainers] CSWpy_mercurial - checkpkg gone wild? In-Reply-To: References: Message-ID: <1302352702-sup-206@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat Apr 09 07:16:27 -0400 2011: Hi Rupert, > when doing a minor upgrade to mercurial, checkpackage somehow got > the idea mercurial should be named now py_mercurial. was there an > issue filed against py_checkpackage that says it should get > english_implemented like this, or in other english_words, > english_who english_checks py_checkpackage? The CSWpy-somepkg/py_somepkg is the generally agreed upon convention for naming. It lines up with CSWpm-otherpkg/pm_otherpkg, CSWrb18-newgem/rb18_newgem, CSWphp5-module/php5_module, etc. More generally, it lines up with the preference to use hyphen and underscore to separate parts of names -doc/_doc, -dev/_doc, etc. You can easily rename an existing package by doing: PACKAGES += CSWpy-newpkg OBSOLETED_BY_CSWpy-newpkg = CSWpyoldpkg I don't see pymercurial listed on our packages page though, so that's either not an issue for you or there is a missing/messed up database entry. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Apr 9 21:16:27 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 9 Apr 2011 20:16:27 +0100 Subject: [csw-maintainers] CSWpy_mercurial - checkpkg gone wild? In-Reply-To: <1302352702-sup-206@pinkfloyd.chass.utoronto.ca> References: <1302352702-sup-206@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/4/9 Ben Walton : > I don't see pymercurial listed on our packages page though, so that's > either not an issue for you or there is a missing/messed up database > entry. One thing comes to mind, although it's not related to checkpkg: r13581. I've made a change[1] to the python category: if PACKAGES is not present, it's automatically set to CSWpy-$(DASHED_NAME), where DASHED_NAME is NAME with all special characters converted to dashes. If the mercurial build used the python category, it may have been affected by that change. If that's the case, PACKAGES = CSWmercurial should fix the problem. Maciej [1] http://sourceforge.net/apps/trac/gar/changeset/13581 From bwalton at opencsw.org Wed Apr 13 02:03:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 12 Apr 2011 20:03:20 -0400 Subject: [csw-maintainers] cswutils in experimental Message-ID: <1302652964-sup-3754@pinkfloyd.chass.utoronto.ca> Hi All, If you use the cswutils package, please test the update I've placed in the cswutils experimental repo on the buildfarm. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From skayser at opencsw.org Wed Apr 13 12:55:29 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 13 Apr 2011 12:55:29 +0200 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? Message-ID: <20110413105529.GB17736@sebastiankayser.de> Hi, in some setups, I am sitting behind a rsync'ed local copy of our mirror. The rsync job is not within my administrative realm and in case there are problems with it, I might see a stale catalog. Now to spot such cases, it would be helpful to see the catalog generation date. The catalog file itself doesn't seem to contain the date directly, though the GPG signature could be used to determine the sign date (which doesn't have to be equal to the generation date). Would it be possible to integrate the generation date into the catalog during build time? And what do you think about integrating this date information in pkgutil -V output (or similar)? Sebastian From skayser at opencsw.org Wed Apr 13 13:07:35 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 13 Apr 2011 13:07:35 +0200 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <20110413105529.GB17736@sebastiankayser.de> References: <20110413105529.GB17736@sebastiankayser.de> Message-ID: <20110413110735.GC17736@sebastiankayser.de> * Sebastian Kayser wrote: > in some setups, I am sitting behind a rsync'ed local copy of our mirror. > The rsync job is not within my administrative realm and in case there > are problems with it, I might see a stale catalog. > > Now to spot such cases, it would be helpful to see the catalog > generation date. The catalog file itself doesn't seem to contain the > date directly, though the GPG signature could be used to determine the > sign date (which doesn't have to be equal to the generation date). > > Would it be possible to integrate the generation date into the catalog > during build time? And what do you think about integrating this date > information in pkgutil -V output (or similar)? A page/box/section on opencsw.org with the generation date for all of our catalogs (like the one from James [1]) would be neat too! Sebastian [1] http://opencsw.oxdrove.co.uk/packages/ From james at opencsw.org Wed Apr 13 13:46:48 2011 From: james at opencsw.org (James Lee) Date: Wed, 13 Apr 2011 11:46:48 GMT Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <20110413110735.GC17736@sebastiankayser.de> References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> Message-ID: <20110413.11464800.3343819048@gyor.oxdrove.co.uk> On 13/04/11, 12:07:35, Sebastian Kayser wrote regarding Re: [csw-maintainers] Catalog generation date information in catalog/pkgutil?: > > Would it be possible to integrate the generation date into the catalog > > during build time? And what do you think about integrating this date > > information in pkgutil -V output (or similar)? > A page/box/section on opencsw.org with the generation date for all of > our catalogs (like the one from James [1]) would be neat too! It was so long ago I asked for the date in the file I've forgotten when I asked. I have to deduce the date from the server returns. FTP dates are tricky. HTTP headers are not consistent, some don't have a date and some people seem incapable of setting their server clock. I do a vague majority vote on the dates when unset. At the moment there are some stray ftp dates, the algorithm needs more work. Summary: what a pain, how much easier with the date in the file. James. From bwalton at opencsw.org Wed Apr 13 14:51:58 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 13 Apr 2011 08:51:58 -0400 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <20110413105529.GB17736@sebastiankayser.de> References: <20110413105529.GB17736@sebastiankayser.de> Message-ID: <1302699085-sup-174@pinkfloyd.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Wed Apr 13 06:55:29 -0400 2011: > Would it be possible to integrate the generation date into the > catalog during build time? And what do you think about integrating > this date information in pkgutil -V output (or similar)? If we can have 'sitefeatures' we can certainly have a date. Makes sense to me. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Wed Apr 13 18:06:46 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 13 Apr 2011 09:06:46 -0700 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <20110413.11464800.3343819048@gyor.oxdrove.co.uk> References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> Message-ID: On Wed, Apr 13, 2011 at 4:46 AM, James Lee wrote: > > It was so long ago I asked for the date in the file I've forgotten > when I asked. huh. I dont recall having this requested before. but it shouldnt be very difficult to wedge one in. Although I'm not really sure what good it does you.. it still doesnt tell you whether it is "in sync" with the master, which seems to be the high level thing that people "really" want. For that, you still have to compare one way or the other with "the master". One made 2 hours ago, could still be "out of date". contrariwise, one made 2 days ago, might still be UP to date. Sounds like what people would most like, would be a "catalog last updated" thingie on our website. That may as well just go with the output from "ls -l $CATALOG" rather than having to actually parse the catalog ? From bwalton at opencsw.org Wed Apr 13 18:42:03 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 13 Apr 2011 12:42:03 -0400 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> Message-ID: <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Apr 13 12:06:46 -0400 2011: > That may as well just go with the output from "ls -l $CATALOG" rather > than having to actually parse the catalog ? But you also need a way to compare the catalog you fetched with this value. I think both things would be useful. Embedded and externally available. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From james at opencsw.org Wed Apr 13 19:00:20 2011 From: james at opencsw.org (James Lee) Date: Wed, 13 Apr 2011 17:00:20 GMT Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> Message-ID: <20110413.17002000.119076268@gyor.oxdrove.co.uk> On 13/04/11, 17:06:46, Philip Brown wrote regarding Re: [csw-maintainers] Catalog generation date information in catalog/pkgutil?: > Although I'm not really sure what good it does you.. it still doesnt > tell you whether it is "in sync" with the master, which seems to be > the high level thing that people "really" want. For that, you still > have to compare one way or the other with "the master". > One made 2 hours ago, could still be "out of date". contrariwise, one > made 2 days ago, might still be UP to date. It allows comparison of different mirrors (or files). The newest on one mirror might not be the newest offered by any server. I can't assume the latest by time stamp is the latest because it's unreliable which is where my mode rule comes in. > Sounds like what people would most like, would be a "catalog last > updated" thingie on our website. > That may as well just go with the output from "ls -l $CATALOG" rather > than having to actually parse the catalog ? Which is tricky when the server fails give a date or the mirrors have the wrong time set or someone copies the file without the time stamp. James. From phil at bolthole.com Wed Apr 13 19:55:54 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 13 Apr 2011 10:55:54 -0700 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Apr 13, 2011 at 9:42 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Wed Apr 13 12:06:46 -0400 2011: > >> That may as well just go with the output from "ls -l $CATALOG" rather >> than having to actually parse the catalog ?? > > But you also need a way to compare the catalog you fetched with this > value. wget preserves the timestamp, though... ? > ?I think both things would be useful. ?Embedded and externally > available. Quite possibly. but we still have the more important higher level need, of informing the user somehow, "value X is the latest". James writes: >Which is tricky when the server fails give a date or the mirrors have >the wrong time set or someone copies the file without the time stamp. If someone has copied the file without the timestamp, they have done a one-time copy, and are not using usual pkgutil/pkg-get update channels. If so, seems like they dont care so much about "what is latest"? [note to pessimistic people: I'm not drawing out this discussion to be difficult :-p I'm trying to flesh out and fully understand use cases. It does not serve us well, if we implement a "solution" to something that is non-applicable to start with. Contrariwise, a poorly understood use case, may have a different problem, that we have not yet seen, that still needs addressing] From phil at bolthole.com Wed Apr 13 20:02:04 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 13 Apr 2011 11:02:04 -0700 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> Message-ID: PS: I put some experimental code into the catalog generation script. It outputs in the first line of comments, a strings of the format date -u '+%Y/%m/%d-%H:%M:%S' Next push will have it. From bwalton at opencsw.org Wed Apr 13 20:10:01 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 13 Apr 2011 14:10:01 -0400 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> Message-ID: <1302718084-sup-968@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Apr 13 13:55:54 -0400 2011: > wget preserves the timestamp, though... ? It can do that, but you're relying implicitly on a whole chain of things there. I think it would be better to use an explicit value as stored in the catalog directly. (Not the only way as you note, but I think it's better...and since it would be almost no cost...) > Quite possibly. but we still have the more important higher level > need, of informing the user somehow, "value X is the latest". Agreed. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From james at opencsw.org Wed Apr 13 20:16:24 2011 From: james at opencsw.org (James Lee) Date: Wed, 13 Apr 2011 18:16:24 GMT Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> Message-ID: <20110413.18162400.442692878@gyor.oxdrove.co.uk> On 13/04/11, 18:55:54, Philip Brown wrote regarding Re: [csw-maintainers] Catalog generation date information in catalog/pkgutil?: > wget preserves the timestamp, though... ? Assuming the server has an accurate date. James. From james at opencsw.org Wed Apr 13 20:16:24 2011 From: james at opencsw.org (James Lee) Date: Wed, 13 Apr 2011 18:16:24 GMT Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> Message-ID: <20110413.18162400.575907544@gyor.oxdrove.co.uk> On 13/04/11, 19:02:04, Philip Brown wrote regarding Re: [csw-maintainers] Catalog generation date information in catalog/pkgutil?: > PS: I put some experimental code into the catalog generation script. Thanks. > It outputs in the first line of comments, a strings of the format > date -u '+%Y/%m/%d-%H:%M:%S' ISO 8601? Can it have a standard label? Like: # CreationDate: $(date -u '+%Y/%m/%d-%H:%M:%S') James. From skayser at opencsw.org Wed Apr 13 20:02:03 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 13 Apr 2011 20:02:03 +0200 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <20110413.18162400.575907544@gyor.oxdrove.co.uk> References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> Message-ID: <20110413180203.GE17736@sebastiankayser.de> * James Lee wrote: > On 13/04/11, 19:02:04, Philip Brown wrote regarding Re: > [csw-maintainers] Catalog generation date information in > catalog/pkgutil?: > > > PS: I put some experimental code into the catalog generation script. > > Thanks. > > > It outputs in the first line of comments, a strings of the format > > > date -u '+%Y/%m/%d-%H:%M:%S' > > ISO 8601? > > Can it have a standard label? Like: > > # CreationDate: $(date -u '+%Y/%m/%d-%H:%M:%S') +1 on all of the above (thanks, ISO8601 w/ timezone, label). Sebastian From phil at bolthole.com Wed Apr 13 22:34:39 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 13 Apr 2011 13:34:39 -0700 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <20110413.18162400.575907544@gyor.oxdrove.co.uk> References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> Message-ID: On Wed, Apr 13, 2011 at 11:16 AM, James Lee wrote: > On 13/04/11, 19:02:04, Philip Brown wrote regarding Re: > [csw-maintainers] Catalog generation date information in > catalog/pkgutil?: > >> PS: I put some experimental code into the catalog generation script. > > Thanks. > >> It outputs in the first line of comments, a strings of the format > >> date -u '+%Y/%m/%d-%H:%M:%S' > > ISO 8601? > > > Can it have a standard label? ?Like: > > # CreationDate: $(date -u '+%Y/%m/%d-%H:%M:%S') > Is the only thing you changed there, to add "CreationDate:" ? Looks like it, but I want to make sure. Is this some kind of actual documented external standard label? Otherwise, I dont see the value of "CreationDate:" over what I shoved in there, of "..blah blah... generated on $(date....)" Hm. going on other people's comments.. I guess even though i think the letters are ugly, it should be date -u '+%Y/%m/%dT%H:%M:%SZ' according to ISO8601 From bonivart at opencsw.org Wed Apr 13 22:46:21 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 13 Apr 2011 22:46:21 +0200 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> Message-ID: On Wed, Apr 13, 2011 at 10:34 PM, Philip Brown wrote: > date -u '+%Y/%m/%dT%H:%M:%SZ' "The separator used between date values (year, month, week, and day) is the hyphen." From phil at bolthole.com Wed Apr 13 22:54:46 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 13 Apr 2011 13:54:46 -0700 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> Message-ID: On Wed, Apr 13, 2011 at 1:46 PM, Peter Bonivart wrote: > On Wed, Apr 13, 2011 at 10:34 PM, Philip Brown wrote: >> date -u '+%Y/%m/%dT%H:%M:%SZ' > > "The separator used between date values (year, month, week, and day) > is the hyphen." > Noted. Okay then: date -u '+%Y-%m-%dT%H:%M:%SZ' which currently yields output of 2011-04-13T20:54:24Z From james at opencsw.org Thu Apr 14 10:44:10 2011 From: james at opencsw.org (James Lee) Date: Thu, 14 Apr 2011 08:44:10 GMT Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> Message-ID: <20110414.8441000.2131520926@gyor.oxdrove.co.uk> On 13/04/11, 21:34:39, Philip Brown wrote regarding Re: [csw-maintainers] Catalog generation date information in catalog/pkgutil?: > > Can it have a standard label? ?Like: > > > > # CreationDate: $(date -u '+%Y/%m/%d-%H:%M:%S') > > > Is the only thing you changed there, to add "CreationDate:" ? > Looks like it, but I want to make sure. > Is this some kind of actual documented external standard label? We should create/extend the standard. As it's a comment line it is already accepted by the standard. Its use will be experimental until we are happy with its format. > Otherwise, I dont see the value of "CreationDate:" over what I shoved > in there, of > "..blah blah... generated on $(date....)" To ease mechanical extraction. Simplistic shell commands but work as examples: date=$(grep '^# CreationDate:' catalog) echo ${date#*:} echo $(sed -n -e '/^# CreationDate: /s///p' catalog) The token "CreationDate" is the same token used by PDF and Postscript DSC [1] [2]. PS DSC is a similar example of how to use comments to embed data in the catalog. $ grep '^/CreationDate' file.pdf /CreationDate(D:20101216165641+00'00') $ grep '^%%CreationDate' file.ps %%CreationDate: 2011/03/24 14:07:25 James. 1. http://en.wikipedia.org/wiki/Document_Structuring_Conventions 2. http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf From bwalton at opencsw.org Thu Apr 14 15:49:30 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 14 Apr 2011 09:49:30 -0400 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <20110414.8441000.2131520926@gyor.oxdrove.co.uk> References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> <20110414.8441000.2131520926@gyor.oxdrove.co.uk> Message-ID: <1302788864-sup-5122@pinkfloyd.chass.utoronto.ca> Excerpts from James Lee's message of Thu Apr 14 04:44:10 -0400 2011: > > > # CreationDate: $(date -u '+%Y/%m/%d-%H:%M:%S') I also like this short and to the point label for the field. The ISO8601 formatted date strings work for me too. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ja at opencsw.org Thu Apr 14 20:11:09 2011 From: ja at opencsw.org (Juergen Arndt) Date: Thu, 14 Apr 2011 20:11:09 +0200 Subject: [csw-maintainers] Perl scripting question Message-ID: Hi All, in a software, written in perl, I stumbled over the following line of code: exec("$cmds[$no]{command} 1>$tmp_stdout 2>$tmp_stderr"); So a certain command should be executed and stdout and stderr should be redirected into a file. This works on linux, but not on Solaris, when the given command is not found. In this case stderr will not be redirected. Could someone explain, why perl works here in different ways and how could a workaround look like? As an minimal example I used: perl -le 'exec( "not_existing_command 2>my.stderr" )' Thank you Juergen -- Juergen Arndt From phil at bolthole.com Thu Apr 14 21:20:53 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 14 Apr 2011 12:20:53 -0700 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <20110414.8441000.2131520926@gyor.oxdrove.co.uk> References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> <20110414.8441000.2131520926@gyor.oxdrove.co.uk> Message-ID: On Thu, Apr 14, 2011 at 1:44 AM, James Lee wrote: > On 13/04/11, 21:34:39, Philip Brown wrote regarding Re: > [ > >> Is this some kind of actual documented external standard label? >.. > >> Otherwise, I dont see the value of "CreationDate:" ?over what I shoved >> in there, of >> "..blah blah... generated on $(date....)" > > To ease mechanical extraction. ?Simplistic shell commands but work as > examples: > > date=$(grep '^# CreationDate:' catalog) > echo ${date#*:} > > echo $(sed -n -e '/^# CreationDate: /s///p' catalog) awk 'NR==1{print $NF;exit}' catalog > > The token "CreationDate" is the same token used by PDF and Postscript > DSC [1] [2]. ?PS DSC is a similar example of how to use comments to > embed data in the catalog. thats a nice reference. However, going by your examples, either of them use ISO8601 format, so in a way, that is an argument NOT to use it. > $ grep '^/CreationDate' file.pdf > /CreationDate(D:20101216165641+00'00') > > $ grep '^%%CreationDate' file.ps > %%CreationDate: 2011/03/24 14:07:25 Does anyone have examples of use of the ISO8601 foramt used in a text(ish) file, and what keyword, if any, that they use? From phil at bolthole.com Fri Apr 15 07:42:29 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 14 Apr 2011 22:42:29 -0700 Subject: [csw-maintainers] Perl scripting question In-Reply-To: References: Message-ID: Its probably not so much solaris vs linux, as "what shell you had on other box, vs solaris box". if your shell happens to be set to a csh-derivative, i would think it would not work? On Thu, Apr 14, 2011 at 11:11 AM, Juergen Arndt wrote: > Hi All, > > in a software, written in perl, I stumbled over the following line of code: > > ? ? ? ?exec("$cmds[$no]{command} 1>$tmp_stdout 2>$tmp_stderr"); > > So a certain command should be executed and stdout and stderr should be redirected into a file. > > This works on linux, but not on Solaris, when the given command is not found. In this case stderr will not be redirected. Could someone explain, why perl works here in different ways and how could a workaround look like? > > As an minimal example I used: perl -le 'exec( "not_existing_command 2>my.stderr" )' > From ja at opencsw.org Fri Apr 15 09:14:12 2011 From: ja at opencsw.org (Juergen Arndt) Date: Fri, 15 Apr 2011 09:14:12 +0200 Subject: [csw-maintainers] Perl scripting question In-Reply-To: References: Message-ID: I tried it on linux and solaris with sh, bash, zsh, ksh and csh and every time I get the effect as described. On 15.04.2011, at 07:42, Philip Brown wrote: > Its probably not so much solaris vs linux, as "what shell you had on > other box, vs solaris box". > if your shell happens to be set to a csh-derivative, i would think it > would not work? > > On Thu, Apr 14, 2011 at 11:11 AM, Juergen Arndt wrote: >> Hi All, >> >> in a software, written in perl, I stumbled over the following line of code: >> >> exec("$cmds[$no]{command} 1>$tmp_stdout 2>$tmp_stderr"); >> >> So a certain command should be executed and stdout and stderr should be redirected into a file. >> >> This works on linux, but not on Solaris, when the given command is not found. In this case stderr will not be redirected. Could someone explain, why perl works here in different ways and how could a workaround look like? >> >> As an minimal example I used: perl -le 'exec( "not_existing_command 2>my.stderr" )' >> > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- Juergen Arndt From james at opencsw.org Fri Apr 15 11:15:02 2011 From: james at opencsw.org (James Lee) Date: Fri, 15 Apr 2011 09:15:02 GMT Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> <20110414.8441000.2131520926@gyor.oxdrove.co.uk> Message-ID: <20110415.9150200.1534078666@gyor.oxdrove.co.uk> On 14/04/11, 20:20:53, Philip Brown wrote regarding Re: [csw-maintainers] Catalog generation date information in catalog/pkgutil?: > > date=$(grep '^# CreationDate:' catalog) > > echo ${date#*:} > > > > echo $(sed -n -e '/^# CreationDate: /s///p' catalog) > awk 'NR==1{print $NF;exit}' catalog Which does? $ cat catalog 1111 2222 # CreationDate: 2011-04-15 11:02:45 4444 5555 6666 $ awk 'NR==1{print $NF;exit}' catalog 1111 # Here again sed but with quit after print. I thought I could put all # on one line with enough back slashes but gave up: $ sed -n -f /dev/stdin catalog << 'EOF' /^# CreationDate: /{ s///p q } EOF 2011-04-15 11:02:45 > > The token "CreationDate" is the same token used by PDF and Postscript > > DSC [1] [2]. ?PS DSC is a similar example of how to use comments to > > embed data in the catalog. > thats a nice reference. However, going by your examples, either of > them use ISO8601 format, so in a way, that is an argument NOT to use > it. Correct, it wasn't supposed to be. Focus on the use of DSC to add data to a file using structured comments. Take the 1 minute PS DSC tutorial, here is the top of a DSC conforming PostScript file: %!PS-Adobe-3.0 %%Pages: (atend) %%BoundingBox: 18 42 593 774 %%HiResBoundingBox: 18.700000 42.300000 593.000000 774.000000 %..................................... %%Creator: GPL Ghostscript 901 (pswrite) %%CreationDate: 2011/03/24 14:07:25 %%DocumentData: Clean7Bit %%LanguageLevel: 2 %%EndComments And here is a notional catalog head with formalised comments: #OpenCSW catalog 1.0 #CreationDate: 2010-04-15 09:11:12Z #Version: 1.2 #Creator: bldcat 2.3 #Author: Philip Brown #SiteFeatures: gzipcatalog #EndComments James. From phil at bolthole.com Fri Apr 15 16:11:45 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 15 Apr 2011 07:11:45 -0700 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <20110414.8441000.2131520926@gyor.oxdrove.co.uk> References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> <20110414.8441000.2131520926@gyor.oxdrove.co.uk> Message-ID: On Thu, Apr 14, 2011 at 1:44 AM, James Lee wrote: > > 1. http://en.wikipedia.org/wiki/Document_Structuring_Conventions > 2. http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf > I finally took the time to look at these docs. While it does refer to itself in places as "DSC", it seems to me that the full title is really PLDSC -- postscript language document structuring conventions. It is not a generic structuring standard. (and for that matter, the catalog isnt a "document" either). Not that I'm saying we have to find something applicable for "catalogs". I'm just saying that it isnt a particularly compelling standard. I'm hoping there's something more generic out there. From ja at opencsw.org Fri Apr 15 16:47:35 2011 From: ja at opencsw.org (Juergen Arndt) Date: Fri, 15 Apr 2011 16:47:35 +0200 Subject: [csw-maintainers] Perl scripting question In-Reply-To: References: Message-ID: <8F9335FB-A668-4398-BC2C-956BFE2E3BF0@opencsw.org> Ok, I got the clou. The exec function of perl calls according to perldoc "/bin/sh -c ..." on unices. On Solaris /bin/sh is indeed the bourne shell, on linux it's a link to /bin/bash. That's the difference and that's why the code snippet below works different on linux and Solaris. Thank you Juergen On 15.04.2011, at 07:42, Philip Brown wrote: > Its probably not so much solaris vs linux, as "what shell you had on > other box, vs solaris box". > if your shell happens to be set to a csh-derivative, i would think it > would not work? > > On Thu, Apr 14, 2011 at 11:11 AM, Juergen Arndt wrote: >> Hi All, >> >> in a software, written in perl, I stumbled over the following line of code: >> >> exec("$cmds[$no]{command} 1>$tmp_stdout 2>$tmp_stderr"); >> >> So a certain command should be executed and stdout and stderr should be redirected into a file. >> >> This works on linux, but not on Solaris, when the given command is not found. In this case stderr will not be redirected. Could someone explain, why perl works here in different ways and how could a workaround look like? >> >> As an minimal example I used: perl -le 'exec( "not_existing_command 2>my.stderr" )' >> > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- Juergen Arndt From james at opencsw.org Fri Apr 15 17:38:09 2011 From: james at opencsw.org (James Lee) Date: Fri, 15 Apr 2011 15:38:09 GMT Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> <20110414.8441000.2131520926@gyor.oxdrove.co.uk> Message-ID: <20110415.15380900.865391463@gyor.oxdrove.co.uk> On 15/04/11, 15:11:45, Philip Brown wrote regarding Re: [csw-maintainers] Catalog generation date information in catalog/pkgutil?: > It is not a generic structuring standard. Correct. It's a pre-existing, enduring example of using comments to add data to a file. > (and for that matter, the catalog isnt a "document" either). Either? A PostScript program isn't a "document", in fact one of the reasons DSC exists is to make PostScript easily parsable without full interpretation, eg, to know how many pages. Legal PS, non-compliant DSC: %! /Times-Roman 20 selectfont 1 1 10 { 50 50 moveto (Page ) show ( ) cvs show showpage } for > Not that I'm saying we have to find something applicable for > "catalogs". I'm just saying that it isnt a particularly compelling > standard. It's an extremely compelling standard for use with PostScript, mainly because it *is* the standard. > I'm hoping there's something more generic out there. I said create one. Before we got side tracked in to why a list of packages is not a page description language we were considering why simply tagging the date with a defended label would help its extraction. A similar problem solved by Adobe over 20 years ago (no doubt there are others older). I didn't say use Adobe's DSC or any one else's (long ago I supported an XML catalog option, then one can use an exiting parser). James. From maciej at opencsw.org Sun Apr 17 12:44:01 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 17 Apr 2011 11:44:01 +0100 Subject: [csw-maintainers] cswutils in experimental In-Reply-To: <1302652964-sup-3754@pinkfloyd.chass.utoronto.ca> References: <1302652964-sup-3754@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/4/13 Ben Walton : > If you use the cswutils package, please test the update I've placed in > the cswutils experimental repo on the buildfarm. Tested submitpkg and comparepkg, they look good. Maciej From dam at opencsw.org Mon Apr 18 17:24:39 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 18 Apr 2011 17:24:39 +0200 Subject: [csw-maintainers] New pax replacement in place References: <4F57D8A2-2969-4561-B099-6510AB49DE2E@baltic-online.de> Message-ID: Hi, I just replaced in r14323 the old "pax" by a new "pcopy" which hopefully has less bugs. It is a tiny rewrite by me in Perl. It should support all used features we used from "pax". Please keep an open eye if you notice anything suspicious. BTW, this is needed as bugs in the current pax kept me from packaging up the new 64 bit perl. Best regards -- Dago From maciej at opencsw.org Mon Apr 18 19:27:29 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 18 Apr 2011 18:27:29 +0100 Subject: [csw-maintainers] New pax replacement in place In-Reply-To: References: <4F57D8A2-2969-4561-B099-6510AB49DE2E@baltic-online.de> Message-ID: 2011/4/18 Dagobert Michelsen : > I just replaced in r14323 the old "pax" by a new "pcopy" which hopefully > has less bugs. It is a tiny rewrite by me in Perl. It should support > all used features we used from "pax". I remember one of the bugs was losing the original file permissions under the influence of umask. I had to add post-merge steps to revert permission bits to what I wanted. Have you tested pcopy under this scenario? Maciej From dam at opencsw.org Mon Apr 18 21:23:41 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 18 Apr 2011 21:23:41 +0200 Subject: [csw-maintainers] New pax replacement in place In-Reply-To: References: <4F57D8A2-2969-4561-B099-6510AB49DE2E@baltic-online.de> Message-ID: <06B14039-D93A-47D7-BAE4-BBA681A54828@opencsw.org> Hi Maciej, Am 18.04.2011 um 19:27 schrieb Maciej Blizi?ski: > 2011/4/18 Dagobert Michelsen : >> I just replaced in r14323 the old "pax" by a new "pcopy" which hopefully >> has less bugs. It is a tiny rewrite by me in Perl. It should support >> all used features we used from "pax". > > I remember one of the bugs was losing the original file permissions > under the influence of umask. I had to add post-merge steps to revert > permission bits to what I wanted. Have you tested pcopy under this > scenario? Nope, but now that you mention it I remember there was a problem. Do you know which Makefile is was so I can have a look? Best regards -- Dago From skayser at opencsw.org Tue Apr 19 00:10:00 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 19 Apr 2011 00:10:00 +0200 Subject: [csw-maintainers] GAR: move to mako for newpkg templates? Message-ID: <20110418221000.GJ17736@sebastiankayser.de> Hi, any objections for moving GAR's newpkg template "backend" to mako [1]? http://paste.pocoo.org/show/374164/ This would re-use the template which is used by mgar and bring us the power of full python syntax in the templates. I'd also roll it out to the subdirectories which have their own newpkg-% target then. Sebastian [1] http://www.makotemplates.org/ From maciej at opencsw.org Tue Apr 19 12:23:30 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Tue, 19 Apr 2011 11:23:30 +0100 Subject: [csw-maintainers] New pax replacement in place In-Reply-To: <06B14039-D93A-47D7-BAE4-BBA681A54828@opencsw.org> References: <4F57D8A2-2969-4561-B099-6510AB49DE2E@baltic-online.de> <06B14039-D93A-47D7-BAE4-BBA681A54828@opencsw.org> Message-ID: 2011/4/18 Dagobert Michelsen : > Hi Maciej, > > Am 18.04.2011 um 19:27 schrieb Maciej Blizi?ski: >> 2011/4/18 Dagobert Michelsen : >>> I just replaced in r14323 the old "pax" by a new "pcopy" which hopefully >>> has less bugs. It is a tiny rewrite by me in Perl. It should support >>> all used features we used from "pax". >> >> I remember one of the bugs was losing the original file permissions >> under the influence of umask. ?I had to add post-merge steps to revert >> permission bits to what I wanted. ?Have you tested pcopy under this >> scenario? > > Nope, but now that you mention it I remember there was a problem. > Do you know which Makefile is was so I can have a look? It's with any (and every) Makefile. The way to reproduce it is: - build with umask 022 - build with umask 027 - compare Maciej From phil at bolthole.com Tue Apr 19 19:58:35 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Apr 2011 10:58:35 -0700 Subject: [csw-maintainers] GAR: move to mako for newpkg templates? In-Reply-To: <20110418221000.GJ17736@sebastiankayser.de> References: <20110418221000.GJ17736@sebastiankayser.de> Message-ID: please list side effects of doing this. eg: this adds the following dependencies required for working with gar:,CSWxxx On Monday, April 18, 2011, Sebastian Kayser wrote: > Hi, > > any objections for moving GAR's newpkg template "backend" to mako [1]? > > ? ?http://paste.pocoo.org/show/374164/ > > This would re-use the template which is used by mgar and bring us the > power of full python syntax in the templates. I'd also roll it out to > the subdirectories which have their own newpkg-% target then. > > Sebastian > > [1] http://www.makotemplates.org/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From skayser at opencsw.org Tue Apr 19 20:01:11 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 19 Apr 2011 20:01:11 +0200 Subject: [csw-maintainers] GAR: move to mako for newpkg templates? In-Reply-To: References: <20110418221000.GJ17736@sebastiankayser.de> Message-ID: <4DADCDE7.2090407@opencsw.org> Philip Brown wrote on 4/19/2011 7:58 PM: > please list side effects of doing this. eg: this adds the following > dependencies required for working with gar:,CSWxxx One additional dep: py_mako. Ben can add this to the gar_dev package. Sebastian From bwalton at opencsw.org Tue Apr 19 20:03:00 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 19 Apr 2011 14:03:00 -0400 Subject: [csw-maintainers] GAR: move to mako for newpkg templates? In-Reply-To: <4DADCDE7.2090407@opencsw.org> References: <20110418221000.GJ17736@sebastiankayser.de> <4DADCDE7.2090407@opencsw.org> Message-ID: <1303236148-sup-2554@pinkfloyd.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Tue Apr 19 14:01:11 -0400 2011: > One additional dep: py_mako. Ben can add this to the gar_dev package. ...and since we depend on python + modules already, this is very little overhead. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Apr 19 21:01:04 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 19 Apr 2011 15:01:04 -0400 Subject: [csw-maintainers] thoughts on a dependency Message-ID: <1303239480-sup-7986@pinkfloyd.chass.utoronto.ca> Hi All, Polling the audience here to see what others think. I'm evaluating bacula for use here so I'm going to update the (really stale) version in our catalog. Bacula requires mysql (or pg or sqlite) to run. The old version used mysql and I see no reason to change that. So, mysql is a dependency but mysql could be run on a separate host. The old package didn't depend on CSWmysql. Should the update? I'm leaning toward no (status quo) as there is still a pile of manual config to do with this thing anyway. If things could be seamlessly added to mysql like in debian (with their magic accounts) I'd be tempted to make the dependency direct... Does anyone think otherwise? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Tue Apr 19 21:05:09 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 19 Apr 2011 21:05:09 +0200 Subject: [csw-maintainers] thoughts on a dependency In-Reply-To: <1303239480-sup-7986@pinkfloyd.chass.utoronto.ca> References: <1303239480-sup-7986@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Apr 19, 2011 at 9:01 PM, Ben Walton wrote: > > Hi All, > > Polling the audience here to see what others think. ?I'm evaluating > bacula for use here so I'm going to update the (really stale) version > in our catalog. ?Bacula requires mysql (or pg or sqlite) to run. ?The > old version used mysql and I see no reason to change that. ?So, mysql > is a dependency but mysql could be run on a separate host. ?The old > package didn't depend on CSWmysql. ?Should the update? > > I'm leaning toward no (status quo) as there is still a pile of manual > config to do with this thing anyway. ?If things could be seamlessly > added to mysql like in debian (with their magic accounts) I'd be > tempted to make the dependency direct... > > Does anyone think otherwise? I do a similar thing with MailScanner, it supports at least Sendmail, Postfix and Exim as MTAs and even though I use Sendmail with it I think a Postfix user would be annoyed if it tried to pull in Sendmail. So I don't declare any MTA dependency at all. /peter From dam at opencsw.org Tue Apr 19 21:46:49 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 19 Apr 2011 21:46:49 +0200 Subject: [csw-maintainers] thoughts on a dependency In-Reply-To: <1303239480-sup-7986@pinkfloyd.chass.utoronto.ca> References: <1303239480-sup-7986@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, Am 19.04.2011 um 21:01 schrieb Ben Walton: > Polling the audience here to see what others think. I'm evaluating > bacula for use here so I'm going to update the (really stale) version > in our catalog. Bacula requires mysql (or pg or sqlite) to run. The > old version used mysql and I see no reason to change that. So, mysql > is a dependency but mysql could be run on a separate host. The old > package didn't depend on CSWmysql. Should the update? > > I'm leaning toward no (status quo) as there is still a pile of manual > config to do with this thing anyway. If things could be seamlessly > added to mysql like in debian (with their magic accounts) I'd be > tempted to make the dependency direct... > > Does anyone think otherwise? It would be good if support for all three would be compiled in. But yes, having no direct dependency is IMHO the best way to go here. Best regards -- Dago From dam at opencsw.org Tue Apr 19 21:48:06 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 19 Apr 2011 21:48:06 +0200 Subject: [csw-maintainers] GAR: move to mako for newpkg templates? In-Reply-To: <20110418221000.GJ17736@sebastiankayser.de> References: <20110418221000.GJ17736@sebastiankayser.de> Message-ID: Hi Sebastian, Am 19.04.2011 um 00:10 schrieb Sebastian Kayser: > any objections for moving GAR's newpkg template "backend" to mako [1]? Nope, please go ahead. Best regards -- Dago From bwalton at opencsw.org Tue Apr 19 21:49:07 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 19 Apr 2011 15:49:07 -0400 Subject: [csw-maintainers] thoughts on a dependency In-Reply-To: References: <1303239480-sup-7986@pinkfloyd.chass.utoronto.ca> Message-ID: <1303242491-sup-2521@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Apr 19 15:46:49 -0400 2011: Hi Dago, > It would be good if support for all three would be compiled in. But > yes, having no direct dependency is IMHO the best way to go here. I can look at this option (using alternatives) later as I agree that it would be the nicest. I'll get the update polished first and then add features. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Apr 19 22:28:51 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 19 Apr 2011 16:28:51 -0400 Subject: [csw-maintainers] thoughts on a dependency In-Reply-To: References: <1303239480-sup-7986@pinkfloyd.chass.utoronto.ca> Message-ID: <1303244849-sup-6722@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Tue Apr 19 15:05:09 -0400 2011: Hi Peter, > I do a similar thing with MailScanner, it supports at least > Sendmail, Postfix and Exim as MTAs and even though I use Sendmail > with it I think a Postfix user would be annoyed if it tried to pull > in Sendmail. So I don't declare any MTA dependency at all. Thanks Peter. I think this is the right path for now. If I add alternatives support later, I can make the sub-package specific bits drag in the right database. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From skayser at opencsw.org Wed Apr 20 00:10:44 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 20 Apr 2011 00:10:44 +0200 Subject: [csw-maintainers] GAR: move to mako for newpkg templates? In-Reply-To: References: <20110418221000.GJ17736@sebastiankayser.de> Message-ID: <4DAE0864.9010900@opencsw.org> Dagobert Michelsen wrote on 4/19/2011 9:48 PM: > Am 19.04.2011 um 00:10 schrieb Sebastian Kayser: >> any objections for moving GAR's newpkg template "backend" to mako [1]? > > Nope, please go ahead. Cool, committed with r14331. The per sub-directory newpkg-stubs are still sort of duplicated effort, but this will likely soon go away with mgar anyway. Sebastian From phil at bolthole.com Wed Apr 20 01:32:25 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Apr 2011 16:32:25 -0700 Subject: [csw-maintainers] thoughts on a dependency In-Reply-To: <1303239480-sup-7986@pinkfloyd.chass.utoronto.ca> References: <1303239480-sup-7986@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Apr 19, 2011 at 12:01 PM, Ben Walton wrote: >... > > I'm leaning toward no (status quo) as there is still a pile of manual > config to do with this thing anyway. ?If things could be seamlessly > added to mysql like in debian (with their magic accounts) I'd be > tempted to make the dependency direct... > No depend... but the nice thing to do is to make sure you include, and blatently document, the fairly decent bacula-mysql scripts to get someone up and running quickly. From bwalton at opencsw.org Wed Apr 20 04:34:55 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 19 Apr 2011 22:34:55 -0400 Subject: [csw-maintainers] thoughts on a dependency In-Reply-To: References: <1303239480-sup-7986@pinkfloyd.chass.utoronto.ca> Message-ID: <1303266880-sup-4983@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Apr 19 19:32:25 -0400 2011: > No depend... but the nice thing to do is to make sure you include, > and blatently document, the fairly decent bacula-mysql scripts to > get someone up and running quickly. Yup. Ok, good to have the confirmations. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From gadavis at opencsw.org Wed Apr 20 23:35:59 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Wed, 20 Apr 2011 14:35:59 -0700 Subject: [csw-maintainers] 64-bit python Message-ID: <3035BBB2-072B-4568-B91C-45B8E13D8D9A@opencsw.org> Hi all, I am incredibly motivated to get a 64-bit version of python running, as I have a software suite that is now 64-bit only and needs to link against a 64-bit relatively modern python installation (2.6 or greater). Solaris 10 unfortunately ships with Python 2.4, which is too old. The effort to make a 64-bit version of ImageMagick also looks like it needs a 64-bit python. See http://wiki.opencsw.org/imagemagick and http://wiki.opencsw.org/project-imagemagick64 I see that Maciej had started working on a 64-bit python version but that it's not ready for primetime. What are the catches with getting this ready to go out to the real world? From gadavis at opencsw.org Thu Apr 21 00:53:05 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Wed, 20 Apr 2011 15:53:05 -0700 Subject: [csw-maintainers] 64-bit python In-Reply-To: <3035BBB2-072B-4568-B91C-45B8E13D8D9A@opencsw.org> References: <3035BBB2-072B-4568-B91C-45B8E13D8D9A@opencsw.org> Message-ID: <7D02D982-387E-4EB4-BD12-95D5014582AB@opencsw.org> Interestingly enough, I can't even get the current GAR recipe to build in 32-bit mode: ==> Verifying installed package CSWlibffi-dev: MISSING I can't find that package in the database, and the corresponding CSWlibffi looks to be empty. There's no libffi5 anywhere in the catalog either. On Apr 20, 2011, at 2:35 PM, Geoff Davis wrote: > Hi all, > > I am incredibly motivated to get a 64-bit version of python running, as I have a software suite that is now 64-bit only and needs to link against a 64-bit relatively modern python installation (2.6 or greater). Solaris 10 unfortunately ships with Python 2.4, which is too old. > > The effort to make a 64-bit version of ImageMagick also looks like it needs a 64-bit python. See http://wiki.opencsw.org/imagemagick and http://wiki.opencsw.org/project-imagemagick64 > > I see that Maciej had started working on a 64-bit python version but that it's not ready for primetime. What are the catches with getting this ready to go out to the real world? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From dam at opencsw.org Thu Apr 21 09:32:35 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 21 Apr 2011 09:32:35 +0200 Subject: [csw-maintainers] 64-bit python In-Reply-To: <3035BBB2-072B-4568-B91C-45B8E13D8D9A@opencsw.org> References: <3035BBB2-072B-4568-B91C-45B8E13D8D9A@opencsw.org> Message-ID: <9054A228-2990-455D-9C1C-EA1325B9DF58@opencsw.org> Hi Geoff, Am 20.04.2011 um 23:35 schrieb Geoff Davis: > I am incredibly motivated to get a 64-bit version of python running, as I have a software suite that is now 64-bit only and needs to link against a 64-bit relatively modern python installation (2.6 or greater). Solaris 10 unfortunately ships with Python 2.4, which is too old. > > The effort to make a 64-bit version of ImageMagick also looks like it needs a 64-bit python. See http://wiki.opencsw.org/imagemagick and http://wiki.opencsw.org/project-imagemagick64 > > I see that Maciej had started working on a 64-bit python version but that it's not ready for primetime. What are the catches with getting this ready to go out to the real world? You may want to look at the 64 bit Perl recipe, which is not 100% done, but on a good way: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/perl/trunk/Makefile Best regards -- Dago From dam at opencsw.org Thu Apr 21 09:45:58 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 21 Apr 2011 09:45:58 +0200 Subject: [csw-maintainers] 64-bit python In-Reply-To: <7D02D982-387E-4EB4-BD12-95D5014582AB@opencsw.org> References: <3035BBB2-072B-4568-B91C-45B8E13D8D9A@opencsw.org> <7D02D982-387E-4EB4-BD12-95D5014582AB@opencsw.org> Message-ID: Hi Geoff, Am 21.04.2011 um 00:53 schrieb Geoff Davis: > Interestingly enough, I can't even get the current GAR recipe to build in 32-bit mode: > ==> Verifying installed package CSWlibffi-dev: MISSING > > I can't find that package in the database, and the corresponding CSWlibffi looks to be empty. There's no libffi5 anywhere in the catalog either. The package Makefile has been updated in GAR, but the package has not been released to current/. It is in unstable, though, and you can experiment with it on the unstable* build machines. Best regards -- Dago From bwalton at opencsw.org Thu Apr 21 15:49:39 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 21 Apr 2011 09:49:39 -0400 Subject: [csw-maintainers] /testing Please help test updated CAS initsmf In-Reply-To: References: <1301235043-sup-2594@pinkfloyd.chass.utoronto.ca> Message-ID: <1303393693-sup-3113@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Sun Mar 27 10:14:44 -0400 2011: Hi Peter, > + load_smf_service_state "$FMRI/$service" This function defaults SMF_STATE to enabled. It can only be toggled to disabled if the preserved state file exists. > + # enable the service if it was enabled before, OR if $daemon = > yes and AUTOENABLE is set > + # previous SMF state always takes precedence > + # note: autoenable_daemons and autoenable_$service controls > $daemon, $AUTOENABLE is set by the package itself > + if [ "$SMF_STATE" = "enabled" ] || [ "$daemon" = "yes" -a > "$AUTOENABLE" != "no" -a "$AUTOENABLE" != "false" ]; then We now always enable, in the case of a fresh installation... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Thu Apr 21 16:35:45 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 21 Apr 2011 16:35:45 +0200 Subject: [csw-maintainers] /testing Please help test updated CAS initsmf In-Reply-To: <1303393693-sup-3113@pinkfloyd.chass.utoronto.ca> References: <1301235043-sup-2594@pinkfloyd.chass.utoronto.ca> <1303393693-sup-3113@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Apr 21, 2011 at 3:49 PM, Ben Walton wrote: > Excerpts from Peter Bonivart's message of Sun Mar 27 10:14:44 -0400 2011: > > Hi Peter, > >> + ? ?load_smf_service_state "$FMRI/$service" > > This function defaults SMF_STATE to enabled. ?It can only be toggled > to disabled if the preserved state file exists. The state file actually says enabled or disabled so there's no reason for the function to default to enabled. If the state file exists it should read the absolute value and if not return neither enabled or disabled. load_smf_service_state () { SMF_STATE="enabled" if [ -f "$SMF_STATE_FILE" ]; then set -- `/usr/bin/awk " \\\$1 == \"$1\" { print \\\$2 } " "$SMF_STATE_FILE"` if [ "$1" = "disabled" ]; then SMF_STATE="disabled" fi fi } becomes: load_smf_service_state () { SMF_STATE="" if [ -f "$SMF_STATE_FILE" ]; then set -- `/usr/bin/awk " \\\$1 == \"$1\" { print \\\$2 } " "$SMF_STATE_FILE"` if [ "$1" = "disabled" ]; then SMF_STATE="disabled" fi if [ "$1" = "enabled" ]; then SMF_STATE="enabled" fi fi } That should fix it. Please try that locally and I can update the package if it works. /peter From bwalton at opencsw.org Thu Apr 21 18:51:14 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 21 Apr 2011 12:51:14 -0400 Subject: [csw-maintainers] /testing Please help test updated CAS initsmf In-Reply-To: References: <1301235043-sup-2594@pinkfloyd.chass.utoronto.ca> <1303393693-sup-3113@pinkfloyd.chass.utoronto.ca> Message-ID: <1303404514-sup-6119@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Thu Apr 21 10:35:45 -0400 2011: Hi Peter, > That should fix it. Please try that locally and I can update the > package if it works. This change works here. With no csw.conf in place and AUTOENABLE no in only one of the bacula init scripts, I get: # svcs -a | grep bacula disabled 12:49:57 svc:/network/cswbacula-dir:default online 12:50:09 svc:/network/cswbacula-sd:default online 12:50:18 svc:/network/cswbacula-fd:default Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Thu Apr 21 21:47:50 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 21 Apr 2011 21:47:50 +0200 Subject: [csw-maintainers] /testing Please help test updated CAS initsmf In-Reply-To: <1303404514-sup-6119@pinkfloyd.chass.utoronto.ca> References: <1301235043-sup-2594@pinkfloyd.chass.utoronto.ca> <1303393693-sup-3113@pinkfloyd.chass.utoronto.ca> <1303404514-sup-6119@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Apr 21, 2011 at 6:51 PM, Ben Walton wrote: > Excerpts from Peter Bonivart's message of Thu Apr 21 10:35:45 -0400 2011: > > Hi Peter, > >> ?That should fix it. Please try that locally and I can update the >> package if it works. > > This change works here. ?With no csw.conf in place and AUTOENABLE no > in only one of the bacula init scripts, I get: > > # svcs -a | grep bacula > disabled ? ? ? 12:49:57 svc:/network/cswbacula-dir:default > online ? ? ? ? 12:50:09 svc:/network/cswbacula-sd:default > online ? ? ? ? 12:50:18 svc:/network/cswbacula-fd:default Great! Updated package submitted. cas_initsmf-1.44,REV=2011.04.21-SunOS5.9-all-CSW.pkg.gz From ja at opencsw.org Thu Apr 21 22:25:37 2011 From: ja at opencsw.org (Juergen Arndt) Date: Thu, 21 Apr 2011 22:25:37 +0200 Subject: [csw-maintainers] Question about cswcptemplates Message-ID: <1B26FEF2-6150-499D-BDD9-A66BB04544E8@opencsw.org> Hi All, I ran into the following problem when using cswcptemplates: After (initially) installing the package on my test system the files belonging to the this class have the ownership root:other , instead of the user and group given in the prototype. As far as I see, the ownerships are supposed to be set in the class action script, but at this point imho something went wrong: contents=`grep "^${file} " $PKG_INSTALL_ROOT/var/sadm/install/contents` if [ "$contents" ]; then mode=`echo $contents | awk '{print $4}'` user=`echo $contents | awk '{print $5}'` group=`echo $contents | awk '{print $6}'` chmod $mode $confdest chown $user:$group $confdest fi In my case $contents was always empty, because the file didn't exist in /var/sadm/install/contents yet, so no mode, user or group was set. Can anyone reproduce this or is it more likely an failure in my package recipe? Thanks, Juergen -- Juergen Arndt From bwalton at opencsw.org Sun Apr 24 01:39:18 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 23 Apr 2011 19:39:18 -0400 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <20110413.18162400.575907544@gyor.oxdrove.co.uk> References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> Message-ID: <1303601852-sup-1830@pinkfloyd.chass.utoronto.ca> Excerpts from James Lee's message of Wed Apr 13 14:16:24 -0400 2011: > Can it have a standard label? Like: > > # CreationDate: $(date -u '+%Y/%m/%d-%H:%M:%S') Was this resolved? Looking at the current catalog, we still have a big english string and then the date. I think a short, concise label is better. It should also be made consistent with SITEFEATURES. Either # CREATIONDATE $(...) or # SiteFeatures: ... I'm not overly partial to either direction for that change, but I think the consistency is worthwhile. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sun Apr 24 02:21:28 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 23 Apr 2011 17:21:28 -0700 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <1303601852-sup-1830@pinkfloyd.chass.utoronto.ca> References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> <1303601852-sup-1830@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Apr 23, 2011 at 4:39 PM, Ben Walton wrote: > Excerpts from James Lee's message of Wed Apr 13 14:16:24 -0400 2011: > >> Can it have a standard label? ?Like: >> >> # CreationDate: $(date -u '+%Y/%m/%d-%H:%M:%S') > > Was this resolved? Not exactly. James requested a "standard" label. I requested suggestions for a "standard" that is more relevant to us. But meanwhile, a creation timestamp HAS been added to the catalog, if you notice. The specific line is: #This catalog file was originally generated on 2011-04-21T20:10:46Z FYI, as someone pointed out, the format that James requested, is not compliant with the relevant ISO. Because of '/' instead of '-'. From bwalton at opencsw.org Sun Apr 24 02:28:02 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 23 Apr 2011 20:28:02 -0400 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> <1303601852-sup-1830@pinkfloyd.chass.utoronto.ca> Message-ID: <1303604615-sup-1875@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Apr 23 20:21:28 -0400 2011: > Not exactly. James requested a "standard" label. I requested > suggestions for a "standard" that is more relevant to us. Well, I think the standard (/ vs - aside) that James proposed is perfectly adequate. # CreationDate: 2011-04-21T20:10:46Z Perfect. Concise, easy to parse, conveys all necessary information. > But meanwhile, a creation timestamp HAS been added to the catalog, if > you notice. Yes, I mentioned that I saw 'blah blah date' (too much verbiage, imo). > FYI, as someone pointed out, the format that James requested, is not > compliant with the relevant ISO. Because of '/' instead of '-'. Ok, so lets s/\//-/g and go with that. I'd then propose that: # SITEFEATURES gzippedcatalog becomes # SiteFeatures: gzippedcatalog So that it is consistent with CreationDate. We could then move forwarding with the following format for any future additions to catalog metadata: # CamelCaseLabel: value Work for everyone? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sun Apr 24 03:11:48 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 23 Apr 2011 18:11:48 -0700 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <1303604615-sup-1875@pinkfloyd.chass.utoronto.ca> References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> <1303601852-sup-1830@pinkfloyd.chass.utoronto.ca> <1303604615-sup-1875@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Apr 23, 2011 at 5:28 PM, Ben Walton wrote: >... ?I'd then propose that: > > # SITEFEATURES gzippedcatalog > > becomes > > # SiteFeatures: gzippedcatalog > > So that it is consistent with CreationDate. > > We could then move forwarding with the following format for any future > additions to catalog metadata: > > # CamelCaseLabel: value > > Work for everyone? > no, it does not work for me. As you point out, we already have a pre-existing magic string in the catalog: > # SITEFEATURES gzippedcatalog If you want consistency in catalog magic strings, then we could just as easily go with # CREATIONDATE 2011-04-21T20:10:46Z From bwalton at opencsw.org Sun Apr 24 03:24:31 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 23 Apr 2011 21:24:31 -0400 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> <1303601852-sup-1830@pinkfloyd.chass.utoronto.ca> <1303604615-sup-1875@pinkfloyd.chass.utoronto.ca> Message-ID: <1303608144-sup-1063@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Apr 23 21:11:48 -0400 2011: > > # SITEFEATURES gzippedcatalog > > If you want consistency in catalog magic strings, then we could just > as easily go with > > # CREATIONDATE 2011-04-21T20:10:46Z Fine with me. I just think the two fields should be consistent. And future meta-data additions should be consistent with these two. I don't know why you don't like CreationDate: (and I don't really care). I find it nicer to look at personally, but that's not the point. Lets remove the current 'this catalog generated on...' and set: # CREATIONDATE 2011-04-21T20:10:46Z Good? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From james at opencsw.org Sun Apr 24 15:53:44 2011 From: james at opencsw.org (James Lee) Date: Sun, 24 Apr 2011 13:53:44 GMT Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> <1303601852-sup-1830@pinkfloyd.chass.utoronto.ca> Message-ID: <20110424.13534400.819674305@gyor.oxdrove.co.uk> On 24/04/11, 01:21:28, Philip Brown wrote regarding Re: [csw-maintainers] Catalog generation date information in catalog/pkgutil?: > FYI, as someone pointed out, the format that James requested, is not > compliant with the relevant ISO. Because of '/' instead of '-'. I requested the catalog use standard format. The only time I used anything else was where asking for a standard label and I used a direct copy from your text (I was not talking about the date at that point). James. From rupert at opencsw.org Mon Apr 25 16:40:00 2011 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 25 Apr 2011 16:40:00 +0200 Subject: [csw-maintainers] link against an old version of neon, again ? In-Reply-To: <34A0E257-12E7-41AE-9899-65E7BE702EC1@opencsw.org> References: <03F536CB-94CE-4C95-B074-03414C4205FC@opencsw.org> <34A0E257-12E7-41AE-9899-65E7BE702EC1@opencsw.org> Message-ID: hi dago, do you think the neon 0.26.x line could be removed now? rupert On Mon, Dec 6, 2010 at 09:45, Dagobert Michelsen wrote: > Hi Rupert, > > Am 05.12.2010 um 00:05 schrieb rupert THURNER: > > On Sat, Dec 4, 2010 at 23:32, Dagobert Michelsen > wrote: > >> Am 04.12.2010 um 21:39 schrieb rupert THURNER: > >>> http://www.opencsw.org/packages/CSWneon/ shows that old versions of > neon are linked. > >> > >> It looks perfectly good to me. You are aware that 0.29.x contains > .so.27, are you? > > > > yes, but it should not link to it any more in a new release. > > It should. libneon.so.27 is *the* shared library from neon 0.29.x., > it is not old. There is no resemblance between so-numbers and > releases-numbers, essentially you have to compile a package and > look what is produced to find out about the so-numbers. > > > 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. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Mon Apr 25 18:03:23 2011 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 25 Apr 2011 18:03:23 +0200 Subject: [csw-maintainers] where hudson runs? Message-ID: some time ago there was some discussion about introducing continuous builds. is this still a topic, and if yes, where hudson runs? i would love to include the mercurial, neon, serf, and subversion builds into it. rupert -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Mon Apr 25 18:30:40 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 25 Apr 2011 09:30:40 -0700 Subject: [csw-maintainers] Catalog generation date information in catalog/pkgutil? In-Reply-To: <20110424.13534400.819674305@gyor.oxdrove.co.uk> References: <20110413105529.GB17736@sebastiankayser.de> <20110413110735.GC17736@sebastiankayser.de> <20110413.11464800.3343819048@gyor.oxdrove.co.uk> <1302712890-sup-2532@pinkfloyd.chass.utoronto.ca> <20110413.18162400.575907544@gyor.oxdrove.co.uk> <1303601852-sup-1830@pinkfloyd.chass.utoronto.ca> <20110424.13534400.819674305@gyor.oxdrove.co.uk> Message-ID: On Sun, Apr 24, 2011 at 6:53 AM, James Lee wrote: > On 24/04/11, 01:21:28, Philip Brown wrote regarding Re: > [csw-maintainers] Catalog generation date information in catalog/pkgutil?: > >> FYI, as someone pointed out, the format that James requested, is not >> compliant with the relevant ISO. Because of '/' instead of '-'. > > I requested the catalog use standard format. ?The only time I used > anything else was where asking for a standard label and I used a > direct copy from your text (I was not talking about the date at that > point). okie dokie. So you're okay with # CREATIONDATE 2011-04-21T20:10:46Z ? From bwalton at opencsw.org Tue Apr 26 04:13:23 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 25 Apr 2011 22:13:23 -0400 Subject: [csw-maintainers] where hudson runs? In-Reply-To: References: Message-ID: <1303783950-sup-5591@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Mon Apr 25 12:03:23 -0400 2011: Hi Rupert, > some time ago there was some discussion about introducing continuous > builds. is this still a topic, and if yes, where hudson runs? i > would love to include the mercurial, neon, serf, and subversion > builds into it. It was up and running at one point although I don't know that it still is. Either way, I have no memory of where it was accessibly. Trygve and Dago got it going, so maybe they can fill in the details? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Apr 26 04:23:01 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 25 Apr 2011 22:23:01 -0400 Subject: [csw-maintainers] [RFE] cswcptemplates Message-ID: <1303784385-sup-8056@pinkfloyd.chass.utoronto.ca> Hi All, I wonder if other people would find it useful for cswcptemplates to not only install template to $somedest, but to also provide a symlink from $somedest.CSW to $original. I find it's nice to have an easy side-by-side live vs default config file. Do others miss this in cptemplates (as opposed to preserveconf)? It's a trivial addition to the CAS, but maybe others prefer it not being there? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Tue Apr 26 11:46:08 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 26 Apr 2011 11:46:08 +0200 Subject: [csw-maintainers] Problem with neon rebuild References: Message-ID: <3F118A8A-E8C4-4D43-B1BB-39D6DB9891B8@opencsw.org> Hi Rupert, I appreciate your commitment in updating packages, but please do not simply change version numbers and release the package. Especially the neon package is really complicated and in flux to AUX linkage transition. That's why the alternatives mechanism has been commented out. If AUX linkage is not in place alternatives must be used or the package will not work. Additionally, the package uses a number of advanced features like on-the-fly renaming on merge which needs manual adjustment. Just changing numbers can result in broken packages as reported here: https://www.opencsw.org/mantis/view.php?id=4763 checpkg detected the errors as surplus dependencies as the packages were empty, please do not just override errors without fully understanding why they occur. In general I am happy for every package another maintainer takes over from me, but especially for a complex package like this I suggest at least pinging me for a review before the first release after takeover. I am also happy to explain the details of the recipe. For now I suggest a rollback to the previous version as the GAR recipe is in flux right now. Do you require the new neon 0.29.5 ? Best regards -- Dago Anfang der weitergeleiteten E-Mail: > Von: rthurner at users.sourceforge.net > Datum: 25. April 2011 17:58:42 MESZ > An: devel at lists.opencsw.org > Betreff: [csw-devel] SF.net SVN: gar:[14400] csw/mgar/pkg/neon/trunk/Makefile > Antwort an: Broadcasts commit logs for build descriptions and GAR > > Revision: 14400 > http://gar.svn.sourceforge.net/gar/?rev=14400&view=rev > Author: rthurner > Date: 2011-04-25 15:58:41 +0000 (Mon, 25 Apr 2011) > > Log Message: > ----------- > adjust to same checkpkg used for subversion-1.6.16 > > Modified Paths: > -------------- > csw/mgar/pkg/neon/trunk/Makefile > > Modified: csw/mgar/pkg/neon/trunk/Makefile > =================================================================== > --- csw/mgar/pkg/neon/trunk/Makefile 2011-04-25 15:08:12 UTC (rev 14399) > +++ csw/mgar/pkg/neon/trunk/Makefile 2011-04-25 15:58:41 UTC (rev 14400) > @@ -93,19 +93,6 @@ > PKGFILES_CSWneon-devel += $(docdir)/.* > > > -# ALTERNATIVES_CSWneon = minimal > -# ALTERNATIVES_CSWneonfull = full > - > -# ALTERNATIVE_minimal = $(libdir)/libneon.so.27.2.3 neon $(libdir)/libneon-minimal.so.27.2.3 100 > -# ALTERNATIVE_minimal += $(libdir)/$(ISA_DEFAULT64)/libneon.so.27.2.3 neon64 $(libdir)/$(ISA_DEFAULT64)/libneon-minimal.so.27.2.3 > -# ALTERNATIVE_minimal += $(libdir)/libneon.so.26.0.4 neon.26 $(libdir)/libneon-minimal.so.26.0.4 > -# ALTERNATIVE_minimal += $(libdir)/$(ISA_DEFAULT64)/libneon.so.26.0.4 neon64.26 $(libdir)/$(ISA_DEFAULT64)/libneon-minimal.so.26.0.4 > - > -# ALTERNATIVE_full = $(libdir)/libneon.so.27.2.3 neon $(libdir)/libneon-full.so.27.2.3 200 > -# ALTERNATIVE_full += $(libdir)/$(ISA_DEFAULT64)/libneon.so.27.2.3 neon64 $(libdir)/$(ISA_DEFAULT64)/libneon-full.so.27.2.3 > -# ALTERNATIVE_full += $(libdir)/libneon.so.26.0.4 neon.26 $(libdir)/libneon-full.so.26.0.4 > -# ALTERNATIVE_full += $(libdir)/$(ISA_DEFAULT64)/libneon.so.26.0.4 neon64.26 $(libdir)/$(ISA_DEFAULT64)/libneon-full.so.26.0.4 > - > FEATURE_LIBRARIES = libneon.26 libneon64.26 > FEATURE_LIBRARIES += libneon.27 libneon64.27 > FEATURES_libneon.26 = $(libdir)/libneon.so.26.0.4 > @@ -126,7 +113,19 @@ > CHECKPKG_OVERRIDES_CSWneonfull += bad-rpath-entry|/opt/csw/lib/|opt/csw/lib/libneon-full.so.27.2.3 > > CHECKPKG_OVERRIDES_CSWneon-devel += surplus-dependency|CSWneon > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWpakchois > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWosslrt > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWggettextrt > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWzlib > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWexpat > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWkrb5lib > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWlibproxy > +CHECKPKG_OVERRIDES_CSWneon += surplus-dependency|CSWexpat > +CHECKPKG_OVERRIDES_CSWneon += surplus-dependency|CSWosslrt > +CHECKPKG_OVERRIDES_CSWneon += surplus-dependency|CSWggettextrt > +CHECKPKG_OVERRIDES_CSWneon += surplus-dependency|CSWzlib > > + > include gar/category.mk > > #post-install-modulated: > > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > _______________________________________________ > devel mailing list > devel at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/devel From dam at opencsw.org Tue Apr 26 11:52:07 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 26 Apr 2011 11:52:07 +0200 Subject: [csw-maintainers] where hudson runs? In-Reply-To: <1303783950-sup-5591@pinkfloyd.chass.utoronto.ca> References: <1303783950-sup-5591@pinkfloyd.chass.utoronto.ca> Message-ID: <4213BB69-A4F2-4EB4-9071-008F7C59A26C@opencsw.org> Hi, Am 26.04.2011 um 04:13 schrieb Ben Walton: > Excerpts from rupert THURNER's message of Mon Apr 25 12:03:23 -0400 2011: > >> some time ago there was some discussion about introducing continuous >> builds. is this still a topic, and if yes, where hudson runs? i >> would love to include the mercurial, neon, serf, and subversion >> builds into it. > > It was up and running at one point although I don't know that it still > is. Either way, I have no memory of where it was accessibly. Trygve > and Dago got it going, so maybe they can fill in the details? Hudson is disabled right now, but it would be good to reenable it on upstream watch autobump. Probably during the summercamp would be good. Best regards -- Dago From dam at opencsw.org Tue Apr 26 11:54:03 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 26 Apr 2011 11:54:03 +0200 Subject: [csw-maintainers] link against an old version of neon, again ? In-Reply-To: References: <03F536CB-94CE-4C95-B074-03414C4205FC@opencsw.org> <34A0E257-12E7-41AE-9899-65E7BE702EC1@opencsw.org> Message-ID: <347BBDE9-9E74-4702-8F5C-C28AD4FFDAF9@opencsw.org> Hi Rupert, Am 25.04.2011 um 16:40 schrieb rupert THURNER: > do you think the neon 0.26.x line could be removed now? Probably not, but I cannot look now. Usually the package page shows other packeges linking to a library, but as the currently released package is empty the display doesn't work right now. The package should be split according to the new library naming standards. Best regards -- Dago From rupert at opencsw.org Tue Apr 26 21:32:49 2011 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 26 Apr 2011 21:32:49 +0200 Subject: [csw-maintainers] Problem with neon rebuild In-Reply-To: <3F118A8A-E8C4-4D43-B1BB-39D6DB9891B8@opencsw.org> References: <3F118A8A-E8C4-4D43-B1BB-39D6DB9891B8@opencsw.org> Message-ID: hi dago, sorry for this, you are of course right. I have nothing against a quick roll back. rupert On Apr 26, 2011 11:46 AM, "Dagobert Michelsen" wrote: Hi Rupert, I appreciate your commitment in updating packages, but please do not simply change version numbers and release the package. Especially the neon package is really complicated and in flux to AUX linkage transition. That's why the alternatives mechanism has been commented out. If AUX linkage is not in place alternatives must be used or the package will not work. Additionally, the package uses a number of advanced features like on-the-fly renaming on merge which needs manual adjustment. Just changing numbers can result in broken packages as reported here: https://www.opencsw.org/mantis/view.php?id=4763 checpkg detected the errors as surplus dependencies as the packages were empty, please do not just override errors without fully understanding why they occur. In general I am happy for every package another maintainer takes over from me, but especially for a complex package like this I suggest at least pinging me for a review before the first release after takeover. I am also happy to explain the details of the recipe. For now I suggest a rollback to the previous version as the GAR recipe is in flux right now. Do you require the new neon 0.29.5 ? Best regards -- Dago Anfang der weitergeleiteten E-Mail: > Von: rthurner at users.sourceforge.net > Datum: 25. April 2011 17:58:42 MESZ > An: devel at lists.opencsw.org > Betreff: [csw-devel] SF.net SVN: gar:[14400] csw/mgar/pkg/neon/trunk/Makefile > Antwort an: Broadcasts commit logs for build descriptions and GAR < devel at lists.opencsw.org> > > Revision: 14400 > http://gar.svn.sourceforge.net/gar/?rev=14400&view=rev > Author: rthurner > Date: 2011-04-25 15:58:41 +0000 (Mon, 25 Apr 2011) > > Log Message: > ----------- > adjust to same checkpkg used for subversion-1.6.16 > > Modified Paths: > -------------- > csw/mgar/pkg/neon/trunk/Makefile > > Modified: csw/mgar/pkg/neon/trunk/Makefile > =================================================================== > --- csw/mgar/pkg/neon/trunk/Makefile 2011-04-25 15:08:12 UTC (rev 14399) > +++ csw/mgar/pkg/neon/trunk/Makefile 2011-04-25 15:58:41 UTC (rev 14400) > @@ -93,19 +93,6 @@ > PKGFILES_CSWneon-devel += $(docdir)/.* > > > -# ALTERNATIVES_CSWneon = minimal > -# ALTERNATIVES_CSWneonfull = full > - > -# ALTERNATIVE_minimal = $(libdir)/libneon.so.27.2.3 neon $(libdir)/libneon-minimal.so.27.2.3 100 > -# ALTERNATIVE_minimal += $(libdir)/$(ISA_DEFAULT64)/libneon.so.27.2.3 neon64 $(libdir)/$(ISA_DEFAULT64)/libneon-minimal.so.27.2.3 > -# ALTERNATIVE_minimal += $(libdir)/libneon.so.26.0.4 neon.26 $(libdir)/libneon-minimal.so.26.0.4 > -# ALTERNATIVE_minimal += $(libdir)/$(ISA_DEFAULT64)/libneon.so.26.0.4 neon64.26 $(libdir)/$(ISA_DEFAULT64)/libneon-minimal.so.26.0.4 > - > -# ALTERNATIVE_full = $(libdir)/libneon.so.27.2.3 neon $(libdir)/libneon-full.so.27.2.3 200 > -# ALTERNATIVE_full += $(libdir)/$(ISA_DEFAULT64)/libneon.so.27.2.3 neon64 $(libdir)/$(ISA_DEFAULT64)/libneon-full.so.27.2.3 > -# ALTERNATIVE_full += $(libdir)/libneon.so.26.0.4 neon.26 $(libdir)/libneon-full.so.26.0.4 > -# ALTERNATIVE_full += $(libdir)/$(ISA_DEFAULT64)/libneon.so.26.0.4 neon64.26 $(libdir)/$(ISA_DEFAULT64)/libneon-full.so.26.0.4 > - > FEATURE_LIBRARIES = libneon.26 libneon64.26 > FEATURE_LIBRARIES += libneon.27 libneon64.27 > FEATURES_libneon.26 = $(libdir)/libneon.so.26.0.4 > @@ -126,7 +113,19 @@ > CHECKPKG_OVERRIDES_CSWneonfull += bad-rpath-entry|/opt/csw/lib/|opt/csw/lib/libneon-full.so.27.2.3 > > CHECKPKG_OVERRIDES_CSWneon-devel += surplus-dependency|CSWneon > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWpakchois > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWosslrt > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWggettextrt > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWzlib > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWexpat > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWkrb5lib > +CHECKPKG_OVERRIDES_CSWneonfull += surplus-dependency|CSWlibproxy > +CHECKPKG_OVERRIDES_CSWneon += surplus-dependency|CSWexpat > +CHECKPKG_OVERRIDES_CSWneon += surplus-dependency|CSWosslrt > +CHECKPKG_OVERRIDES_CSWneon += surplus-dependency|CSWggettextrt > +CHECKPKG_OVERRIDES_CSWneon += surplus-dependency|CSWzlib > > + > include gar/category.mk > > #post-install-modulated: > > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > _______________________________________________ > devel mailing list > devel at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Tue Apr 26 21:47:50 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 26 Apr 2011 12:47:50 -0700 Subject: [csw-maintainers] Problem with neon rebuild In-Reply-To: References: <3F118A8A-E8C4-4D43-B1BB-39D6DB9891B8@opencsw.org> Message-ID: On Tue, Apr 26, 2011 at 12:32 PM, rupert THURNER wrote: > hi dago, sorry for this, you are of course right. I have nothing against a > quick roll back. > For me, there is no such thing as a "quick" rollback. (unless someone ELSE does the work of resubmitting the older packages :p ) From dam at opencsw.org Tue Apr 26 22:56:55 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 26 Apr 2011 22:56:55 +0200 Subject: [csw-maintainers] Problem with neon rebuild In-Reply-To: References: <3F118A8A-E8C4-4D43-B1BB-39D6DB9891B8@opencsw.org> Message-ID: <6527AC3D-E58C-4877-902B-398A9049451C@opencsw.org> Hi Rupert, Am 26.04.2011 um 21:32 schrieb rupert THURNER: > hi dago, sorry for this, you are of course right. I have nothing against a quick roll back. > Ok, would you mind submitting the previous ones from here? http://mirror.opencsw.org/opencsw-future/allpkgs/ Best regards -- Dago -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Wed Apr 27 16:02:19 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 27 Apr 2011 16:02:19 +0200 Subject: [csw-maintainers] Problem with neon rebuild In-Reply-To: References: <3F118A8A-E8C4-4D43-B1BB-39D6DB9891B8@opencsw.org> Message-ID: Hi everybody, Am 26.04.2011 um 21:32 schrieb rupert THURNER: > just thought it ll be great to have the newest dependencies for a new subversion release. > > maybe adding a comment in the makefile would be appropriate in such a case? > > would it be sensible to split up neon in two to take some complexity out? I updated all build reciped in one large swoop. Updated packages are available at http://buildfarm.opencsw.org/experimental.html#libneon If anybody has some time to test: please test them as soon as possible as the current ones are broken. I have installed them on testing* and they look good to me. Best regards -- Dago From maciej at opencsw.org Thu Apr 28 00:10:10 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 27 Apr 2011 23:10:10 +0100 Subject: [csw-maintainers] Problem with neon rebuild In-Reply-To: References: <3F118A8A-E8C4-4D43-B1BB-39D6DB9891B8@opencsw.org> Message-ID: I remember a discussion about potential checks that could help identify problems caused by package upgrades, but problems occurring with other packages rather than the package being upgraded. If we had such automation, it would prevent problems like this one from happening in the future. The basic plan would be: - establish a list of packages potentially affected by the planned upgrade - run checkpkg against this set of packages and record all non overridden errors thrown by checkpkg. The set of packages should not include the packages from theplanned upgrade. - run checkpkg again, against a slightly modified set of packages: this time include the new versions of the packages to upgrade - if any new errors are thrown, it means that our upgrade breaks other packages and it should be stopped. I'm sure there's a fair amount of devil to be in the details, but this check looks doable to me. I don't have ideas what false positives would we get from it. They would be hard to override, especially if they concern legacy packages. This mechanism would be best a wrapper around checkpkg. I don't want to add more functionality to the core checkpkg executable unless really necessary. If anyone is up for implementing this functionality, I'll be happy lend a hand and show where to get resources, e.g. json catalog representations. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Apr 28 08:17:12 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Apr 2011 08:17:12 +0200 Subject: [csw-maintainers] Problem with neon rebuild In-Reply-To: References: <3F118A8A-E8C4-4D43-B1BB-39D6DB9891B8@opencsw.org> Message-ID: <4A343C3F-B98C-469B-A570-992EDAFE5E1E@opencsw.org> Hi Maciej, Am 28.04.2011 um 00:10 schrieb Maciej Blizi?ski: > I remember a discussion about potential checks that could help identify problems caused by package upgrades, but problems occurring with other packages rather than the package being upgraded. If we had such automation, it would prevent problems like this one from happening in the future. > > The basic plan would be: > > - establish a list of packages potentially affected by the planned upgrade - run checkpkg against this set of packages and record all non overridden errors thrown by checkpkg. The set of packages should not include the packages from theplanned upgrade. - run checkpkg again, against a slightly modified set of packages: this time include the new versions of the packages to upgrade - if any new errors are thrown, it means that our upgrade breaks other packages and it should be stopped. > > I'm sure there's a fair amount of devil to be in the details, but this check looks doable to me. I don't have ideas what false positives would we get from it. They would be hard to override, especially if they concern legacy packages. The heuristics to find out which packages could be affected sounds difficult. The other idea was to check against the whole catalog and see if more errors happen on the updated package, which required performance tuning of the code... > This mechanism would be best a wrapper around checkpkg. I don't want to add more functionality to the core checkpkg executable unless really necessary. > > If anyone is up for implementing this functionality, I'll be happy lend a hand and show where to get resources, e.g. json catalog representations. Best regards -- Dago From dam at opencsw.org Thu Apr 28 08:18:11 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Apr 2011 08:18:11 +0200 Subject: [csw-maintainers] Available atom feeds Message-ID: Hi, I remember there is a feed about checkpkg activity going on and changes on unstable/ and stuff. Could someone please reply so I can list them on https://www.opencsw.org/feeds/ ? Best regards -- Dago From ja at opencsw.org Thu Apr 28 11:26:12 2011 From: ja at opencsw.org (Juergen Arndt) Date: Thu, 28 Apr 2011 11:26:12 +0200 Subject: [csw-maintainers] [RFE] cswcptemplates In-Reply-To: <1303784385-sup-8056@pinkfloyd.chass.utoronto.ca> References: <1303784385-sup-8056@pinkfloyd.chass.utoronto.ca> Message-ID: <69F745A4-EAB2-45B4-AD89-99484F37A2AD@opencsw.org> On 26.04.2011, at 04:23, Ben Walton wrote: > I wonder if other people would find it useful for cswcptemplates to > not only install template to $somedest, but to also provide a symlink > from $somedest.CSW to $original. I find it's nice to have an easy > side-by-side live vs default config file. Do others miss this in > cptemplates (as opposed to preserveconf)? It's a trivial addition to > the CAS, but maybe others prefer it not being there? I don't really miss this, but I agree, that it would be nice to be able to easily access the default configuration. Best regards Juergen -- Juergen Arndt From bwalton at opencsw.org Thu Apr 28 15:02:48 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 28 Apr 2011 09:02:48 -0400 Subject: [csw-maintainers] Available atom feeds In-Reply-To: References: Message-ID: <1303995507-sup-9833@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Apr 28 02:18:11 -0400 2011: Hi Dago, > I remember there is a feed about checkpkg activity going on and > changes on unstable/ and stuff. Could someone please reply so I > can list them on > https://www.opencsw.org/feeds/ > ? I'm currently monitoring all catalog changes with feed at http://buildfarm.opencsw.org/~bwalton/ This needs a more permanent home (cron running on unstable9x using rb18_ratom currently. I also still plan to do an aggregated (cross-catalog) feed. I might tackle that this weekend, time permitting. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Thu Apr 28 15:58:52 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Apr 2011 15:58:52 +0200 Subject: [csw-maintainers] Available atom feeds In-Reply-To: <1303995507-sup-9833@pinkfloyd.chass.utoronto.ca> References: <1303995507-sup-9833@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, Am 28.04.2011 um 15:02 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Thu Apr 28 02:18:11 -0400 2011: >> I remember there is a feed about checkpkg activity going on and >> changes on unstable/ and stuff. Could someone please reply so I >> can list them on >> https://www.opencsw.org/feeds/ >> ? > > I'm currently monitoring all catalog changes with feed at > http://buildfarm.opencsw.org/~bwalton/ > > This needs a more permanent home (cron running on unstable9x using > rb18_ratom currently. > > I also still plan to do an aggregated (cross-catalog) feed. I might > tackle that this weekend, time permitting. Cool. I remember there was another feed which showed checkpkg activity on the buildfarm. Do you remember which was it? Best regards -- Dago From bwalton at opencsw.org Thu Apr 28 16:01:56 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 28 Apr 2011 10:01:56 -0400 Subject: [csw-maintainers] Available atom feeds In-Reply-To: References: <1303995507-sup-9833@pinkfloyd.chass.utoronto.ca> Message-ID: <1303999291-sup-4070@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Apr 28 09:58:52 -0400 2011: Hi Dao, > Cool. I remember there was another feed which showed checkpkg > activity on the buildfarm. Do you remember which was it? No, sorry. I wasn't aware such a thing existed. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Apr 28 17:10:01 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 28 Apr 2011 16:10:01 +0100 Subject: [csw-maintainers] Available atom feeds In-Reply-To: <1303999291-sup-4070@pinkfloyd.chass.utoronto.ca> References: <1303995507-sup-9833@pinkfloyd.chass.utoronto.ca> <1303999291-sup-4070@pinkfloyd.chass.utoronto.ca> Message-ID: Em 28/04/2011 16:02, "Ben Walton" escreveu: > > Excerpts from Dagobert Michelsen's message of Thu Apr 28 09:58:52 -0400 2011: > > Hi Dao, > > > Cool. I remember there was another feed which showed checkpkg > > activity on the buildfarm. Do you remember which was it? > > No, sorry. I wasn't aware such a thing existed. I noticed that yesterday during the recording of the show. Simon asked about the activity on the buildfarm. You can view it live if you start at buildfarm.opencsw.org and follow the signs. It's not a feed though. It shows a fixed number of most recently checked packages. We could make it a feed without much effort I suppose. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Apr 28 17:12:01 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Apr 2011 17:12:01 +0200 Subject: [csw-maintainers] Available atom feeds In-Reply-To: References: <1303995507-sup-9833@pinkfloyd.chass.utoronto.ca> <1303999291-sup-4070@pinkfloyd.chass.utoronto.ca> Message-ID: <977F603E-1B18-4B83-8343-EFB9A2920EBE@opencsw.org> Hi, Am 28.04.2011 um 17:10 schrieb Maciej Blizi?ski: > m 28/04/2011 16:02, "Ben Walton" escreveu: > > > > Excerpts from Dagobert Michelsen's message of Thu Apr 28 09:58:52 -0400 2011: > > > > Hi Dao, > > > > > Cool. I remember there was another feed which showed checkpkg > > > activity on the buildfarm. Do you remember which was it? > > > > No, sorry. I wasn't aware such a thing existed. > > I noticed that yesterday during the recording of the show. Simon asked about the activity on the buildfarm. You can view it live if you start at buildfarm.opencsw.org and follow the signs. It's not a feed though. It shows a fixed number of most recently checked packages. We could make it a feed without much effort I suppose > > This is exactly what I was looking for: http://buildfarm.opencsw.org/pkgdb/srv4/ If it was a feed it would be nice to include on the front page to show some real up to date activity. Best regards -- Dago -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Thu Apr 28 20:44:42 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 28 Apr 2011 11:44:42 -0700 Subject: [csw-maintainers] [RFE] cswcptemplates In-Reply-To: <69F745A4-EAB2-45B4-AD89-99484F37A2AD@opencsw.org> References: <1303784385-sup-8056@pinkfloyd.chass.utoronto.ca> <69F745A4-EAB2-45B4-AD89-99484F37A2AD@opencsw.org> Message-ID: On Thu, Apr 28, 2011 at 2:26 AM, Juergen Arndt wrote: > On 26.04.2011, at 04:23, Ben Walton wrote: > >> I wonder if other people would find it useful for cswcptemplates to >> not only install template to $somedest, but to also provide a symlink >> from $somedest.CSW to $original. ?I find it's nice to have an easy >> side-by-side live vs default config file. ?Do others miss this in >> cptemplates (as opposed to preserveconf)? ?It's a trivial addition to >> the CAS, but maybe others prefer it not being there? > > > I don't really miss this, but I agree, that it would be nice to be able to easily access the default configuration. I hope someone will feel free to code it :) and also while you're in the vicinity, to look at the permissions/ownership issue. From bwalton at opencsw.org Thu Apr 28 20:46:28 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 28 Apr 2011 14:46:28 -0400 Subject: [csw-maintainers] [RFE] cswcptemplates In-Reply-To: References: <1303784385-sup-8056@pinkfloyd.chass.utoronto.ca> <69F745A4-EAB2-45B4-AD89-99484F37A2AD@opencsw.org> Message-ID: <1304016355-sup-238@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Apr 28 14:44:42 -0400 2011: > I hope someone will feel free to code it :) Well, I'm requesting it, so I don't mind writing it. I just didn't want to bother if others thought it was useless noise. > and also while you're in the vicinity, to look at the > permissions/ownership issue. Roger that. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Apr 28 23:59:12 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 28 Apr 2011 22:59:12 +0100 Subject: [csw-maintainers] Problem with neon rebuild In-Reply-To: <4A343C3F-B98C-469B-A570-992EDAFE5E1E@opencsw.org> References: <3F118A8A-E8C4-4D43-B1BB-39D6DB9891B8@opencsw.org> <4A343C3F-B98C-469B-A570-992EDAFE5E1E@opencsw.org> Message-ID: Em 28/04/2011 08:17, "Dagobert Michelsen" escreveu: > > Hi Maciej, > > Am 28.04.2011 um 00:10 schrieb Maciej Blizi?ski: > > I remember a discussion about potential checks that could help identify problems caused by package upgrades, but problems occurring with other packages rather than the package being upgraded. If we had such automation, it would prevent problems like this one from happening in the future. > > > > The basic plan would be: > > > > - establish a list of packages potentially affected by the planned upgrade - run checkpkg against this set of packages and record all non overridden errors thrown by checkpkg. The set of packages should not include the packages from theplanned upgrade. - run checkpkg again, against a slightly modified set of packages: this time include the new versions of the packages to upgrade - if any new errors are thrown, it means that our upgrade breaks other packages and it should be stopped. > > > > I'm sure there's a fair amount of devil to be in the details, but this check looks doable to me. I don't have ideas what false positives would we get from it. They would be hard to override, especially if they concern legacy packages. > > The heuristics to find out which packages could be affected sounds difficult. The first heuristic could be to look at dependent packages, let's say up to 2 levels. This way we'd catch issues with package renames. > The other idea was to check against the whole catalog and see if more errors > happen on the updated package, which required performance tuning of the code... Analyzing the whole catalog is potentially doable, but requires significant work. I think I did describe the issue before; it's the lookups of packages by file name and catalog. They require a couple of table joins, and keep on beings slow despite indexes on all foreign keys. A solution to that would be schema denormalization and additional code to handle catalog updates. That would probably not be sufficient for practical use, as the fastest whole catalog run ever achieved was about one hour. To insert a batch of packages, you would typically need to make ckecks for: 2 architectures times 3 OS releases times 2 states (before upgrade, after upgrade). This amounts to 12h (per batch) in the best case. This would limit us to 2 catalog update attempts a day. There is a lot of space for optimization and parallelism, so we can achieve reasonable performance at some point. It will require a significant amount of development work and testing. It's hard to make precise estimates, but at the rate of our development we could optimize file-to-package in about 4 to 8 weeks of focused effort. That wouldn't necessary mean making that many whole catalog runs feasible. It would be a necessary step though. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Fri Apr 29 04:02:05 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 28 Apr 2011 22:02:05 -0400 Subject: [csw-maintainers] write access to tape devices Message-ID: <1304042353-sup-9634@pinkfloyd.chass.utoronto.ca> Hi All, I want to have the new bacula packages run as non-root while still allowing them to write to tape devices. I've never used tape backup on solaris before...Can someone confirm that group membership in 'sys' is good enough to allow this? Poking at a few of my systems seem to indicate that this fits with the /devices/ target of /dev/rmt/0, but I'd rather hear from someone with experience. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri Apr 29 07:57:07 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 29 Apr 2011 06:57:07 +0100 Subject: [csw-maintainers] Available atom feeds In-Reply-To: <1303995507-sup-9833@pinkfloyd.chass.utoronto.ca> References: <1303995507-sup-9833@pinkfloyd.chass.utoronto.ca> Message-ID: Em 28/04/2011 15:02, "Ben Walton" escreveu: > > Excerpts from Dagobert Michelsen's message of Thu Apr 28 02:18:11 -0400 2011: > > Hi Dago, > > > I remember there is a feed about checkpkg activity going on and > > changes on unstable/ and stuff. Could someone please reply so I > > can list them on > > https://www.opencsw.org/feeds/ > > ? > > I'm currently monitoring all catalog changes with feed at > http://buildfarm.opencsw.org/~bwalton/ Hi Ben, Could you modify the feed from the current catalog so it's called 'current' rather than 'unstable'? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri Apr 29 14:49:24 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 29 Apr 2011 13:49:24 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] PRIORITY: Mirror push In-Reply-To: <6E992EEE-B854-43F5-AB7C-D7CCDE1F8211@opencsw.org> References: <6E992EEE-B854-43F5-AB7C-D7CCDE1F8211@opencsw.org> Message-ID: [+maintainers] 2011/4/29 Dagobert Michelsen : > Hi Phil, > > please make sure to push the mirror ASAP as the current neon is broken > and hurts a lot of users. Looks like we can't get hold of the primary release manager. Can the secondary release manager kick in and do the push? Maciej P.S. Not sure if the secondary is on the pkgsubmissions mailing list, so I'm cross-posting on maintainers at . From bwalton at opencsw.org Fri Apr 29 17:13:35 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 29 Apr 2011 11:13:35 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] PRIORITY: Mirror push In-Reply-To: References: <6E992EEE-B854-43F5-AB7C-D7CCDE1F8211@opencsw.org> Message-ID: <1304089947-sup-4928@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Apr 29 11:10:03 -0400 2011: [-pkgsubmissions, +maintainers] Hi Phil, > Sorry, didnt remember that neon was that important, and forgot to > push yesterday. But it went out a coupla hours ago. Is there a technical reason why pushes don't happen after every set of batching operations? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Apr 29 17:14:49 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 29 Apr 2011 08:14:49 -0700 Subject: [csw-maintainers] write access to tape devices In-Reply-To: <1304042353-sup-9634@pinkfloyd.chass.utoronto.ca> References: <1304042353-sup-9634@pinkfloyd.chass.utoronto.ca> Message-ID: Yes that's the typical way to go... however, keep in mind that group sys also gives read access to RAM. (ie /dev/(memory), whatever itis ) so you arent being that much more "secure" by putting bacula in group sys. On Thu, Apr 28, 2011 at 7:02 PM, Ben Walton wrote: > > Hi All, > > I want to have the new bacula packages run as non-root while still > allowing them to write to tape devices. ?I've never used tape backup > on solaris before...Can someone confirm that group membership in 'sys' > is good enough to allow this? ?Poking at a few of my systems seem to > indicate that this fits with the /devices/ target of /dev/rmt/0, but > I'd rather hear from someone with experience. > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From bwalton at opencsw.org Fri Apr 29 17:18:32 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 29 Apr 2011 11:18:32 -0400 Subject: [csw-maintainers] write access to tape devices In-Reply-To: References: <1304042353-sup-9634@pinkfloyd.chass.utoronto.ca> Message-ID: <1304090190-sup-6499@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Apr 29 11:14:49 -0400 2011: Hi Phil, > so you arent being that much more "secure" by putting bacula in > group sys. Well, I'm trying to have the daemons run with uid != 0, but the storage daemon in some configs will need tape access, so I need to make sure it has the required rights. Thanks for the info though. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Apr 29 17:18:38 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 29 Apr 2011 08:18:38 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] PRIORITY: Mirror push In-Reply-To: <1304089947-sup-4928@pinkfloyd.chass.utoronto.ca> References: <6E992EEE-B854-43F5-AB7C-D7CCDE1F8211@opencsw.org> <1304089947-sup-4928@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Apr 29, 2011 at 8:13 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Apr 29 11:10:03 -0400 2011: > > [-pkgsubmissions, +maintainers] > > Hi Phil, > >> Sorry, didnt remember that neon was that important, and forgot to >> push yesterday. But it went out a coupla hours ago. > > Is there a technical reason why pushes don't happen after every set of > batching operations? > depends what you mean by "set". If you mean, "after every group of submitted packages", then yes. The answer being that the pre-push validation process + signing, takes about 30 minutes. (and it's mostly scripted, not manual, even) That's why this is a "batch" process From bwalton at opencsw.org Fri Apr 29 18:45:55 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 29 Apr 2011 12:45:55 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] PRIORITY: Mirror push In-Reply-To: References: <6E992EEE-B854-43F5-AB7C-D7CCDE1F8211@opencsw.org> <1304089947-sup-4928@pinkfloyd.chass.utoronto.ca> Message-ID: <1304095437-sup-3038@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Apr 29 11:18:38 -0400 2011: > depends what you mean by "set". You typically process a bunch of requests as a group. These tend to be at certain times of day (eg: a regularly occurring event). I'm suggesting that a push always happen when you're done processing items from your mailbox. If you do two processing (batched/rejected) runs per day, push twice a day. If you do three rounds, push three times, etc. Thanks -ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Apr 29 20:04:43 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 29 Apr 2011 11:04:43 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] PRIORITY: Mirror push In-Reply-To: <1304095437-sup-3038@pinkfloyd.chass.utoronto.ca> References: <6E992EEE-B854-43F5-AB7C-D7CCDE1F8211@opencsw.org> <1304089947-sup-4928@pinkfloyd.chass.utoronto.ca> <1304095437-sup-3038@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Apr 29, 2011 at 9:45 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Apr 29 11:18:38 -0400 2011: > >> depends what you mean by "set". > > You typically process a bunch of requests as a group. ?These tend to > be at certain times of day (eg: a regularly occurring event). not really at certain times of day. > ?I'm > suggesting that a push always happen when you're done processing items > from your mailbox. ?If you do two processing (batched/rejected) runs > per day, push twice a day. ?If you do three rounds, push three times, > etc. I USUALLY do a push, once I reach a point where I dont think I'm going to be processing any more packages that day. Unfortunately, in this occurrence, I forgot to. From phil at bolthole.com Sat Apr 30 17:51:19 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 30 Apr 2011 08:51:19 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] PRIORITY: Mirror push In-Reply-To: References: <6E992EEE-B854-43F5-AB7C-D7CCDE1F8211@opencsw.org> <1304089947-sup-4928@pinkfloyd.chass.utoronto.ca> <1304095437-sup-3038@pinkfloyd.chass.utoronto.ca> Message-ID: btw, you'll be happy to know, that I just rigged up a crontab, that reminds me after a few hours if there is stuff that is batched, but not pushed. From maciej.blizinski at gmail.com Thu Apr 28 00:07:40 2011 From: maciej.blizinski at gmail.com (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 27 Apr 2011 22:07:40 -0000 Subject: [csw-maintainers] Problem with neon rebuild In-Reply-To: References: <3F118A8A-E8C4-4D43-B1BB-39D6DB9891B8@opencsw.org> Message-ID: I remember a discussion about potential checks that could help identify problems caused by package upgrades, but problems occurring with other packages rather than the package being upgraded. If we had such automation, it would prevent problems like this one from happening in the future. The basic plan would be: - establish a list of packages potentially affected by the planned upgrade - run checkpkg against this set of packages and record all non overridden errors thrown by checkpkg. The set of packages should not include the packages from theplanned upgrade. - run checkpkg again, against a slightly modified set of packages: this time include the new versions of the packages to upgrade - if any new errors are thrown, it means that our upgrade breaks other packages and it should be stopped. I'm sure there's a fair amount of devil to be in the details, but this check looks doable to me. I don't have ideas what false positives would we get from it. They would be hard to override, especially if they concern legacy packages. This mechanism would be best a wrapper around checkpkg. I don't want to add more functionality to the core checkpkg executable unless really necessary. If anyone is up for implementing this functionality, I'll be happy lend a hand and show where to get resources, e.g. json catalog representations. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert.thurner at gmail.com Wed Apr 20 08:19:52 2011 From: rupert.thurner at gmail.com (rupert THURNER) Date: Wed, 20 Apr 2011 06:19:52 -0000 Subject: [csw-maintainers] GAR: move to mako for newpkg templates? In-Reply-To: <4DAE0864.9010900@opencsw.org> References: <20110418221000.GJ17736@sebastiankayser.de> <4DAE0864.9010900@opencsw.org> Message-ID: is there a special reason why you chose mako and not jinja2? On Apr 20, 2011 12:10 AM, "Sebastian Kayser" wrote: Dagobert Michelsen wrote on 4/19/2011 9:48 PM: > Am 19.04.2011 um 00:10 schrieb Sebastian Kayser: >> any objections for moving GAR's newpkg templat... Cool, committed with r14331. The per sub-directory newpkg-stubs are still sort of duplicated effort, but this will likely soon go away with mgar anyway. Sebastian _______________________________________________ maintainers mailing list maintainers at lists.opencsw.o... -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej.blizinski at gmail.com Thu Apr 28 16:46:50 2011 From: maciej.blizinski at gmail.com (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 28 Apr 2011 14:46:50 -0000 Subject: [csw-maintainers] Problem with neon rebuild In-Reply-To: References: Message-ID: Em 28/04/2011 08:17, "Dagobert Michelsen" escreveu: > > Hi Maciej, > > Am 28.04.2011 um 00:10 schrieb Maciej Blizi?ski: > > I remember a discussion about potential checks that could help identify problems caused by package upgrades, but problems occurring with other packages rather than the package being upgraded. If we had such automation, it would prevent problems like this one from happening in the future. > > > > The basic plan would be: > > > > - establish a list of packages potentially affected by the planned upgrade - run checkpkg against this set of packages and record all non overridden errors thrown by checkpkg. The set of packages should not include the packages from theplanned upgrade. - run checkpkg again, against a slightly modified set of packages: this time include the new versions of the packages to upgrade - if any new errors are thrown, it means that our upgrade breaks other packages and it should be stopped. > > > > I'm sure there's a fair amount of devil to be in the details, but this check looks doable to me. I don't have ideas what false positives would we get from it. They would be hard to override, especially if they concern legacy packages. > > The heuristics to find out which packages could be affected sounds difficult. > The other idea was to check against the whole catalog and see if more errors > happen on the updated package, which required performance tuning of the code... The first heuristic could be to look at dependent packages, let's say up to 2 levels. This way we'd catch issues with package renames. Analyzing the whole catalog is potentially doable, but requires significant work. I think I did describe the issue before; it's the lookups of packages by file name and catalog. They require a couple of table joins, and keep on beings slow despite indexes on all foreign keys. A solution to that would be schema denormalization and additional code to handle catalog updates. That would probably not be sufficient for practical use, as the fastest whole catalog run ever achieved was about one hour. To insert a batch of packages, you would typically need to make ckecks for: 2 architectures times 3 OS releases times 2 states (before upgrade, after upgrade). This amounts to 12h (per batch) in the best case. This would limit us to 2 catalog update attempts a day. There is a lot of space for optimization and parallelism, so we can achieve reasonable performance at some point. It will require a significant amount of development work and testing. It's hard to make precise estimates, but at the rate of our development we could optimize file-to-package in about 4 to 8 weeks of focused effort. That wouldn't necessary mean making that many whole catalog runs feasible. It would be a necessary step though. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej.blizinski at gmail.com Thu Apr 28 17:03:24 2011 From: maciej.blizinski at gmail.com (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 28 Apr 2011 15:03:24 -0000 Subject: [csw-maintainers] Available atom feeds In-Reply-To: <1303999291-sup-4070@pinkfloyd.chass.utoronto.ca> References: <1303995507-sup-9833@pinkfloyd.chass.utoronto.ca> <1303999291-sup-4070@pinkfloyd.chass.utoronto.ca> Message-ID: Em 28/04/2011 16:02, "Ben Walton" escreveu: > > Excerpts from Dagobert Michelsen's message of Thu Apr 28 09:58:52 -0400 2011: > > Hi Dao, > > > Cool. I remember there was another feed which showed checkpkg > > activity on the buildfarm. Do you remember which was it? > > No, sorry. I wasn't aware such a thing existed. I noticed that yesterday during the recording of the show. Simon asked about the activity on the buildfarm. You can view it live if you start at buildfarm.opencsw.org and follow the signs. It's not a feed though. It shows a fixed number of most recently checked packages. We could make it a feed without much effort I suppose. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: