From bonivart at opencsw.org Tue Sep 1 00:09:16 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 1 Sep 2009 00:09:16 +0200 Subject: [csw-maintainers] Firefox 3 release In-Reply-To: <4A9C47D6.4010501@wbonnet.net> References: <4A9C47D6.4010501@wbonnet.net> Message-ID: <625385e30908311509x7959e9cdn520bd4421c3e21c6@mail.gmail.com> On Mon, Aug 31, 2009 at 11:59 PM, William Bonnet wrote: > Hi, > > I'm pleased to announced that Firefox 3.0.13 has been pushed to current. > This version supports Solaris 8 and newer (thanks goes to James Lee for > pointing me the solution). > > Thunderbird has also been updated to version 2.0.0.23, latest stable before > TB3 is released. Nice work! Very high profile packages. -- /peter From trygvis at opencsw.org Tue Sep 1 01:06:35 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 01 Sep 2009 01:06:35 +0200 Subject: [csw-maintainers] robots.txt In-Reply-To: References: <4A9C3D84.5080609@opencsw.org> Message-ID: <4A9C577B.80509@opencsw.org> Philip Brown wrote: > 2009/8/31 Trygve Laugst?l : >> Philip Brown wrote: >>> Any robot that cant figure out to properly prune /page vs >>> /page.php, in this day and age, is a broken robot. >>> We should not modify our configs to make dumb robots look better than they >>> are. >> Actually, they're not. There's no way for the engines out there to know that >> "packages" is the same resource as "packages.php" (it can do some magic, and >> I'm sure they do when they're doing page ranking). However, they will still >> list both as hits, try to seach for "site:opencsw.org CSWbash packages" on >> google and you'll see. > > Err.. that search phrase gives a very long ... aha. now I see. > > you are referring, presumably, to the #1, and #3 results. Not sure, the search result is most likely different for you and me, but yes, there where references to most combinations of the page. > However, this rather underlines my area of concern. > > They are referenced in quite different ways. "packages/CSWbash", vs > "packages.php/bash". > Which hints that google "found" the pages in different ways. Which > hints that somewhere (probably on OUR site), there is something > incorrectly referencing "packages.php/bash" instead of > "packages/bash". > > I think we should fix those out-of-date reference styles, before > making anything canonical. Fixing references is always nice, but adding stuff (be it Apache config or PHP code) to either make sure that the ".php" variant is never used is also required. Now that the links exist, a permanent redirect would be the correct solution. > ALSO: the two results, were from DIFFERENT TIMES. They are actually > "different" pages! If in contrast, the output was the same, google > would probably have coalesced them into one, I would bet. I doubt that they will as the number of candidate pages is quite big if they first where to go down that path. The fact that they list both is to me a sign of that they store both. How would they determine the canonical one anyway? > Hence I still stand by my statement that intelligent search engines > already handle this sort of thing "properly". > It is more appropriate for us fix our internal links, rather than tell > search engines, "ignore our mangled links" ! I think that in this case fixing the references is the right solution. -- Trygve From phil at bolthole.com Tue Sep 1 01:17:52 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 31 Aug 2009 16:17:52 -0700 Subject: [csw-maintainers] robots.txt In-Reply-To: <4A9C577B.80509@opencsw.org> References: <4A9C3D84.5080609@opencsw.org> <4A9C577B.80509@opencsw.org> Message-ID: 2009/8/31 Trygve Laugst?l : > Philip Brown wrote: >The fact that they list both is to me a > sign of that they store both. How would they determine the canonical one > anyway? I would say that the common-sense answer is, if "page", and "page.anything" exists (and the content is the same), then "page" should always be canonical. after all, if "site.com/docs" exists, and "site.com/docs.php" exists... odds are that "site.com/docs" will ALWAYS exist.. but someday, they may change the backend to be .pl, or .cgi, or whoknowswhat. > >> Hence I still stand by my statement that intelligent search engines >> already handle this sort of thing "properly". >> It is more appropriate for us fix our internal links, rather than tell >> search engines, "ignore our mangled links" ! > > I think that in this case fixing the references is the right solution. I'm glad we agree there. The annoying thing is that I'm not sure where the references are, at this point. From my searching through the pages, I dont see any obvious references to ".php" in our site. So assistance from other folks in hunting those down, would be appreciated. From trygvis at opencsw.org Tue Sep 1 01:47:59 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 01 Sep 2009 01:47:59 +0200 Subject: [csw-maintainers] robots.txt In-Reply-To: References: <4A9C3D84.5080609@opencsw.org> <4A9C577B.80509@opencsw.org> Message-ID: <4A9C612F.2090103@opencsw.org> Philip Brown wrote: > 2009/8/31 Trygve Laugst?l : >> Philip Brown wrote: >> The fact that they list both is to me a >> sign of that they store both. How would they determine the canonical one >> anyway? > > I would say that the common-sense answer is, if "page", and > "page.anything" exists (and the content is the same), then "page" > should always be canonical. > > after all, if "site.com/docs" exists, and "site.com/docs.php" > exists... odds are that "site.com/docs" will ALWAYS exist.. but > someday, they may change the backend to be .pl, or .cgi, or > whoknowswhat. > > > > >>> Hence I still stand by my statement that intelligent search engines >>> already handle this sort of thing "properly". >>> It is more appropriate for us fix our internal links, rather than tell >>> search engines, "ignore our mangled links" ! >> I think that in this case fixing the references is the right solution. > > > I'm glad we agree there. The annoying thing is that I'm not sure where > the references are, at this point. From my searching through the > pages, I dont see any obvious references to ".php" in our site. So > assistance from other folks in hunting those down, would be > appreciated. It very well might be old links that has gotten index at some point in time, and since we still return 200 OK on those URLs, Google will keep on re-indexing them. Try adding a permanent redirect from "page.php" to "page" and they will disappear after a while. Another option might be to grep the logs for ".php" and check the referer field if that is logged. Might give you a clue as well. This is where the Webmaster toolkit comes in handy, it can show you how Google view your side (not that I've used it myself, but that's what I've been told). -- Trygve From phil at bolthole.com Tue Sep 1 02:37:38 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 31 Aug 2009 17:37:38 -0700 Subject: [csw-maintainers] robots.txt In-Reply-To: <4A9C612F.2090103@opencsw.org> References: <4A9C3D84.5080609@opencsw.org> <4A9C577B.80509@opencsw.org> <4A9C612F.2090103@opencsw.org> Message-ID: 2009/8/31 Trygve Laugst?l : > > It very well might be old links that has gotten index at some point in time, > and since we still return 200 OK on those URLs, Google will keep on > re-indexing them. Try adding a permanent redirect from "page.php" to "page" > and they will disappear after a while. Seeing as how the .php page is the "real" page, that might be a little challenging. Or perhaps, since we currently have apache "fancy[somethingorother]" to auto-dereference "page", to "page.php" on the back end... there might be an apache setting to automatically redirect "page.php" to "page"? We should only do that for certain subtrees, though. not mantis ones. ugh. From jeff at cjsa.com Tue Sep 1 09:19:53 2009 From: jeff at cjsa.com (Jeffery Small) Date: Tue, 1 Sep 2009 07:19:53 GMT Subject: [csw-maintainers] sendmail and dbus packages Message-ID: Can someone please provide an update on the status of the following two open issues: 1: Is there a revised release of sendmail pending for use with the Berkeley DB 4.x problem, and have all the Berkeley DB issues been resolved? I am in a state of confusion about all this and very afraid to touch anything for fear of getting things out of sync once again. I really don't know what version of the BDB I should be running. I currently have: berkeleydb4 4.2.52,REV=2005.04.28_rev=p4 berkeleydb44 4.4.20,REV=2009.07.28 sendmail 8.14.2,REV=2007.12.17 2: Is anyone still working on the dbus package problem that is keeping Solaris SPARC from being able to disable the service and also making it impossible to cleanly shutdown the system, since we never get to the boot PROM, apparently because this service will not stop. One additional question regarding CSW sendmail. In the /opt/csw/var/spool directory, there are the following two links: ..clientmqueue -> /var/spool/clientmqueue ..mqueue -> /var/spool/mqueue These links are not listed on the webpage for sendmail as part of the package. Do these links exist on other people's systems, and if so, what is their purpose? Thanks. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From bonivart at opencsw.org Tue Sep 1 11:59:23 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 1 Sep 2009 11:59:23 +0200 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: Message-ID: <625385e30909010259r7053c7e0h611d392f28817b96@mail.gmail.com> On Tue, Sep 1, 2009 at 9:19 AM, Jeffery Small wrote: > Can someone please provide an update on the status of the following two > open issues: > > 1: ?Is there a revised release of sendmail pending for use with the Berkeley > ? ?DB 4.x problem, and have all the Berkeley DB issues been resolved? ?I > ? ?am in a state of confusion about all this and very afraid to touch anything > ? ?for fear of getting things out of sync once again. ?I really don't know > ? ?what version of the BDB I should be running. I currently have: > > ? ? ? ?berkeleydb4 ? ? ? ? ? 4.2.52,REV=2005.04.28_rev=p4 > ? ? ? ?berkeleydb44 ? ? ? ? ? ? ? ? 4.4.20,REV=2009.07.28 > ? ? ? ?sendmail ? ? ? ? ? ? ? ? ? ? 8.14.2,REV=2007.12.17 I know there's a lot of work going on to update the Sendmail package. As of now there's nothing to test though. I have several Sendmail servers and I'm holding off all updates until this is resolved. -- /peter From maciej at opencsw.org Tue Sep 1 12:11:15 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 1 Sep 2009 11:11:15 +0100 Subject: [csw-maintainers] robots.txt In-Reply-To: References: <4A9C3D84.5080609@opencsw.org> <4A9C577B.80509@opencsw.org> <4A9C612F.2090103@opencsw.org> Message-ID: On Tue, Sep 1, 2009 at 1:37 AM, Philip Brown wrote: > 2009/8/31 Trygve Laugst?l : >> >> It very well might be old links that has gotten index at some point in time, >> and since we still return 200 OK on those URLs, Google will keep on >> re-indexing them. Try adding a permanent redirect from "page.php" to "page" >> and they will disappear after a while. > > Seeing as how the .php page is the "real" page, that might be a little > challenging. > > Or perhaps, since we currently have apache "fancy[somethingorother]" > to auto-dereference "page", to "page.php" on the back end... there > might be an apache setting to automatically redirect "page.php" to > "page"? > > We should only do that for certain subtrees, though. not mantis ones. > ugh. mod_rewrite[1] could help. There could br a rule along the lines of: RewriteRule ^/packages.php(.*) /packages$1 [R=301] We'd need to test it, of course. [1] http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html#RewriteRule From maciej at opencsw.org Tue Sep 1 16:42:24 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 1 Sep 2009 15:42:24 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: <4A939902.3050808@opencsw.org> References: <4A939902.3050808@opencsw.org> Message-ID: 2009/8/25 Trygve Laugst?l : > Philip Brown wrote: >> >> I think with this sort of thing, you have to consider the likelyhood of >> breakage. >> >> If the nature of the application/configuration is relatively >> straightforward, and/or compatibility between the two versions is very >> strong, then I think the best thing to do is an automated migration. >> >> If on the other hand, breakage is very likely, then probably "halt and >> prompt" is best. >> >> An intermediate possibility, might be if the app has very good >> configuration file verification. >> >> Then you could do the automigration, VERIFY it, and then halt noisily if >> it fails verification. >> >> A post thought: in this case, I think you should always only copy; never >> remove. Worse case, 'mv' old config to config.migrated or something. > > These points sounds like a good policy to me and are similar to what I've > talked about earlier. I wrote up a comparison, for the sake of brevity, formatted as a table. It considers the simplest case, a single file which was previously on /opt/csw/etc and is going to be in /etc/opt/csw. http://wiki.opencsw.org/configuration-directory-migration In a simple case, which option people think is best? Maciej From dam at opencsw.org Tue Sep 1 16:57:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Sep 2009 16:57:49 +0200 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: Hi Maciej, Am 01.09.2009 um 16:42 schrieb Maciej (Matchek) Blizinski: > I wrote up a comparison, for the sake of brevity, formatted as a > table. It considers the simplest case, a single file which was > previously on /opt/csw/etc and is going to be in /etc/opt/csw. > > http://wiki.opencsw.org/configuration-directory-migration > > In a simple case, which option people think is best? Good comparison. In case (4) this means the file is first moved from /opt/csw/etc/foo.conf to /etc/opt/csw/foo.conf and then symlinked? So it is more like (2)+(4). Sounds for me as the best thing to do. The symlink shouldn't be in the package but generated during postinstall with errors ignored because if /etc/opt/csw is lofs'ed to /opt/csw/etc the symlink would point to itself and generation would fail as would the complete package install. Best regards -- Dago From maciej at opencsw.org Tue Sep 1 17:22:23 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 1 Sep 2009 16:22:23 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: On Tue, Sep 1, 2009 at 3:57 PM, Dagobert Michelsen wrote: > Good comparison. In case (4) this means the file is first moved > from /opt/csw/etc/foo.conf to /etc/opt/csw/foo.conf and then symlinked? > So it is more like (2)+(4). I was thinking about doing only the symlinking, so if you opened /etc/opt/csw/foo.conf, you'd get data from /opt/csw/etc/foo.conf. The actual command would be: ln -s ../../../opt/csw/etc/foo.conf ${PKG_INSTALL_ROOT}/etc/opt/csw/foo.conf > Sounds for me as the best thing to do. The symlink shouldn't be > in the package but generated during postinstall with errors ignored > because if /etc/opt/csw is lofs'ed to /opt/csw/etc the symlink would > point to itself and generation would fail as would the complete package > install. I see. Good point. Maciej From dam at opencsw.org Tue Sep 1 17:32:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Sep 2009 17:32:18 +0200 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) Message-ID: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> Hi, there is a parallel gzip in testing/ from Mark Adler: pkg-get -s http://mirror.opencsw.org/opencsw/testing -U -u pigz pkgutil -t http://mirror.opencsw.org/opencsw/testing -i pigz Some tests: > build8st% ls -l x > -rw-r--r-- 1 dam csw 336455680 Sep 1 17:05 x File is roughly 336 MB is size > build8st% time pigz x > pigz x 215.55s user 1.91s system 3065% cpu 7.094 total Compression takes 7 seconds instead 3 1/2 minutes on T5220! > build8st% time unpigz x.gz > unpigz x.gz 10.36s user 1.79s system 143% cpu 8.446 total Parallel gunzip is only 1,5 times faster > build8st% time pigz -9 x > pigz -9 x 396.91s user 1.96s system 2334% cpu 17.087 total Higher compressions take 17 seconds instead of 6 1/2 minutes!! > build8st% cksum x.gz > 585068046 123219628 x.gz Write that down. > build8st% time unpigz x.gz > unpigz x.gz 10.34s user 1.79s system 144% cpu 8.413 total > build8st% time gzip -9 x > gzip -9 x 241.84s user 1.56s system 99% cpu 4:03.40 total Traditional gzip takes less total CPU but 4 minutes total. > build8st% cksum x.gz > 206071496 123179310 x.gz Different checksum, but both archives are valid. I guess I'll switch package compression in GAR to pigz after release. Best regards -- Dago PS: ...and don't forget: it is pronounced "pig-zee" From maciej at opencsw.org Tue Sep 1 18:15:03 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 1 Sep 2009 17:15:03 +0100 Subject: [csw-maintainers] Rebuild package with an updated postinstall script Message-ID: When I update a postinstall script in files/CSWfoo.postinstall and do "gmake repackage", the GAR keeps using the old script in the package. I tried also "reinstall" and "remerge". Do you know if I can get GAR to include the updated postinstall script without recompiling the whole package? Maciej From dam at opencsw.org Tue Sep 1 18:31:53 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Sep 2009 18:31:53 +0200 Subject: [csw-maintainers] Rebuild package with an updated postinstall script In-Reply-To: References: Message-ID: <0CA83913-39A0-4792-B79C-69D5D1A5C47B@opencsw.org> Hi Maciej, Am 01.09.2009 um 18:15 schrieb Maciej (Matchek) Blizinski: > When I update a postinstall script in files/CSWfoo.postinstall and do > "gmake repackage", the GAR keeps using the old script in the package. > I tried also "reinstall" and "remerge". Do you know if I can get GAR > to include the updated postinstall script without recompiling the > whole package? Not easily, not easily. This is because the files are transferred from files/ to donwload/ to $(WORKSRC) during extract phase at the very beginning. GAR can not know what needs to be redone after anything has changed there. For testing purposes you can copy the files from download/ over to work/build-*/, but to be sure the result is reproducable the final package should be build from scratch. This all is a safety measure. It is guaranteed that there is no difference between 'gmake package' and the result after 'gmake repackage' and this guarantee can not be given when you tinker with files from the first phase. Best regards -- Dago From maciej at opencsw.org Wed Sep 2 10:58:11 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 2 Sep 2009 09:58:11 +0100 Subject: [csw-maintainers] unixODBC-2.2.14 in testing In-Reply-To: References: Message-ID: On Wed, Jul 29, 2009 at 11:24 PM, Maciej (Matchek) Blizinski wrote: > The unixODBC package, version 2.2.14 is now in testing. > > http://mirror.opencsw.org/testing/unixodbc-2.2.14,REV=2009.07.29-SunOS5.8-sparc-CSW.pkg.gz > http://mirror.opencsw.org/testing/unixodbc-2.2.14,REV=2009.07.29-SunOS5.8-i386-CSW.pkg.gz > > It's the first version built with GAR, a remake from scratch. I > haven't got access to the original package. This package doesn't > include GUI (QT) support. It keeps the configuration files in > /etc/opt/csw, as opposed to the earlier /opt/csw/etc. Please feel free > to respond with any feedback on the package. I've updated the unixodbc packages. http://mirror.opencsw.org/testing/unixodbc-2.2.14,REV=2009.09.02-SunOS5.8-i386-CSW.pkg.gz http://mirror.opencsw.org/testing/unixodbc-2.2.14,REV=2009.09.02-SunOS5.8-sparc-CSW.pkg.gz The changes include: - 64-bit binaries for sparcv9 and amd64 ISAs - A postinstall script which aids the migration of /opt/csw/etc/odbc*ini files to /etc/opt/csw. The installation should pass non-interactively and unixodbc should preserve its configuration, including the non-global zones. Hint files are placed in the /opt/csw/etc directory. Maciej From maciej at opencsw.org Wed Sep 2 13:25:55 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 2 Sep 2009 12:25:55 +0100 Subject: [csw-maintainers] unixODBC-2.2.14 in testing In-Reply-To: References: Message-ID: On Wed, Sep 2, 2009 at 9:58 AM, Maciej (Matchek) Blizinski wrote: > The changes include: > > - 64-bit binaries for sparcv9 and amd64 ISAs > - A postinstall script which aids the migration of > /opt/csw/etc/odbc*ini files to /etc/opt/csw. The installation should > pass non-interactively and unixodbc should preserve its configuration, > including the non-global zones. Hint files are placed in the > /opt/csw/etc directory. After a request from one of the maintainers, I moved the unixodbc packages to a subdirectory. The new location is: http://mirror.opencsw.org/testing/etc-migration/unixodbc-2.2.14,REV=2009.09.02-SunOS5.8-i386-CSW.pkg.gz http://mirror.opencsw.org/testing/etc-migration/unixodbc-2.2.14,REV=2009.09.02-SunOS5.8-sparc-CSW.pkg.gz Maciej From skayser at opencsw.org Wed Sep 2 13:54:23 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 02 Sep 2009 13:54:23 +0200 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: Message-ID: <4A9E5CEF.6050001@opencsw.org> Jeffery Small wrote on 01.09.2009 09:19: > Can someone please provide an update on the status of the following two > open issues: > > 1: [...] have all the Berkeley DB issues been resolved? I > am in a state of confusion about all this and very afraid to touch anything > for fear of getting things out of sync once again. +1 Same state of uncertainty here. > 2: Is anyone still working on the dbus package problem that is keeping > Solaris SPARC from being able to disable the service and also making it > impossible to cleanly shutdown the system, since we never get to the boot > PROM, apparently because this service will not stop. There should be a fixed dbus package in testing. I didn't get to test it anymore after the initial feedback. I guess William is just waiting for some feedback. http://thread.gmane.org/gmane.os.solaris.opencsw.maintainers/3409 Sebastian From dam at opencsw.org Wed Sep 2 13:39:42 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Sep 2009 13:39:42 +0200 Subject: [csw-maintainers] [csw-users] Firefox 3 release In-Reply-To: <4A9D0946.7060104@wbonnet.net> References: <4A9C47D6.4010501@wbonnet.net> <4A9D084C.1040005@ericsson.com> <4A9D0946.7060104@wbonnet.net> Message-ID: Hi William, Am 01.09.2009 um 13:45 schrieb William Bonnet: > Firefox 3.5.1 is compiling on our build farm, but it is not running > yet. We have several dependencies to update before we can release > it. Work have started on updating this libs, but it will take some > time and a lot of testing... What libs do you need to have updated for this? Best regards -- Dago From phil at bolthole.com Wed Sep 2 18:56:35 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 2 Sep 2009 09:56:35 -0700 Subject: [csw-maintainers] robots.txt In-Reply-To: References: <4A9C3D84.5080609@opencsw.org> <4A9C577B.80509@opencsw.org> <4A9C612F.2090103@opencsw.org> Message-ID: On Tue, Sep 1, 2009 at 3:11 AM, Maciej (Matchek) Blizinski wrote: > > > mod_rewrite[1] could help. There could br a rule along the lines of: > > RewriteRule ^/packages.php(.*) /packages$1 [R=301] > > We'd need to test it, of course. > > [1] http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html#RewriteRule > Not bad. I wouldnt object to Ihsan putting that in there. Although I think we should probably agree that this is a temporary cleanup,and to remove it after some fixed period of time. (6 months?) No need to throw away server resources unneccessarily, once it has served its purpose. From phil at bolthole.com Wed Sep 2 19:00:06 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 2 Sep 2009 10:00:06 -0700 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: Message-ID: On Tue, Sep 1, 2009 at 12:19 AM, Jeffery Small wrote: > Can someone please provide an update on the status of the following two > open issues: > > 1: Is there a revised release of sendmail pending for use with the Berkeley > DB 4.x problem, and have all the Berkeley DB issues been resolved? I > am in a state of confusion about all this and very afraid to touch anything > for fear of getting things out of sync once again. I really don't know > what version of the BDB I should be running. I currently have: > > berkeleydb4 4.2.52,REV=2005.04.28_rev=p4 > berkeleydb44 4.4.20,REV=2009.07.28 > sendmail 8.14.2,REV=2007.12.17 > > I previously suggested/requested that our berkeleydb maintainer(s), repackage the "berkeleyedb4" package, to include the old binaries for the shared libs, until they are no longer used. This basically echos our "normal" policies about shared libs. http://www.opencsw.org/standards/libraries " ... it is usually neccessary to include older versions of a library, in your package. So, if you are releasing libfoo.so.1.3, it is appropriate to copy in the older libfoo.so.1.2 into your package. .... until their maintainers have time to recompile." From ihsan at opencsw.org Wed Sep 2 19:15:31 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 02 Sep 2009 19:15:31 +0200 Subject: [csw-maintainers] [board] maintainer registration? In-Reply-To: <4A9CEAEE.6030708@pocock.com.au> References: <4A927A7D.70600@pocock.com.au> <4A92C8A9.1060307@pocock.com.au> <4A92EEF9.7070804@pocock.com.au> <7D46DB25-88E5-407C-A5B5-B28549D99D23@opencsw.org> <4A96ABAF.70109@pocock.com.au> <052AF7DA-8E8C-41E7-B013-93BB6352BE23@opencsw.org> <4A96EA68.8020000@pocock.com.au> <4A9A8EB4.6080602@opencsw.org> <4A9CEAEE.6030708@pocock.com.au> Message-ID: <4A9EA833.3020908@opencsw.org> Am 1.9.2009 11:35 Uhr, Daniel Pocock schrieb: >>> I haven't got an opencsw.org account as far as I know - I've tried to >>> subscribe to that list using my main email address, daniel at pocock.com.au >>> - I think it is waiting for someone to approve, because I haven't >>> received the confirmation email yet >> >> I can't approve that request because according to our policy, only >> e-mail addresses with an @opencsw.org address can be on the list. >> > Could you kindly clarify the reason for this policy? It's easier to administrate. > Adding an extra email address in my various email clients, and > remembering to change the sender address on each email I send, may only > make participating in opencsw more tedious than it should be. As far you are using Thunderbird, you could install the "Folder Account" extensions. With this extension you can define your sender address per folder. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From daniel at pocock.com.au Tue Sep 1 11:36:20 2009 From: daniel at pocock.com.au (Daniel Pocock) Date: Tue, 01 Sep 2009 10:36:20 +0100 Subject: [csw-maintainers] [board] maintainer registration? In-Reply-To: <4A9A8EB4.6080602@opencsw.org> References: <4A927A7D.70600@pocock.com.au> <4A92C8A9.1060307@pocock.com.au> <4A92EEF9.7070804@pocock.com.au> <7D46DB25-88E5-407C-A5B5-B28549D99D23@opencsw.org> <4A96ABAF.70109@pocock.com.au> <052AF7DA-8E8C-41E7-B013-93BB6352BE23@opencsw.org> <4A96EA68.8020000@pocock.com.au> <4A9A8EB4.6080602@opencsw.org> Message-ID: <4A9CEB14.2@pocock.com.au> Ihsan Dogan wrote: > Am 27.8.2009 22:19 Uhr, Daniel Pocock schrieb: > > >>>> Could you let me know whether this type of thing should be discussed >>>> on the board list, the maintainers list or the devel list? >>>> >>> Usually on maintainers@, but you have to post from your opencsw.org >>> account >>> on the list which you may or may not (Ihsan?) have yet. >>> >>> >> I haven't got an opencsw.org account as far as I know - I've tried to >> subscribe to that list using my main email address, daniel at pocock.com.au >> - I think it is waiting for someone to approve, because I haven't >> received the confirmation email yet >> > > I can't approve that request because according to our policy, only > e-mail addresses with an @opencsw.org address can be on the list. > > Could you kindly clarify the reason for this policy? Wouldn't it be sufficient to just tell the list software to only accept email from subscribers? Adding an extra email address in my various email clients, and remembering to change the sender address on each email I send, may only make participating in opencsw more tedious than it should be. From mats.larsson at ericsson.com Tue Sep 1 13:41:00 2009 From: mats.larsson at ericsson.com (Mats Larsson) Date: Tue, 01 Sep 2009 13:41:00 +0200 Subject: [csw-maintainers] [csw-users] Firefox 3 release In-Reply-To: <4A9C47D6.4010501@wbonnet.net> References: <4A9C47D6.4010501@wbonnet.net> Message-ID: <4A9D084C.1040005@ericsson.com> Hi Will, Good work indeed. Any chance for a Fx 3.5.x soon? BR MOL On 2009-08-31 23:59, William Bonnet wrote: > Hi, > > I'm pleased to announced that Firefox 3.0.13 has been pushed to > current. This version supports Solaris 8 and newer (thanks goes to > James Lee for pointing me the solution). > > Thunderbird has also been updated to version 2.0.0.23, latest stable > before TB3 is released. > > cheers > W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihsan at opencsw.org Wed Sep 2 20:02:47 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 02 Sep 2009 20:02:47 +0200 Subject: [csw-maintainers] Summary for OpenCSW summer camp? In-Reply-To: References: Message-ID: <4A9EB347.4020602@opencsw.org> Am 26.8.2009 15:58 Uhr, Peter FELECAN schrieb: > Now, that we had photos about this event, is it possible to have a > summary of what happened, discussed, &c for those that hadn't the > opportunity to be there? This is my task. I'm already working on it to put it on the wiki. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Wed Sep 2 20:10:02 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 02 Sep 2009 20:10:02 +0200 Subject: [csw-maintainers] FYI: Hosting provider for Solaris In-Reply-To: References: <141B8FA6-FB56-41B4-8FDF-5E5A0A58DE77@familie-michelsen.de> Message-ID: <4A9EB4FA.1060302@opencsw.org> Am 26.8.2009 22:36 Uhr, Dagobert Michelsen schrieb: > the domain hoster I use for opencsw.org is now offering OpenSolaris vServer > starting at 40 Euro per month with 2 TB traffic included. I haven't heard > of another hoster offering Solaris, so you may find this interesting. We (Uplink AG, the company where I work) provide Solaris hosting as well, but at the moment only Solaris and not OpenSolaris. --> http://www.netofficeservices.net/ (currently only in German) Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From daniel at opencsw.org Wed Sep 2 20:32:42 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 02 Sep 2009 19:32:42 +0100 Subject: [csw-maintainers] FYI: Hosting provider for Solaris In-Reply-To: <4A9EB4FA.1060302@opencsw.org> References: <141B8FA6-FB56-41B4-8FDF-5E5A0A58DE77@familie-michelsen.de> <4A9EB4FA.1060302@opencsw.org> Message-ID: <4A9EBA4A.6030109@opencsw.org> Ihsan Dogan wrote: > Am 26.8.2009 22:36 Uhr, Dagobert Michelsen schrieb: > > >> the domain hoster I use for opencsw.org is now offering OpenSolaris vServer >> starting at 40 Euro per month with 2 TB traffic included. I haven't heard >> of another hoster offering Solaris, so you may find this interesting. >> > > We (Uplink AG, the company where I work) provide Solaris hosting as > well, but at the moment only Solaris and not OpenSolaris. > > --> http://www.netofficeservices.net/ > > (currently only in German) > > Many providers offer physical server hosting (using your hardware or their own) - you can then install Xen on top of the supplied Linux distro, and run any virtual machine you like, including Solaris or OpenSolaris My own personal setup has Solaris 10 x86 inside a Debian lenny box. I use iSCSI to export raw LVM volumes to Solaris, this provides a convenient and standardised way to manage the disk space across multiple VMs. From daniel at pocock.com.au Wed Sep 2 20:30:21 2009 From: daniel at pocock.com.au (Daniel Pocock) Date: Wed, 02 Sep 2009 19:30:21 +0100 Subject: [csw-maintainers] FYI: Hosting provider for Solaris In-Reply-To: <4A9EB4FA.1060302@opencsw.org> References: <141B8FA6-FB56-41B4-8FDF-5E5A0A58DE77@familie-michelsen.de> <4A9EB4FA.1060302@opencsw.org> Message-ID: <4A9EB9BD.5010809@pocock.com.au> Ihsan Dogan wrote: > Am 26.8.2009 22:36 Uhr, Dagobert Michelsen schrieb: > > >> the domain hoster I use for opencsw.org is now offering OpenSolaris vServer >> starting at 40 Euro per month with 2 TB traffic included. I haven't heard >> of another hoster offering Solaris, so you may find this interesting. >> > > We (Uplink AG, the company where I work) provide Solaris hosting as > well, but at the moment only Solaris and not OpenSolaris. > > --> http://www.netofficeservices.net/ > > Many providers offer physical server hosting (using your hardware or their own) - you can then install Xen on top of the supplied Linux distro, and run any virtual machine you like, including Solaris or OpenSolaris My own personal setup has Solaris 10 x86 inside a Debian lenny box. I use iSCSI to export raw LVM volumes to Solaris, this provides a convenient and standardised way to manage the disk space across multiple VMs. From dam at opencsw.org Wed Sep 2 21:16:14 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Sep 2009 21:16:14 +0200 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: Message-ID: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> Hi, Am 02.09.2009 um 19:00 schrieb Philip Brown: > On Tue, Sep 1, 2009 at 12:19 AM, Jeffery Small wrote: >> Can someone please provide an update on the status of the following >> two >> open issues: >> >> 1: Is there a revised release of sendmail pending for use with the >> Berkeley >> DB 4.x problem, and have all the Berkeley DB issues been >> resolved? I >> am in a state of confusion about all this and very afraid to >> touch anything >> for fear of getting things out of sync once again. I really >> don't know >> what version of the BDB I should be running. I currently have: >> >> berkeleydb4 4.2.52,REV=2005.04.28_rev=p4 >> berkeleydb44 4.4.20,REV=2009.07.28 >> sendmail 8.14.2,REV=2007.12.17 >> >> > > I previously suggested/requested that our berkeleydb maintainer(s), > repackage the "berkeleyedb4" package, to include the old binaries for > the shared libs, until they are no longer used. > This basically echos our "normal" policies about shared libs. This policy is there to avoid having multiple packages with one version each. Currently we already have multiple packages and correct dependencies to each package version. There is no need to put all in one package. Essentially, you say "go back to the old scheme and let's see that we update all builds to old versions". I fully agree to going back with correct versions inside, but not as one package and links from other packages. It is more difficult to package and maintain and additionally bloats the system with all versions when you only need one. Best regards -- Dago From ihsan at opencsw.org Wed Sep 2 22:05:48 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 02 Sep 2009 22:05:48 +0200 Subject: [csw-maintainers] FYI: Hosting provider for Solaris In-Reply-To: <4A9EBA4A.6030109@opencsw.org> References: <141B8FA6-FB56-41B4-8FDF-5E5A0A58DE77@familie-michelsen.de> <4A9EB4FA.1060302@opencsw.org> <4A9EBA4A.6030109@opencsw.org> Message-ID: <4A9ED01C.8010707@opencsw.org> Am 2.9.2009 20:32 Uhr, Daniel Pocock schrieb: >> We (Uplink AG, the company where I work) provide Solaris hosting as >> well, but at the moment only Solaris and not OpenSolaris. >> >> --> http://www.netofficeservices.net/ >> >> (currently only in German) >> >> > Many providers offer physical server hosting (using your hardware or > their own) - you can then install Xen on top of the supplied Linux > distro, and run any virtual machine you like, including Solaris or > OpenSolaris > > My own personal setup has Solaris 10 x86 inside a Debian lenny box. I > use iSCSI to export raw LVM volumes to Solaris, this provides a > convenient and standardised way to manage the disk space across multiple > VMs. We address actually more the professional market. Xen and iSCSI are, well, not really for production. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From phil at bolthole.com Wed Sep 2 23:16:23 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 2 Sep 2009 14:16:23 -0700 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> References: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> Message-ID: On Wed, Sep 2, 2009 at 12:16 PM, Dagobert Michelsen wrote: > Am 02.09.2009 um 19:00 schrieb Philip Brown: >> I previously suggested/requested that our berkeleydb maintainer(s), >> repackage the "berkeleyedb4" package, to include the old binaries for >> the shared libs, until they are no longer used. >> This basically echos our "normal" policies about shared libs. > > This[standard?] policy is there to avoid having multiple packages with > one version each. Currently we already have multiple packages > and correct dependencies to each package version. There is no > need to put all in one package. Essentially, you say "go back > to the old scheme and let's see that we update all builds > to old versions". That "old scheme" is a bit ambigous. Lets be a bit more explicit, and say "go back to CSW STANDARD scheme". And lets continue to be explicit and spell out the future path for berkeleydb: Once applications have been recompiled to no longer use berkeleydb4X versions of the shared libs, that versioned virtual package should be completely removed from our repository. older berkeleydb4X packages should be in transition to non-existance, once their dependants are gone. agree? From skayser at opencsw.org Thu Sep 3 00:22:09 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 03 Sep 2009 00:22:09 +0200 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> Message-ID: <4A9EF011.8050500@opencsw.org> Philip Brown wrote on 02.09.2009 23:16: > On Wed, Sep 2, 2009 at 12:16 PM, Dagobert Michelsen wrote: >> Am 02.09.2009 um 19:00 schrieb Philip Brown: >>> I previously suggested/requested that our berkeleydb maintainer(s), >>> repackage the "berkeleyedb4" package, to include the old binaries for >>> the shared libs, until they are no longer used. >>> This basically echos our "normal" policies about shared libs. >> This[standard?] policy is there to avoid having multiple packages with >> one version each. Currently we already have multiple packages >> and correct dependencies to each package version. There is no >> need to put all in one package. Essentially, you say "go back >> to the old scheme and let's see that we update all builds >> to old versions". > > That "old scheme" is a bit ambigous. Lets be a bit more explicit, and > say "go back to CSW STANDARD scheme". > > And lets continue to be explicit and spell out the future path for berkeleydb: > > Once applications have been recompiled to no longer use berkeleydb4X > versions of the shared libs, that versioned virtual package should be > completely removed from our repository. > > older berkeleydb4X packages should be in transition to non-existance, > once their dependants are gone. I didn't jump in on the discussion where Dago initially requested feedback for the bdb packaging change [1], but as the bdb stuff caused some hickups some wider discussion might help. Just to understand the status quo: - We do have a CSWbdb package which currently holds 4.7.x, lives in /opt/csw/lib (/opt/csw/lib/libdb.so to be precise), and which might get upgraded to 4.7+ sometime in the future? - Previous CSWbdb packages (like CSWbdb44) lived within their own /opt/csw/lib/bdb4X/ prefix and have been replaced by stub packages containting symlinks to /opt/csw/lib/libdb.so to preserve functionality of existing packages? - Packages linked against previous CSWbdb packages should be changed to link against /opt/csw/lib/libdb.so (or to a symlink named libdb-4.7.so which is also installed by CSWbdb)? Now that we have a "moving version" libdb.so file (plus already existing packages linked against previous versions), the one question that comes to my mind is ABI compatibility? Dago mentioned BDB should be ABI backward-compatible, but i couldn't find any page actually saying so. The only thing i found sounds a bit like the opposite [2]: "Berkeley DB major and minor releases may optionally include changes in all four areas, that is, the application API, region files, database formats, and log files may not be backward-compatible with previous releases." I know API != ABI, but API changes can break ABI compatibility and i couldn't come up with a reference that guarantees ABI compatibility. Sebastian [1]http://lists.opencsw.org/pipermail/maintainers/2009-May/002726.html [2]http://www.oracle.com/technology/documentation/berkeley-db/db/ref/upgrade/process.html From daniel at opencsw.org Thu Sep 3 00:43:57 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 02 Sep 2009 23:43:57 +0100 Subject: [csw-maintainers] FYI: Hosting provider for Solaris In-Reply-To: <4A9ED01C.8010707@opencsw.org> References: <141B8FA6-FB56-41B4-8FDF-5E5A0A58DE77@familie-michelsen.de> <4A9EB4FA.1060302@opencsw.org> <4A9EBA4A.6030109@opencsw.org> <4A9ED01C.8010707@opencsw.org> Message-ID: <4A9EF52D.70900@opencsw.org> Ihsan Dogan wrote: > Am 2.9.2009 20:32 Uhr, Daniel Pocock schrieb: > > >>> We (Uplink AG, the company where I work) provide Solaris hosting as >>> well, but at the moment only Solaris and not OpenSolaris. >>> >>> --> http://www.netofficeservices.net/ >>> >>> (currently only in German) >>> >>> >>> >> Many providers offer physical server hosting (using your hardware or >> their own) - you can then install Xen on top of the supplied Linux >> distro, and run any virtual machine you like, including Solaris or >> OpenSolaris >> >> My own personal setup has Solaris 10 x86 inside a Debian lenny box. I >> use iSCSI to export raw LVM volumes to Solaris, this provides a >> convenient and standardised way to manage the disk space across multiple >> VMs. >> > > We address actually more the professional market. Xen and iSCSI are, > well, not really for production. > > I'm certainly not advocating any solution as better than any other. Xen and iSCSI are certainly sufficient for me to do Ganglia and OpenCSW development/packaging, but that is obviously not the same as production ecommerce systems. The production environment I work in is completely different, both in scale and choice of technology. From dam at opencsw.org Thu Sep 3 09:32:54 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Sep 2009 09:32:54 +0200 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> Message-ID: <1F0E2987-F72A-46A9-B84B-82A4B3AF2DBB@opencsw.org> Hi Phil, Am 02.09.2009 um 23:16 schrieb Philip Brown: > On Wed, Sep 2, 2009 at 12:16 PM, Dagobert Michelsen > wrote: >> Am 02.09.2009 um 19:00 schrieb Philip Brown: >>> I previously suggested/requested that our berkeleydb maintainer(s), >>> repackage the "berkeleyedb4" package, to include the old binaries >>> for >>> the shared libs, until they are no longer used. >>> This basically echos our "normal" policies about shared libs. >> >> This[standard?] policy is there to avoid having multiple packages >> with >> one version each. Currently we already have multiple packages >> and correct dependencies to each package version. There is no >> need to put all in one package. Essentially, you say "go back >> to the old scheme and let's see that we update all builds >> to old versions". > > That "old scheme" is a bit ambigous. Lets be a bit more explicit, and > say "go back to CSW STANDARD scheme". > > And lets continue to be explicit and spell out the future path for > berkeleydb: > > Once applications have been recompiled to no longer use berkeleydb4X > versions of the shared libs, that versioned virtual package should be > completely removed from our repository. > > older berkeleydb4X packages should be in transition to non-existance, > once their dependants are gone. Yes. I propose to put the old shared libs back in to bdb4x until the dependencies are gone and then remove them. There is really no point in moving the shared libs in bdb4 and make bdb4x stubs. The CSW standard doesn't apply here as we already have multiple version packages. Apart from that I am not keen into putting a whole day of work reorganizing the libs where we already have build descriptions for all bdb4x packages. Not because of the work, but because there no gain in clearance and bloat in size. Mike, your opinion? Best regards -- Dago From daniel at opencsw.org Thu Sep 3 12:08:41 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 03 Sep 2009 11:08:41 +0100 Subject: [csw-maintainers] linking against rrdtool fails Message-ID: <4A9F95A9.9060700@opencsw.org> This is a relatively fresh install of OpenCSW, so I'm guessing that the CSWrrd package hasn't dragged in all it's dependencies: configure:19101: checking for rrd_create in -lrrd configure:19131: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 -xarch=386 - I/opt/csw/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib conftest.c -lrrd -lm -lpthread >&5 Undefined first referenced symbol in file cairo_svg_surface_restrict_to_version /opt/csw/lib/librrd.so cairo_svg_surface_create /opt/csw/lib/librrd.so cairo_svg_surface_create_for_stream /opt/csw/lib/librrd.so ld: fatal: Symbol referencing errors. No output written to conftest From dam at opencsw.org Thu Sep 3 12:13:48 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Sep 2009 12:13:48 +0200 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <4A9F95A9.9060700@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> Message-ID: Hi Daniel, Am 03.09.2009 um 12:08 schrieb Daniel Pocock: > This is a relatively fresh install of OpenCSW, so I'm guessing that > the CSWrrd package hasn't dragged in all it's dependencies: > > configure:19101: checking for rrd_create in -lrrd > configure:19131: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 - > xarch=386 - > I/opt/csw/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib > conftest.c -lrrd > -lm -lpthread >&5 > Undefined first referenced > symbol in file > cairo_svg_surface_restrict_to_version /opt/csw/lib/librrd.so > cairo_svg_surface_create /opt/csw/lib/librrd.so > cairo_svg_surface_create_for_stream /opt/csw/lib/librrd.so > ld: fatal: Symbol referencing errors. No output written to conftest There were issues with circular dependencies which have been fixed recently with SVG support. Please try if libcairo from testing solves you problem. This would also help John who did the repackage to release it. Best regards -- Dago From daniel at opencsw.org Thu Sep 3 12:36:18 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 03 Sep 2009 11:36:18 +0100 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: References: <4A9F95A9.9060700@opencsw.org> Message-ID: <4A9F9C22.1080101@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 03.09.2009 um 12:08 schrieb Daniel Pocock: >> This is a relatively fresh install of OpenCSW, so I'm guessing that >> the CSWrrd package hasn't dragged in all it's dependencies: >> >> configure:19101: checking for rrd_create in -lrrd >> configure:19131: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 >> -xarch=386 - >> I/opt/csw/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib >> conftest.c -lrrd >> -lm -lpthread >&5 >> Undefined first referenced >> symbol in file >> cairo_svg_surface_restrict_to_version /opt/csw/lib/librrd.so >> cairo_svg_surface_create /opt/csw/lib/librrd.so >> cairo_svg_surface_create_for_stream /opt/csw/lib/librrd.so >> ld: fatal: Symbol referencing errors. No output written to conftest > > There were issues with circular dependencies which have been fixed > recently with SVG support. Please try if libcairo from testing > solves you problem. This would also help John who did the > repackage to release it. > How do I get it from testing? When I look at the mirrors, I just see stable, current and unstable From dam at opencsw.org Thu Sep 3 12:38:58 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Sep 2009 12:38:58 +0200 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <4A9F9C22.1080101@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> Message-ID: <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> Hi Daniel, Am 03.09.2009 um 12:36 schrieb Daniel Pocock: > Dagobert Michelsen wrote: >> Hi Daniel, >> >> Am 03.09.2009 um 12:08 schrieb Daniel Pocock: >>> This is a relatively fresh install of OpenCSW, so I'm guessing >>> that the CSWrrd package hasn't dragged in all it's dependencies: >>> >>> configure:19101: checking for rrd_create in -lrrd >>> configure:19131: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest - >>> xO3 -xarch=386 - >>> I/opt/csw/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib >>> conftest.c -lrrd >>> -lm -lpthread >&5 >>> Undefined first referenced >>> symbol in file >>> cairo_svg_surface_restrict_to_version /opt/csw/lib/librrd.so >>> cairo_svg_surface_create /opt/csw/lib/librrd.so >>> cairo_svg_surface_create_for_stream /opt/csw/lib/librrd.so >>> ld: fatal: Symbol referencing errors. No output written to conftest >> >> There were issues with circular dependencies which have been fixed >> recently with SVG support. Please try if libcairo from testing >> solves you problem. This would also help John who did the >> repackage to release it. >> > How do I get it from testing? When I look at the mirrors, I just > see stable, current and unstable Ah, ok, from here: Commandlines for pkg-get and pkgutil are also described there. It is btw also available from the farm as /home/testing/ Best regards -- Dago From daniel at opencsw.org Thu Sep 3 12:46:07 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 03 Sep 2009 11:46:07 +0100 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> Message-ID: <4A9F9E6F.2030002@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 03.09.2009 um 12:36 schrieb Daniel Pocock: > >> Dagobert Michelsen wrote: >>> Hi Daniel, >>> >>> Am 03.09.2009 um 12:08 schrieb Daniel Pocock: >>>> This is a relatively fresh install of OpenCSW, so I'm guessing that >>>> the CSWrrd package hasn't dragged in all it's dependencies: >>>> >>>> configure:19101: checking for rrd_create in -lrrd >>>> configure:19131: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 >>>> -xarch=386 - >>>> I/opt/csw/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib >>>> conftest.c -lrrd >>>> -lm -lpthread >&5 >>>> Undefined first referenced >>>> symbol in file >>>> cairo_svg_surface_restrict_to_version /opt/csw/lib/librrd.so >>>> cairo_svg_surface_create /opt/csw/lib/librrd.so >>>> cairo_svg_surface_create_for_stream /opt/csw/lib/librrd.so >>>> ld: fatal: Symbol referencing errors. No output written to conftest >>> >>> There were issues with circular dependencies which have been fixed >>> recently with SVG support. Please try if libcairo from testing >>> solves you problem. This would also help John who did the >>> repackage to release it. >>> >> How do I get it from testing? When I look at the mirrors, I just see >> stable, current and unstable > > Ah, ok, from here: > > Commandlines for pkg-get and pkgutil are also described there. > It is btw also available from the farm as /home/testing/ > Thanks, I had been looking at http://www.opencsw.org/mirrors which mentions testing but doesn't link to that other page. From daniel at opencsw.org Thu Sep 3 12:56:31 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 03 Sep 2009 11:56:31 +0100 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <4A9F9E6F.2030002@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> <4A9F9E6F.2030002@opencsw.org> Message-ID: <4A9FA0DF.4040903@opencsw.org> Daniel Pocock wrote: > Dagobert Michelsen wrote: >> Hi Daniel, >> >> Am 03.09.2009 um 12:36 schrieb Daniel Pocock: >> >>> Dagobert Michelsen wrote: >>>> Hi Daniel, >>>> >>>> Am 03.09.2009 um 12:08 schrieb Daniel Pocock: >>>>> This is a relatively fresh install of OpenCSW, so I'm guessing >>>>> that the CSWrrd package hasn't dragged in all it's dependencies: >>>>> >>>>> configure:19101: checking for rrd_create in -lrrd >>>>> configure:19131: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest >>>>> -xO3 -xarch=386 - >>>>> I/opt/csw/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib >>>>> conftest.c -lrrd >>>>> -lm -lpthread >&5 >>>>> Undefined first referenced >>>>> symbol in file >>>>> cairo_svg_surface_restrict_to_version /opt/csw/lib/librrd.so >>>>> cairo_svg_surface_create /opt/csw/lib/librrd.so >>>>> cairo_svg_surface_create_for_stream /opt/csw/lib/librrd.so >>>>> ld: fatal: Symbol referencing errors. No output written to conftest >>>> >>>> There were issues with circular dependencies which have been fixed >>>> recently with SVG support. Please try if libcairo from testing >>>> solves you problem. This would also help John who did the >>>> repackage to release it. >>>> >>> How do I get it from testing? When I look at the mirrors, I just >>> see stable, current and unstable >> >> Ah, ok, from here: >> >> Commandlines for pkg-get and pkgutil are also described there. >> It is btw also available from the farm as /home/testing/ >> > > Thanks, I had been looking at http://www.opencsw.org/mirrors which > mentions testing but doesn't link to that other page. I did pkgutil -t ... -i CSWrrd and now things like ggrep are broken. It says libiconv is not found, but I can see it in the right place. Do other issues exist in testing? Do I need to update all my packages from testing now? -bash-3.00# ldd /opt/csw/bin/ggrep libintl.so.8 => /opt/csw/lib/pentium_pro/libintl.so.8 libpcre.so.0 => /opt/csw/lib/i386/libpcre.so.0 libc.so.1 => /lib/libc.so.1 libiconv.so.2 => (file not found) libncurses.so.5 => /opt/csw/lib/pentium_pro/libncurses.so.5 libm.so.2 => /lib/libm.so.2 -bash-3.00# ls -l | grep iconv lrwxrwxrwx 1 root root 17 Sep 3 11:46 libiconv.so -> libiconv.so.2.5.0 lrwxrwxrwx 1 root root 17 Sep 3 11:46 libiconv.so.2 -> libiconv.so.2.5.0 -rwxr-xr-x 1 root bin 961948 Jul 31 10:18 libiconv.so.2.5.0 -rw-r--r-- 1 root bin 960320 Jul 31 10:18 preloadable_libiconv.so From dam at opencsw.org Thu Sep 3 13:54:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Sep 2009 13:54:43 +0200 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <4A9FA0DF.4040903@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> <4A9F9E6F.2030002@opencsw.org> <4A9FA0DF.4040903@opencsw.org> Message-ID: <0E96A327-0F1D-48F9-80DA-6D33707496DF@opencsw.org> Hi Daniel, Am 03.09.2009 um 12:56 schrieb Daniel Pocock: > Daniel Pocock wrote: >> Dagobert Michelsen wrote: >>> Hi Daniel, >>> >>> Am 03.09.2009 um 12:36 schrieb Daniel Pocock: >>> >>>> Dagobert Michelsen wrote: >>>>> There were issues with circular dependencies which have been fixed >>>>> recently with SVG support. Please try if libcairo from testing >>>>> solves you problem. This would also help John who did the >>>>> repackage to release it. >> >>>> >>>> How do I get it from testing? When I look at the mirrors, I just >>>> see stable, current and unstable >>> >>> Ah, ok, from here: >>> >>> Commandlines for pkg-get and pkgutil are also described there. >>> It is btw also available from the farm as /home/testing/ >> >> Thanks, I had been looking at http://www.opencsw.org/mirrors which >> mentions testing but doesn't link to that other page. > > I did > pkgutil -t ... -i CSWrrd Please update _only_ cairo, not rrd or anything else as stuff in testing may or may not be broken and you want to test cairo only. > and now things like ggrep are broken. It says libiconv is not > found, but I can see it in the right place. > > Do other issues exist in testing? Do I need to update all my > packages from testing now? Definitely not. Please revert all versions from CSW packages to current except cairo or you will get massive problems. testing/ is not meant to be fully installed as there are no checks done between packages from testing/. Best regards -- Dago From daniel at opencsw.org Thu Sep 3 17:01:57 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 03 Sep 2009 16:01:57 +0100 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <0E96A327-0F1D-48F9-80DA-6D33707496DF@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> <4A9F9E6F.2030002@opencsw.org> <4A9FA0DF.4040903@opencsw.org> <0E96A327-0F1D-48F9-80DA-6D33707496DF@opencsw.org> Message-ID: <4A9FDA65.5000003@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 03.09.2009 um 12:56 schrieb Daniel Pocock: >> Daniel Pocock wrote: >>> Dagobert Michelsen wrote: >>>> Hi Daniel, >>>> >>>> Am 03.09.2009 um 12:36 schrieb Daniel Pocock: >>>> >>>>> Dagobert Michelsen wrote: >>>>>> There were issues with circular dependencies which have been fixed >>>>>> recently with SVG support. Please try if libcairo from testing >>>>>> solves you problem. This would also help John who did the >>>>>> repackage to release it. >>> >>>>> >>>>> How do I get it from testing? When I look at the mirrors, I just >>>>> see stable, current and unstable >>>> >>>> Ah, ok, from here: >>>> >>>> Commandlines for pkg-get and pkgutil are also described there. >>>> It is btw also available from the farm as /home/testing/ >>> >>> Thanks, I had been looking at http://www.opencsw.org/mirrors which >>> mentions testing but doesn't link to that other page. >> >> I did >> pkgutil -t ... -i CSWrrd > > Please update _only_ cairo, not rrd or anything else as stuff in > testing may or may not > be broken and you want to test cairo only. > >> and now things like ggrep are broken. It says libiconv is not found, >> but I can see it in the right place. >> >> Do other issues exist in testing? Do I need to update all my >> packages from testing now? > > Definitely not. Please revert all versions from CSW packages to > current except > cairo or you will get massive problems. testing/ is not meant to be > fully installed > as there are no checks done between packages from testing/. > When I try to get cairo with pkgutil, it wants to grab other packages too, including iconv: -bash-3.00# pkgutil -t http://mirror.opencsw.org/opencsw/testing -i CSWlibcairo Fetching new catalog http://mirror.opencsw.org/opencsw/testing/i386/5.10 if available... --2009-09-03 15:59:32-- http://mirror.opencsw.org/opencsw/testing/i386/5.10/catalog Resolving mirror.opencsw.org... 213.178.77.176 Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 31807 (31K) [text/plain] Saving to: `/var/opt/csw/pkgutil/catalog.mirror.opencsw.org_opencsw_testing_i386_5.10' 100%[======================================>] 31,807 85.4K/s in 0.4s 2009-09-03 15:59:37 (85.4 KB/s) - `/var/opt/csw/pkgutil/catalog.mirror.opencsw.org_opencsw_testing_i386_5.10' saved [31807/31807] Fetching new catalog http://ftp.heanet.ie/pub/opencsw/current/i386/5.10 if available... --2009-09-03 15:59:37-- http://ftp.heanet.ie/pub/opencsw/current/i386/5.10/catalog Resolving ftp.heanet.ie... 193.1.193.64, 2001:770:18:aa40::c101:c140 Connecting to ftp.heanet.ie|193.1.193.64|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 398585 (389K) [text/plain] Saving to: `/var/opt/csw/pkgutil/catalog.ftp.heanet.ie_pub_opencsw_current_i386_5.10' 100%[======================================>] 398,585 72.1K/s in 5.2s 2009-09-03 15:59:42 (74.5 KB/s) - `/var/opt/csw/pkgutil/catalog.ftp.heanet.ie_pub_opencsw_current_i386_5.10' saved [398585/398585] Parsing catalog, may take a while... Updated packages: CSWzlib-1.2.3,REV=2009.04.05 CSWiconv-1.13.1,REV=2009.07.31 CSWftype2-2.3.9,REV=2009.04.16 CSWlibcairo-1.8.8,REV=2009.08.04 Current packages: CSWcommon-1.4.6,REV=2008.04.28 CSWx11common-1.0,REV=2009.05.24 CSWlibxau-1.0.4,REV=2009.06.04 CSWlibxcb-1.3,REV=2009.06.07 CSWlibx11-1.2.2,REV=2009.07.12 CSWexpat-2.0.1,REV=2009.01.22 CSWisaexec-0.2,REV=2009.03.26 CSWxcbutil-0.3.5,REV=2009.06.12 CSWpng-1.2.39,REV=2009.08.13 CSWpixman-0.15.8,REV=2009.06.02 CSWlibxrender-0.9.4,REV=2009.06.11 CSWfconfig-2.6.0,REV=2009.04.24 Total size: 3.9 MB 4 packages to fetch. Do you want to continue? [Y,n] From bonivart at opencsw.org Thu Sep 3 17:46:42 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 3 Sep 2009 17:46:42 +0200 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <4A9FDA65.5000003@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> <4A9F9E6F.2030002@opencsw.org> <4A9FA0DF.4040903@opencsw.org> <0E96A327-0F1D-48F9-80DA-6D33707496DF@opencsw.org> <4A9FDA65.5000003@opencsw.org> Message-ID: <625385e30909030846u3978ebd5q56153fcfa1d638a7@mail.gmail.com> On Thu, Sep 3, 2009 at 5:01 PM, Daniel Pocock wrote: > When I try to get cairo with pkgutil, it wants to grab other packages too, > including iconv: > > -bash-3.00# pkgutil -t http://mirror.opencsw.org/opencsw/testing -i > CSWlibcairo > > Parsing catalog, may take a while... > Updated packages: CSWzlib-1.2.3,REV=2009.04.05 > CSWiconv-1.13.1,REV=2009.07.31 CSWftype2-2.3.9,REV=2009.04.16 > CSWlibcairo-1.8.8,REV=2009.08.04 Use the -x option to exclude packages: # pkgutil -t http://mirror.opencsw.org/opencsw/testing -i CSWlibcairo -x CSWzlib -x CSWiconv -x CSWftype2 -- /peter From phil at bolthole.com Thu Sep 3 18:25:53 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 3 Sep 2009 09:25:53 -0700 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <625385e30909030846u3978ebd5q56153fcfa1d638a7@mail.gmail.com> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> <4A9F9E6F.2030002@opencsw.org> <4A9FA0DF.4040903@opencsw.org> <0E96A327-0F1D-48F9-80DA-6D33707496DF@opencsw.org> <4A9FDA65.5000003@opencsw.org> <625385e30909030846u3978ebd5q56153fcfa1d638a7@mail.gmail.com> Message-ID: On Thu, Sep 3, 2009 at 8:46 AM, Peter Bonivart wrote: > >Use the -x option to exclude packages: > # pkgutil -t http://mirror.opencsw.org/opencsw/testing -i CSWlibcairo > -x CSWzlib -x CSWiconv -x CSWftype2 > or perhaps just download it, and pkgadd it. For example pkg-get -s http://mirror.opencsw.org/opencsw/testing -d libcairo and then gunzip and pkgadd the result. if you dont want to just go to the webpage and click on it with your mouse to download :) From phil at bolthole.com Thu Sep 3 18:33:15 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 3 Sep 2009 09:33:15 -0700 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: <1F0E2987-F72A-46A9-B84B-82A4B3AF2DBB@opencsw.org> References: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> <1F0E2987-F72A-46A9-B84B-82A4B3AF2DBB@opencsw.org> Message-ID: On Thu, Sep 3, 2009 at 12:32 AM, Dagobert Michelsen wrote: > > I propose to put the old shared libs back in to bdb4x until the > dependencies are gone and then remove them. There is really no point > in moving the shared libs in bdb4 and make bdb4x stubs. The CSW standard > doesn't apply here as we already have multiple version packages. Well, there is ONE reason to do it "the standard way": new packages, tend to follow the pattern of older packages. If we dont do it "the right way" now, then 6-12 months down the road when it's time for someone (who may not be you or mike) to do an update, they might just follow along in the same scheme. that would be bad. From phil at bolthole.com Thu Sep 3 18:36:34 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 3 Sep 2009 09:36:34 -0700 Subject: [csw-maintainers] berkeleydb saga Message-ID: On Wed, Sep 2, 2009 at 3:22 PM, Sebastian Kayser wrote: > ..... > Now that we have a "moving version" libdb.so file (plus already existing > packages linked against previous versions), the one question that comes > to my mind is ABI compatibility? > I know API != ABI, but API changes can break ABI compatibility and i > couldn't come up with a reference that guarantees ABI compatibility. > The symlink isnt important. What is important, is the "SONAME" of the library. if it is compiled with SONAME=libdb-4.7, then even if you compile with cc .... -ldb at runtime, it will be dynamically linked aginst "libdb-4.7". So no worries there. the symlink is just a shortcut for "at COMPILE time, use latest version". When ABI compatibility changes, we bump the SONAME. From dam at opencsw.org Thu Sep 3 18:49:57 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Sep 2009 18:49:57 +0200 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> <1F0E2987-F72A-46A9-B84B-82A4B3AF2DBB@opencsw.org> Message-ID: Hi Phil, Am 03.09.2009 um 18:33 schrieb Philip Brown: > On Thu, Sep 3, 2009 at 12:32 AM, Dagobert Michelsen > wrote: >>> I propose to put the old shared libs back in to bdb4x until the >> dependencies are gone and then remove them. There is really no point >> in moving the shared libs in bdb4 and make bdb4x stubs. The CSW >> standard >> doesn't apply here as we already have multiple version packages. > > Well, there is ONE reason to do it "the standard way": > new packages, tend to follow the pattern of older packages. > If we dont do it "the right way" now, then 6-12 months down the road > when it's time for someone (who may not be you or mike) to do an > update, they might just follow along in the same scheme. > that would be bad. The bdb4x packages will most certainly never get an update. The only package to be updated would be bdb4, which already contains 4.7.x, so no worries there. Best regards -- Dago From daniel at opencsw.org Thu Sep 3 18:54:04 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 03 Sep 2009 17:54:04 +0100 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> <4A9F9E6F.2030002@opencsw.org> <4A9FA0DF.4040903@opencsw.org> <0E96A327-0F1D-48F9-80DA-6D33707496DF@opencsw.org> <4A9FDA65.5000003@opencsw.org> <625385e30909030846u3978ebd5q56153fcfa1d638a7@mail.gmail.com> Message-ID: <4A9FF4AC.4070402@opencsw.org> Philip Brown wrote: > On Thu, Sep 3, 2009 at 8:46 AM, Peter Bonivart wrote: > >> Use the -x option to exclude packages: >> # pkgutil -t http://mirror.opencsw.org/opencsw/testing -i CSWlibcairo >> -x CSWzlib -x CSWiconv -x CSWftype2 >> >> > > > or perhaps just download it, and pkgadd it. For example > > pkg-get -s http://mirror.opencsw.org/opencsw/testing -d libcairo > and then gunzip and pkgadd the result. > if you dont want to just go to the webpage and click on it with your > mouse to download :) > Yes, after looking at the pkgutil output, I decided to just download the package and use pkgadd, it didn't complain. The main reason I posted those other comments in that the testing page suggests using pkgutil, but that obviously led to a broken system for me. When I finally got the new libcairo, Ganglia gmetad server built quite happily. I'm now fine-tuning the Makefile for the full Ganglia suite, it will probably be available tomorrow. From phil at bolthole.com Thu Sep 3 19:13:18 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 3 Sep 2009 10:13:18 -0700 Subject: [csw-maintainers] berkeleydb saga Message-ID: On Thu, Sep 3, 2009 at 9:49 AM, Dagobert Michelsen wrote: > Hi Phil, > > Am 03.09.2009 um 18:33 schrieb Philip Brown: >> >> Well, there is ONE reason to do it "the standard way": >> new packages, tend to follow the pattern of older packages. >... > > The bdb4x packages will most certainly never get an update. The > only package to be updated would be bdb4, which already contains > 4.7.x, so no worries there. > my point being, that someone updating bdb4, in the distant future, may see the old, versioned packages, and think, "oh ok, I'd better follow the existing 'standard' for berkeleydb, and make a separate, new, berkeleydb4.8 package" From dam at opencsw.org Thu Sep 3 19:18:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Sep 2009 19:18:31 +0200 Subject: [csw-maintainers] berkeleydb saga In-Reply-To: References: Message-ID: <1E772177-3CCB-4855-9620-3517F5DCE57D@opencsw.org> Hi Phil, Am 03.09.2009 um 19:13 schrieb Philip Brown: > On Thu, Sep 3, 2009 at 9:49 AM, Dagobert Michelsen > wrote: >> Hi Phil, >> >> Am 03.09.2009 um 18:33 schrieb Philip Brown: >>> >>> Well, there is ONE reason to do it "the standard way": >>> new packages, tend to follow the pattern of older packages. >> ... >> >> The bdb4x packages will most certainly never get an update. The >> only package to be updated would be bdb4, which already contains >> 4.7.x, so no worries there. >> > > my point being, that someone updating bdb4, in the distant future, may > see the old, versioned packages, and think, "oh ok, I'd better follow > the existing 'standard' for berkeleydb, and make a separate, new, > berkeleydb4.8 package" Let me put it that way: At least *I* will never forget this, and I'm sure Mike and you won't either. And if in the distant future somebody takes over bdb and all of us are no longer project members I don't care. It is just too much work to build a unified bdb4 only for "the sake of consistency" and taking the negative side effects that every package depending on bdb would pull in all versions as they would be contained in bdb4, right? It would not make things clearer. Best regards -- Dago From william at wbonnet.net Thu Sep 3 23:01:27 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 03 Sep 2009 23:01:27 +0200 Subject: [csw-maintainers] Important ! DBus update and bug fix Message-ID: <4AA02EA7.9010406@wbonnet.net> Hi, A new version of the dbus packages will be pushed to current catalog in the next hours. This version fixes the fllowing bug 0003626: dbus daemon will not stop on reboot/init 6 blocking the shutdown ( http://opencsw.org/bugtrack/view.php?id=3626 ). This bugs prevents dbus from stop correctly. If dbus is running, it will be stop during update, thus update may freeze. In order to avoid this situation, you have to be sure that you don't have dbus running, or if it is running, you will have to kill it by hand before the upgrade. You can retrieve the pid to kill with the following command : bash-3.00# cat /opt/csw/var/run/dbus/pid 1592 or bash-3.00# ps -elf | grep dbus-daemon 0 S messageb 1592 1 0 40 20 ? 634 ? 22:55:25 ? 0:00 /opt/csw/bin/dbus-daemon --system Please "kill -9" the dbus process before running package upgrade. Kind regards W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From dam at opencsw.org Fri Sep 4 10:09:37 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Sep 2009 10:09:37 +0200 Subject: [csw-maintainers] Handling of bug reports Message-ID: Hi Rupert, (cc'ing maintainers@ to enhance consistent handling of bugreports) first thanks a lot for updating the Trac package. However, I received some status changes for bugs which were handled a bit uncustomary :-) It looks like you added your fix to the "Additional Information" field, which is quite confusing as it is meant to be used be the bug reporter. For the sake of consistency it would be nice if you could do the following steps: 1. Assign the bug to yourself 2. Change the status to Feedback/Acknowledged/Confirmed 3. Fix the bug and release a package to testing/ 4. If package is good set status to Resolved including the package version (e. g. "Fixed in 2.2.6,REV=2009.09.03_rev=a released to testing/") 5. Deliver the package to newpkgs/ 6. Set status to Closed when the package hit the mirrors As the updated package has already been released it would be great if you could review the bug reports and do (1) and (6) with the text of (4) in it. For general discussion: For the sake of simplicity I guess (4) could be ommitted. Step (2) is necessary to show someone is working on it, obivously you need (3) and a final close with (6) and the exact version for reference. Thanks and best regards -- Dago From maciej at opencsw.org Fri Sep 4 11:23:15 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 4 Sep 2009 10:23:15 +0100 Subject: [csw-maintainers] /opt/csw/bin/foo=bar=/opt/csw/bin/isaexec in the prototype Message-ID: I just got an error when installing wxwidgets: /opt/csw/lib/libwx_gtk2u_xrc-2.8.so.0 /opt/csw/lib/libwx_gtk2u_xrc-2.8.so.0.6.0 /opt/csw/lib/wx/config/gtk2-unicode-release-2.8 /opt/csw/lib/wx/include/gtk2-unicode-release-2.8/wx/setup.h [ verifying class ] /opt/csw/bin/wxrc ERROR: attribute verification of failed pathname does not exist unable to create link to /opt/csw/bin/wxrc-2.8 Installation of partially failed. ## Interrupted: package not installed in any non-global zones The relevant part of the install directory looks like this: work/install-isa-sparcv8/ `-- opt `-- csw |-- bin | |-- wx-config -> /opt/csw/lib/wx/config/gtk2-unicode-release-2.8 | |-- wxrc -> wxrc-2.8 | `-- wxrc-2.8 |-- include | `-- wx-2.8 | `-- wx | |-- aboutdlg.h ...and the prototype part is: s none /opt/csw/bin/sparcv8/wxrc=/opt/csw/bin/wxrc f none /opt/csw/bin/sparcv8/wxrc-2.8=/opt/csw/bin/wxrc-2.8 0755 root bin s none /opt/csw/bin/wx-config=/opt/csw/lib/wx/config/gtk2-unicode-release-2.8 l none /opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec l none /opt/csw/bin/wxrc-2.8=/opt/csw/bin/isaexec 0755 root bin It looks like there is a problem when there's a symlink which later becomes handled by isaexec. Initial "/opt/csw/bin/wxrc=wxrc-2.8" becomes "/opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec". Is this a valid prototype line? Maciej From james at opencsw.org Fri Sep 4 11:24:16 2009 From: james at opencsw.org (James Lee) Date: Fri, 04 Sep 2009 09:24:16 GMT Subject: [csw-maintainers] berkeleydb saga In-Reply-To: References: Message-ID: <20090904.9241600.918026838@gyor.oxdrove.co.uk> On 03/09/09, 17:36:34, Philip Brown wrote regarding Re: [csw-maintainers] berkeleydb saga: > The symlink isnt important. What is important, is the "SONAME" of the > library. > if it is compiled with SONAME=libdb-4.7, then even if you compile with > cc .... -ldb > at runtime, it will be dynamically linked aginst "libdb-4.7". Which is good, so when I install and use bdb4 generic version 4.X the libraries to which I link are 4.7. Therefore the package version for bdb4 should be 4.7 not 4.2. Currently the displayed package version is 4.2 which reflects the legacy libs also provided by this package as links to the 4.7 files. Being a bdb4 and not bdb42 it has rolling 4.x version unlike the bdb43 and bdbd44 which are fixed to 4.3 and 4.4 respectively. $ dump -Lv /opt/csw/bdb4/lib/libdb.so | grep SONAME [7] SONAME libdb-4.7.so $ pkgchk -l -p /opt/csw/bdb4/lib/libdb.so Pathname: /opt/csw/bdb4/lib/libdb.so Type: symbolic link Source of link: /opt/csw/lib/libdb.so Referenced by the following packages: CSWbdb4 Current status: installed $ pkgparam CSWbdb4 VERSION 4.2.52,REV=2009.07.28 James. From dam at opencsw.org Fri Sep 4 11:33:52 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Sep 2009 11:33:52 +0200 Subject: [csw-maintainers] /opt/csw/bin/foo=bar=/opt/csw/bin/isaexec in the prototype In-Reply-To: References: Message-ID: <8D0F5086-1849-476E-BED4-BC8BFC62AC46@opencsw.org> Hi Maciej, Am 04.09.2009 um 11:23 schrieb Maciej (Matchek) Blizinski: > I just got an error when installing wxwidgets: > > /opt/csw/lib/libwx_gtk2u_xrc-2.8.so.0 > /opt/csw/lib/libwx_gtk2u_xrc-2.8.so.0.6.0 > /opt/csw/lib/wx/config/gtk2-unicode-release-2.8 > /opt/csw/lib/wx/include/gtk2-unicode-release-2.8/wx/setup.h > [ verifying class ] > /opt/csw/bin/wxrc > ERROR: attribute verification of failed > pathname does not exist > unable to create link to > /opt/csw/bin/wxrc-2.8 > > Installation of partially failed. > ## Interrupted: package not installed in any non- > global zones > > > The relevant part of the install directory looks like this: > > work/install-isa-sparcv8/ > `-- opt > `-- csw > |-- bin > | |-- wx-config -> /opt/csw/lib/wx/config/gtk2-unicode- > release-2.8 > | |-- wxrc -> wxrc-2.8 > | `-- wxrc-2.8 > |-- include > | `-- wx-2.8 > | `-- wx > | |-- aboutdlg.h > You are using tree, nice! (whose package is orphaned and there is a new version, btw). > ...and the prototype part is: > > s none /opt/csw/bin/sparcv8/wxrc=/opt/csw/bin/wxrc > f none /opt/csw/bin/sparcv8/wxrc-2.8=/opt/csw/bin/wxrc-2.8 0755 root > bin > s none /opt/csw/bin/wx-config=/opt/csw/lib/wx/config/gtk2-unicode- > release-2.8 > l none /opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec > l none /opt/csw/bin/wxrc-2.8=/opt/csw/bin/isaexec 0755 root bin > > It looks like there is a problem when there's a symlink which later > becomes handled by isaexec. Initial "/opt/csw/bin/wxrc=wxrc-2.8" > becomes "/opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec". Is this a > valid prototype line? Umh, no, this looks broken. Obiously isaexec should not be applied to symlinks and I can add that to GAR. That would mean wxrc would still be a symlink to wxrc-2.8 which would then be isaexec'ed and relocated to subdirs. Does this sound right to you? Best regards -- Dago From james at opencsw.org Fri Sep 4 11:42:14 2009 From: james at opencsw.org (James Lee) Date: Fri, 04 Sep 2009 09:42:14 GMT Subject: [csw-maintainers] berkeleydb saga In-Reply-To: <1E772177-3CCB-4855-9620-3517F5DCE57D@opencsw.org> References: <1E772177-3CCB-4855-9620-3517F5DCE57D@opencsw.org> Message-ID: <20090904.9421400.1835663330@gyor.oxdrove.co.uk> On 03/09/09, 18:18:31, Dagobert Michelsen wrote regarding Re: [csw-maintainers] berkeleydb saga: > >>> Well, there is ONE reason to do it "the standard way": > >>> new packages, tend to follow the pattern of older packages. > >> ... > >> > >> The bdb4x packages will most certainly never get an update. The > >> only package to be updated would be bdb4, which already contains > >> 4.7.x, so no worries there. CSWbdb4 contains no files, only links to CSWbdb. > > my point being, that someone updating bdb4, in the distant future, may > > see the old, versioned packages, and think, "oh ok, I'd better follow > > the existing 'standard' for berkeleydb, and make a separate, new, > > berkeleydb4.8 package" > Let me put it that way: At least *I* will never forget this, > and I'm sure Mike and you won't either. And if in the distant > future somebody takes over bdb and all of us are no longer > project members I don't care. It is just too much work to > build a unified bdb4 only for "the sake of consistency" > and taking the negative side effects that every package > depending on bdb would pull in all versions as they would > be contained in bdb4, right? It would not make things > clearer. I'm confused as to why CSWbdb exists. It's not legacy because it's new. We are in the habit of suffixing the software name with the major version number. The CSWbdb4 should be the 4.X package and currently contain version 4.7 files plus links for the legacy 4.2 libs. We have no need of CSWbdb. James. From maciej at opencsw.org Fri Sep 4 12:04:35 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 4 Sep 2009 11:04:35 +0100 Subject: [csw-maintainers] /opt/csw/bin/foo=bar=/opt/csw/bin/isaexec in the prototype In-Reply-To: <8D0F5086-1849-476E-BED4-BC8BFC62AC46@opencsw.org> References: <8D0F5086-1849-476E-BED4-BC8BFC62AC46@opencsw.org> Message-ID: On Fri, Sep 4, 2009 at 10:33 AM, Dagobert Michelsen wrote: > You are using tree, nice! (whose package is orphaned and there is a new > version, btw). Is this a hint? :-) >> ...and the prototype part is: >> >> s none /opt/csw/bin/sparcv8/wxrc=/opt/csw/bin/wxrc >> f none /opt/csw/bin/sparcv8/wxrc-2.8=/opt/csw/bin/wxrc-2.8 0755 root bin >> s none >> /opt/csw/bin/wx-config=/opt/csw/lib/wx/config/gtk2-unicode-release-2.8 >> l none /opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec >> l none /opt/csw/bin/wxrc-2.8=/opt/csw/bin/isaexec 0755 root bin >> >> It looks like there is a problem when there's a symlink which later >> becomes handled by isaexec. Initial "/opt/csw/bin/wxrc=wxrc-2.8" >> becomes "/opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec". Is this a >> valid prototype line? > > Umh, no, this looks broken. Obiously isaexec should not be applied to > symlinks and I can add that to GAR. That would mean wxrc would still be a symlink to > wxrc-2.8 which would then be isaexec'ed and relocated to subdirs. Does this sound > right to you? Yes, this sounds right. Maciej From dam at opencsw.org Fri Sep 4 15:21:00 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Sep 2009 15:21:00 +0200 Subject: [csw-maintainers] Updated libtool available with GCC support Message-ID: <7609235B-544D-499A-8AD9-A7A7C1325C9E@opencsw.org> Hi folks, I just pushed an updated libtool in testing/ and installed it on test8s (alias for build8st) and test8x. The problem with the existing version is that it was not able to compile stuff with the GCC compilers. It was in there a long time ago when Robin Kay made the package and it took me a while to figure out how this worked. THIS IS COMPLETE MADNESS! Basically you have to compile libtool with every compiler you want support for, then cut out certain parts, put them away and add code in the main libtool to use the snippets when something unknown compiler is encountered. Anyway, it was a good opportunity to do a triple-modulation of ISA, version and compiler (I guess this is the only package this will ever need this). If you want to see how this works you can take a look at A test with freeradius and gcc3/gcc4 builds fine. There is currently no support for gcc2 as there is also no support for gcc2 in GAR. If somebody needs it I'll add it. So please give it a try if you have anything to compile with libtool and gcc. Best regards -- Dago From dam at opencsw.org Fri Sep 4 16:03:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Sep 2009 16:03:55 +0200 Subject: [csw-maintainers] /opt/csw/bin/foo=bar=/opt/csw/bin/isaexec in the prototype In-Reply-To: References: <8D0F5086-1849-476E-BED4-BC8BFC62AC46@opencsw.org> Message-ID: <8148FEFE-AF03-46A7-A14B-76F3EE77CAEB@opencsw.org> Hi Maciej, Am 04.09.2009 um 12:04 schrieb Maciej (Matchek) Blizinski: >>> ...and the prototype part is: >>> >>> s none /opt/csw/bin/sparcv8/wxrc=/opt/csw/bin/wxrc >>> f none /opt/csw/bin/sparcv8/wxrc-2.8=/opt/csw/bin/wxrc-2.8 0755 >>> root bin >>> s none >>> /opt/csw/bin/wx-config=/opt/csw/lib/wx/config/gtk2-unicode- >>> release-2.8 >>> l none /opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec >>> l none /opt/csw/bin/wxrc-2.8=/opt/csw/bin/isaexec 0755 root bin >>> >>> It looks like there is a problem when there's a symlink which later >>> becomes handled by isaexec. Initial "/opt/csw/bin/wxrc=wxrc-2.8" >>> becomes "/opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec". Is this a >>> valid prototype line? >> >> Umh, no, this looks broken. Obiously isaexec should not be applied to >> symlinks and I can add that to GAR. That would mean wxrc would >> still be a symlink to >> wxrc-2.8 which would then be isaexec'ed and relocated to subdirs. >> Does this sound >> right to you? > > Yes, this sounds right. Ok, fixed in r6176. And isaexec shouldn't have been used in the first place, this was broken since r6148 where I made some reorderings to make all local builds first (needed for pbuilds) which is fixed now in r6177. Best regards -- Dago From phil at bolthole.com Fri Sep 4 18:14:19 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Sep 2009 09:14:19 -0700 Subject: [csw-maintainers] berkeleydb saga In-Reply-To: <20090904.9421400.1835663330@gyor.oxdrove.co.uk> References: <1E772177-3CCB-4855-9620-3517F5DCE57D@opencsw.org> <20090904.9421400.1835663330@gyor.oxdrove.co.uk> Message-ID: On Fri, Sep 4, 2009 at 2:42 AM, James Lee wrote: > > CSWbdb4 contains no files, only links to CSWbdb. Hmmm. I'm thinking it would be better, the other way around. > The CSWbdb4 should be the 4.X package and > currently contain version 4.7 files plus links for the legacy 4.2 > libs. We have no need of CSWbdb. > well, I dont have a strong feeling about the existance of "CSWbdb". but I do agree that the "berkeley db 4.x latest binaries" belong in the package CSWbdb4. From phil at bolthole.com Fri Sep 4 18:17:18 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Sep 2009 09:17:18 -0700 Subject: [csw-maintainers] berkeleydb saga In-Reply-To: <20090904.9241600.918026838@gyor.oxdrove.co.uk> References: <20090904.9241600.918026838@gyor.oxdrove.co.uk> Message-ID: On Fri, Sep 4, 2009 at 2:24 AM, James Lee wrote: > .... so when I install and use bdb4 generic version 4.X the > libraries to which I link are 4.7. Therefore the package version for > bdb4 should be 4.7 not 4.2. >..... > $ pkgparam CSWbdb4 VERSION > 4.2.52,REV=2009.07.28 > good point. there was some mass chaos for a while, when the bdb pkg maintainers were trying to release bugfixes quick. this probably got lost in the confusion there. Hopefully, they will catch up and rectify this soon. From phil at bolthole.com Fri Sep 4 18:54:40 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Sep 2009 09:54:40 -0700 Subject: [csw-maintainers] robots.txt In-Reply-To: References: <4A9C3D84.5080609@opencsw.org> <4A9C577B.80509@opencsw.org> <4A9C612F.2090103@opencsw.org> Message-ID: On Wed, Sep 2, 2009 at 9:56 AM, Philip Brown wrote: > On Tue, Sep 1, 2009 at 3:11 AM, Maciej (Matchek) > Blizinski wrote: >> >> >> mod_rewrite[1] could help. There could br a rule along the lines of: >> >> RewriteRule ^/packages.php(.*) /packages$1 [R=301] >> > > Not bad. I wouldnt object to Ihsan putting that in there. FYI: this is now unneccessary. I have recoded packages.php, to do Location: header redirects. From daniel at opencsw.org Fri Sep 4 22:33:56 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 04 Sep 2009 21:33:56 +0100 Subject: [csw-maintainers] Ganglia update Message-ID: <4AA179B4.3010001@opencsw.org> Hi Dagobert, Thanks for your earlier feedback. The packages are now working, except for init scripts and SMF support. That will come shortly. However, people are welcome to test, just install the packages, and start the processes like so: On every node running the agent: /opt/csw/sbin/gmond -c /opt/csw/etc/ganglia/gmond.conf On the reporting server, run both the agent and the server: /opt/csw/sbin/gmond -c /opt/csw/etc/ganglia/gmond.conf /opt/csw/sbin/gmetad -c /opt/csw/etc/ganglia/gmetad.conf Then just browse to http:///ganglia/ and enjoy watching the graphs. Please let me know if there is anything else horribly wrong in my Makefile Regards, Daniel From dam at opencsw.org Fri Sep 4 22:43:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Sep 2009 22:43:13 +0200 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA179B4.3010001@opencsw.org> References: <4AA179B4.3010001@opencsw.org> Message-ID: Hi Daniel, Am 04.09.2009 um 22:33 schrieb Daniel Pocock: > The packages are now working, except for init scripts and SMF > support. That will come shortly. However, people are welcome to > test, just install the packages, and start the processes like so: > > On every node running the agent: > /opt/csw/sbin/gmond -c /opt/csw/etc/ganglia/gmond.conf > > On the reporting server, run both the agent and the server: > > /opt/csw/sbin/gmond -c /opt/csw/etc/ganglia/gmond.conf > /opt/csw/sbin/gmetad -c /opt/csw/etc/ganglia/gmetad.conf > > Then just browse to http:///ganglia/ and enjoy > watching the graphs. > > Please let me know if there is anything else horribly wrong in my > Makefile Looks mighty good, however there are some minor issues: - ETCGANGLIA should be /etc/opt/csw/ganglia - For httpd-ganglia.conf you should use PRESERVECONF or SAMPLECONF from CSWcswclassutils described here: Best regards -- Dago From yann at pleiades.fr.eu.org Fri Sep 4 22:54:25 2009 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 04 Sep 2009 22:54:25 +0200 Subject: [csw-maintainers] Another problem with Berkeleydb (with cyrus_imapd) Message-ID: <4AA17E81.1010109@pleiades.fr.eu.org> Hi, I run into the same problem with berkeleydb and cyrus imapd: imaps[4196]: [ID 539395 local6.crit] incorrect version of Berkeley db: compiled against 4.2.52, linked against 4.7.25 I saw a lot of thread about berkeleydb, but it's not easy to find what is current situation and what will be done to solve this problem. Can someone explain to me: - if it is planned to provide again the berkeleydb 4.2.52 package or if I have to recompile cyrus against berkeleydb 4.7 ? - if it is 100% guaranted that the upgrade to 4.7 is transparent for the user and that berkeleydb files created with 4.2 will be handled with 4.7 ? I would rather like the berkeleydb 4.2 package to be restored in its previous state so it doesn't break current cyrus installation and to give me some time to test the upgrade path to 4.7. Yann From dam at opencsw.org Fri Sep 4 23:01:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Sep 2009 23:01:26 +0200 Subject: [csw-maintainers] Another problem with Berkeleydb (with cyrus_imapd) In-Reply-To: <4AA17E81.1010109@pleiades.fr.eu.org> References: <4AA17E81.1010109@pleiades.fr.eu.org> Message-ID: <8D063F4A-0B90-4E07-9EFD-D9AE27D10530@opencsw.org> Hi Yann, Am 04.09.2009 um 22:54 schrieb Yann Rouillard: > I run into the same problem with berkeleydb and cyrus imapd: > > imaps[4196]: [ID 539395 local6.crit] incorrect version of Berkeley > db: compiled against 4.2.52, linked against 4.7.25 > > I saw a lot of thread about berkeleydb, but it's not easy to find > what is current situation and what will be done to solve this problem. > > Can someone explain to me: > > - if it is planned to provide again the berkeleydb 4.2.52 package > or if I have to recompile cyrus against berkeleydb 4.7 ? Phil, Mike: Please correct me if I'm wrong. We will put 4.2.52 back in as legacy lib in bdb4. If you could update your package to 4.7 that would be great as we generally want to reducy dependency to old libs. > - if it is 100% guaranted that the upgrade to 4.7 is transparent > for the user and that berkeleydb files created with 4.2 will be > handled with 4.7 ? We thought so. However, I am not 100% sure any more. > I would rather like the berkeleydb 4.2 package to be restored in its > previous state so it doesn't break current cyrus installation and to > give me some time to test the upgrade path to 4.7. Ok, agreed. So again: everybody please be extra careful on upgrades from current as the berkeley db issues have not been fully cleaned. It will unfortunately take some more time to reorganize things again. Best regards -- Dago From phil at bolthole.com Fri Sep 4 23:35:59 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Sep 2009 14:35:59 -0700 Subject: [csw-maintainers] Another problem with Berkeleydb (with cyrus_imapd) In-Reply-To: <8D063F4A-0B90-4E07-9EFD-D9AE27D10530@opencsw.org> References: <4AA17E81.1010109@pleiades.fr.eu.org> <8D063F4A-0B90-4E07-9EFD-D9AE27D10530@opencsw.org> Message-ID: On Fri, Sep 4, 2009 at 2:01 PM, Dagobert Michelsen wrote: > > Phil, Mike: Please correct me if I'm wrong. > > We will put 4.2.52 back in as legacy lib in bdb4. yes this would be good. also good is, >If you could [recompile your cyrus package to use] 4.7 that would be great as we generally want to reduce dependency to old libs. From daniel at opencsw.org Sat Sep 5 01:26:16 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 05 Sep 2009 00:26:16 +0100 Subject: [csw-maintainers] Ganglia update In-Reply-To: References: <4AA179B4.3010001@opencsw.org> Message-ID: <4AA1A218.90709@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 04.09.2009 um 22:33 schrieb Daniel Pocock: >> The packages are now working, except for init scripts and SMF >> support. That will come shortly. However, people are welcome to >> test, just install the packages, and start the processes like so: >> >> On every node running the agent: >> /opt/csw/sbin/gmond -c /opt/csw/etc/ganglia/gmond.conf >> >> On the reporting server, run both the agent and the server: >> >> /opt/csw/sbin/gmond -c /opt/csw/etc/ganglia/gmond.conf >> /opt/csw/sbin/gmetad -c /opt/csw/etc/ganglia/gmetad.conf >> I've now added init scripts and SMF, so that it starts automatically when you install the package. >> Then just browse to http:///ganglia/ and enjoy >> watching the graphs. >> >> Please let me know if there is anything else horribly wrong in my >> Makefile > > Looks mighty good, however there are some minor issues: > - ETCGANGLIA should be /etc/opt/csw/ganglia Done > - For httpd-ganglia.conf you should use PRESERVECONF or SAMPLECONF from > CSWcswclassutils described here: > Done One other thing that caused some issues, I tried adding these lines: ARCHALL_CSWgangliadevel = 1 ARCHALL_CSWgangliaweb = 1 but when it gets to the install-custom code, it looks for files in the wrong place, specifically: @cd $(WORKSRC)/web; \ cp -R * $(DESTDIR)$(WWWGANGLIA) and the other lines referencing $(WORKSRC) look in the wrong place. Any hints would be welcome. From maciej at opencsw.org Sat Sep 5 10:34:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Sep 2009 09:34:58 +0100 Subject: [csw-maintainers] Can't run Sun Studio in vncserver Message-ID: I'm trying to run Sun Studio 12 IDE in vncserver. It doesn't run; it appears to be starting up for some time and the just dies with return code 2: + export netbeans_extraclusters=/opt/studio/sunstudio12.1/prod/nb-clusters/sside1 + netbeans_extraclusters=/opt/studio/sunstudio12.1/prod/nb-clusters/sside1 + /opt/studio/sunstudio12.1/netbeans/bin/netbeans -J-Dspro.home=/opt/studio/sunstudio12.1 -J-Dspro.pwd=/root -J-Dnb.registration.enabled=true -J-Dnetbeans.winsys.ctrltab.editoronly=true -J-Dspro.debugger.count=0 -J-da --branding sunstudio --userdir /root/.sunstudio/12.1-SunOS-sparc --jdkhome / netra ~ # echo $? 2 (I'm running it as root because I need to start cupsd as root and you can't run a binary as a different user than your current one in the IDE.) The computer I'm trying to run the IDE on is a Netra with 2 cores and 2GB of RAM, I think it's sufficient. System Configuration: Sun Microsystems sun4u Netra t 1120/1125 (2 X UltraSPARC-II 440MHz) System clock frequency: 110 MHz Memory size: 2048 Megabytes It doesn't print any error messages. Have you ever encountered a problem like this? Maciej From dam at opencsw.org Sat Sep 5 12:42:52 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 5 Sep 2009 12:42:52 +0200 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: References: Message-ID: <884DDCCA-830F-494A-89E2-014E9A9FA232@opencsw.org> Hi Maciej, Am 05.09.2009 um 10:34 schrieb Maciej (Matchek) Blizinski: > I'm trying to run Sun Studio 12 IDE in vncserver. It doesn't run; it > appears to be starting up for some time and the just dies with return > code 2: ... > It doesn't print any error messages. Have you ever encountered a > problem like this? I also had some problem with vncserver as it is quite old and started work on a refresher. Unfortunately vncserver is awfully hard to package as it uses a combination of Imake and scripts which require tweaking results of Imake. I committed what I have, feel free to take a look. Best regards -- Dago PS: Don't get me wrong: It should not look like everytime you ask a question I propose more work for you ;-) From dam at opencsw.org Sat Sep 5 12:54:00 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 5 Sep 2009 12:54:00 +0200 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA1A218.90709@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> Message-ID: <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> Hi Daniel, Am 05.09.2009 um 01:26 schrieb Daniel Pocock: > One other thing that caused some issues, I tried adding these lines: > > ARCHALL_CSWgangliadevel = 1 > ARCHALL_CSWgangliaweb = 1 > > but when it gets to the install-custom code, it looks for files in > the wrong place, specifically: > > @cd $(WORKSRC)/web; \ > cp -R * $(DESTDIR)$(WWWGANGLIA) > > and the other lines referencing $(WORKSRC) look in the wrong place. > Any hints would be welcome. Theoretically this can't happen as ARCHALL_* only changes the gspec file. However, I would like to reproduce it, but libconfuse has neither been released nor is it in testing/. Please build it so I can install it on build8st and retry. There is also no harm in releasing libconfuse as it is a new library. Best regards -- Dago From glaw at opencsw.org Sat Sep 5 17:48:18 2009 From: glaw at opencsw.org (Gary Law) Date: Sat, 5 Sep 2009 16:48:18 +0100 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} Message-ID: Hi My latest puppet package is clashing with CSWapache2c over permissions of /etc/opt a) what should the permissions be? b) should we put this in CSWcommon? Gary -- glaw at opencsw.org From maciej at opencsw.org Sat Sep 5 17:51:36 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Sep 2009 16:51:36 +0100 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: On Sat, Sep 5, 2009 at 4:48 PM, Gary Law wrote: > Hi > > My latest puppet package is clashing with CSWapache2c over permissions > of /etc/opt > > a) what should the permissions be? Perhaps same as /etc? > b) should we put this in CSWcommon? I think it's a good idea, it's a directory shared my multiple packages. Maciej From bwalton at opencsw.org Sat Sep 5 18:10:56 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 05 Sep 2009 12:10:56 -0400 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: <1252167009-sup-8673@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sat Sep 05 11:51:36 -0400 2009: > > b) should we put this in CSWcommon? > > I think it's a good idea, it's a directory shared my multiple packages. Yes, I think that CSWcommon should swallow up /etc/opt/csw and /var/opt/csw, if it's not already there. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Sat Sep 5 18:21:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Sep 2009 17:21:54 +0100 Subject: [csw-maintainers] Sanity checks in GAR Message-ID: Dago, My day-to-day environment has umask set to 027; but many packages, when built with this umask, end up with binaries having permissions 0750. Perhaps it would be a good idea to do a GAR sanity check: bail out if umask is set to anything else than 022 when building a package? Maciej From maciej at opencsw.org Sat Sep 5 18:29:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Sep 2009 17:29:47 +0100 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: <884DDCCA-830F-494A-89E2-014E9A9FA232@opencsw.org> References: <884DDCCA-830F-494A-89E2-014E9A9FA232@opencsw.org> Message-ID: On Sat, Sep 5, 2009 at 11:42 AM, Dagobert Michelsen wrote: > PS: Don't get me wrong: It should not look like everytime you ask a > question I propose more work for you ;-) I understand that. Such is life! Well, I've spent some time and made a little progress with the build: https://sourceforge.net/apps/trac/gar/changeset/6195 It currently fails by calling 'clean' target on directories with no Makefiles. I couldn't work out where are the calls coming from. I've commited what I have right now. Maciej From glaw at opencsw.org Sat Sep 5 19:07:05 2009 From: glaw at opencsw.org (Gary Law) Date: Sat, 5 Sep 2009 18:07:05 +0100 Subject: [csw-maintainers] New in testing: puppet-0.25 Message-ID: This is the long awaited 'go faster' release of puppet. Enjoy. Gary From daniel at opencsw.org Sat Sep 5 20:41:54 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 05 Sep 2009 19:41:54 +0100 Subject: [csw-maintainers] Ganglia update In-Reply-To: <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> Message-ID: <4AA2B0F2.9030304@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 05.09.2009 um 01:26 schrieb Daniel Pocock: >> One other thing that caused some issues, I tried adding these lines: >> >> ARCHALL_CSWgangliadevel = 1 >> ARCHALL_CSWgangliaweb = 1 >> >> but when it gets to the install-custom code, it looks for files in >> the wrong place, specifically: >> >> @cd $(WORKSRC)/web; \ >> cp -R * $(DESTDIR)$(WWWGANGLIA) >> >> and the other lines referencing $(WORKSRC) look in the wrong place. >> Any hints would be welcome. > > Theoretically this can't happen as ARCHALL_* only changes the gspec > file. However, > I would like to reproduce it, but libconfuse has neither been released > nor is it > in testing/. Please build it so I can install it on build8st and > retry. There is > also no harm in releasing libconfuse as it is a new library. > > I can log in to login.bo.opencsw.org with my ssh key From there, if I try to log in to any other machine (I've tried typing `ssh build8st'), I am asked for a password I found this document on using the build farms, but it is not 100% clear, and it says it is not for GAR users: http://www.opencsw.org/standards/pkg-walkthrough Can you suggest which document I should read for doing all this the first time? From maciej at opencsw.org Sat Sep 5 20:50:48 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Sep 2009 19:50:48 +0100 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: References: <884DDCCA-830F-494A-89E2-014E9A9FA232@opencsw.org> Message-ID: On Sat, Sep 5, 2009 at 5:29 PM, Maciej (Matchek) Blizinski wrote: > On Sat, Sep 5, 2009 at 11:42 AM, Dagobert Michelsen wrote: >> PS: Don't get me wrong: It should not look like everytime you ask a >> question I propose more work for you ;-) > > I understand that. Such is life! Well, I've spent some time and made a > little progress with the build: > > https://sourceforge.net/apps/trac/gar/changeset/6195 > > It currently fails by calling 'clean' target on directories with no > Makefiles. I couldn't work out where are the calls coming from. I've > commited what I have right now. The current issue is that it tries to call a 'clean' target in a directory which doesn't have a Makefile. I tried planting my own Makefile there to define such target, but it gets renamed to Makefile.bak and the build is still failing. I mailed vncserver's mailing list with this question. Maciej From bwalton at opencsw.org Sat Sep 5 21:04:31 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 05 Sep 2009 15:04:31 -0400 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA2B0F2.9030304@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> Message-ID: <1252177400-sup-7813@ntdws12.chass.utoronto.ca> Excerpts from Daniel Pocock's message of Sat Sep 05 14:41:54 -0400 2009: > From there, if I try to log in to any other machine (I've tried typing > `ssh build8st'), I am asked for a password Create a new key on the build farm and add the public half to your authorized_keys file. This will get you access to the build machines. > I found this document on using the build farms, but it is not 100% > clear, and it says it is not for GAR users: > > http://www.opencsw.org/standards/pkg-walkthrough Please consider this deprecated. Use the documents on the following pages as a better getting started guide: http://sourceforge.net/apps/trac/gar/ HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ja at opencsw.org Sat Sep 5 21:34:28 2009 From: ja at opencsw.org (Juergen Arndt) Date: Sat, 05 Sep 2009 21:34:28 +0200 Subject: [csw-maintainers] Why do I get V8+ binaries? Message-ID: Hi all, when compiling spine (checked in into subversion) on Solaris 8 sparc, the binary which is created is a V8+ binary. So my questions are: (1) Why it becomes a V8+? I cannot find a reason for that. (2) Is this a critical thing or can I ignore it? The name of the (one and only) binary: /opt/csw/bin/spine Thank you, Juergen -- Juergen Arndt From daniel at opencsw.org Sat Sep 5 21:54:58 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 05 Sep 2009 20:54:58 +0100 Subject: [csw-maintainers] Ganglia update In-Reply-To: <1252177400-sup-7813@ntdws12.chass.utoronto.ca> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> Message-ID: <4AA2C212.9060706@opencsw.org> > Create a new key on the build farm and add the public half to your > authorized_keys file. This will get you access to the build machines. > > I've just looked in ~/.ssh/ on login, and I see that is all set up - I can actually get to some of the machines, it is just build8st that prompts for the password >> I found this document on using the build farms, but it is not 100% >> clear, and it says it is not for GAR users: >> >> http://www.opencsw.org/standards/pkg-walkthrough >> > > Please consider this deprecated. Use the documents on the following > pages as a better getting started guide: > http://sourceforge.net/apps/trac/gar/ > > Thanks, I had been looking over that as well, but it doesn't give me specific advice about what to do when my packages are ready for release. However, I've just found this: http://www.opencsw.org/standards/ I think the heading `Pkg file creation' might need to be `Pkg file creation and release', as it gives some notes about how to release - is this the most current version of the process? From daniel at opencsw.org Sat Sep 5 22:00:57 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 05 Sep 2009 21:00:57 +0100 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA2C212.9060706@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> <4AA2C212.9060706@opencsw.org> Message-ID: <4AA2C379.1070203@opencsw.org> Daniel Pocock wrote: > >> Create a new key on the build farm and add the public half to your >> authorized_keys file. This will get you access to the build machines. >> >> > I've just looked in ~/.ssh/ on login, and I see that is all set up - I > can actually get to some of the machines, it is just build8st that > prompts for the password >>> I found this document on using the build farms, but it is not 100% >>> clear, and it says it is not for GAR users: >>> >>> http://www.opencsw.org/standards/pkg-walkthrough >>> >> >> Please consider this deprecated. Use the documents on the following >> pages as a better getting started guide: >> http://sourceforge.net/apps/trac/gar/ >> > Thanks, I had been looking over that as well, but it doesn't give me > specific advice about what to do when my packages are ready for > release. However, I've just found this: > > http://www.opencsw.org/standards/ > > I think the heading `Pkg file creation' might need to be `Pkg file > creation and release', as it gives some notes about how to release - > is this the most current version of the process? I've now built libconfuse on build8s, but can't complete the scp to www.opencsw.org as described in the document above: bash-2.03$ hostname build8s bash-2.03$ scp /home/daniel/staging/build-05.Sep.2009/libconfuse-2.6,REV\=2009.09.05-SunOS5.8-sparc-CSW.pkg.gz www.opencsw.org:/home/newpkgs ssh: connect to host www.opencsw.org port 22: Network is unreachable lost connection From daniel at opencsw.org Sat Sep 5 22:19:41 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 05 Sep 2009 21:19:41 +0100 Subject: [csw-maintainers] testing a release candidate from upstream Message-ID: <4AA2C7DD.2090304@opencsw.org> Ganglia 3.1.3 will have some Solaris specific fixes (e.g. a seg fault when the first CPU is not in slot 0) I'd like to test release candidate for 3.1.3 (in other words, the monitor-core-3.1 branch from upstream SVN) by building OpenCSW packages on each of the build machines. This way any final issues can be resolved before upstream tags the release. What is the normal way of doing such a build? I notice that with my existing Makefile for the Ganglia CSW package, it wants to download a released ganglia-X.tar.gz From skayser at opencsw.org Sat Sep 5 23:05:08 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sat, 05 Sep 2009 23:05:08 +0200 Subject: [csw-maintainers] Why do I get V8+ binaries? In-Reply-To: References: Message-ID: <4AA2D284.1030401@opencsw.org> Hi Juergen, Juergen Arndt wrote on 05.09.2009 21:34: > when compiling spine (checked in into subversion) on Solaris 8 sparc, the > binary which is created is a V8+ binary. So my questions are: > > (1) Why it becomes a V8+? I cannot find a reason for that. > (2) Is this a critical thing or can I ignore it? > > The name of the (one and only) binary: /opt/csw/bin/spine it's simple. :) You are using a custom configure target which is missing the $(CONFIGURE_ENV) environment and thus the $(CFLAGS), in particular the -xarch=v8 one. Better use the pre-configure-modulated hook instead. I have committed an adjusted version of the Makefile. $ svn diff -r6089:6199 Makefile In case you want to revert these changes just do $ svn merge -r6199:6089 Makefile $ svn commit -m "spine: Undid r6199" Sebastian From skayser at opencsw.org Sat Sep 5 23:07:11 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sat, 05 Sep 2009 23:07:11 +0200 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA2C379.1070203@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> <4AA2C212.9060706@opencsw.org> <4AA2C379.1070203@opencsw.org> Message-ID: <4AA2D2FF.5050405@opencsw.org> Hi Daniel, Daniel Pocock wrote on 05.09.2009 22:00: > I've now built libconfuse on build8s, but can't complete the scp to > www.opencsw.org as described in the document above: > > bash-2.03$ hostname > build8s > bash-2.03$ scp > /home/daniel/staging/build-05.Sep.2009/libconfuse-2.6,REV\=2009.09.05-SunOS5.8-sparc-CSW.pkg.gz > www.opencsw.org:/home/newpkgs > ssh: connect to host www.opencsw.org port 22: Network is unreachable > lost connection outgoing SSH from the build hosts is blocked. You need to scp from the login host. Sebastian From bonivart at opencsw.org Sun Sep 6 00:08:38 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 6 Sep 2009 00:08:38 +0200 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: <625385e30909051508q2df9f78cpd1cbd9b9294edcee@mail.gmail.com> On Sat, Sep 5, 2009 at 5:48 PM, Gary Law wrote: > Hi > > My latest puppet package is clashing with CSWapache2c over permissions > of /etc/opt > > a) what should the permissions be? > b) should we put this in CSWcommon? Aren't /etc/opt and /var/opt installed by default in Solaris? I think you should start with /etc/opt/csw and /var/opt/csw respectively. Both those are included in CSWcommon and CSWcswclassutils. -- /peter From glaw at opencsw.org Sun Sep 6 00:50:15 2009 From: glaw at opencsw.org (Gary Law) Date: Sat, 5 Sep 2009 23:50:15 +0100 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: <625385e30909051508q2df9f78cpd1cbd9b9294edcee@mail.gmail.com> References: <625385e30909051508q2df9f78cpd1cbd9b9294edcee@mail.gmail.com> Message-ID: 2009/9/5 Peter Bonivart : > Aren't /etc/opt and /var/opt installed by default in Solaris? I think > you should start with /etc/opt/csw and /var/opt/csw respectively. Both > those are included in CSWcommon and CSWcswclassutils. In which case there is a bug in CSWapache2c and my package too. I don't have a clean Solaris install to hand to check this; if someone could confirm this is correct I'll fix up my package and fill a mantis bug on Apache. Thanks Gary -- Gary Law Email: garylaw at garylaw.net Chat googletalk/messenger: gary.law at gmail.com iChat/jabber/AIM: gary.law at mac.com From glaw at opencsw.org Sun Sep 6 02:18:58 2009 From: glaw at opencsw.org (Gary Law) Date: Sun, 6 Sep 2009 01:18:58 +0100 Subject: [csw-maintainers] testing a release candidate from upstream In-Reply-To: <4AA2C7DD.2090304@opencsw.org> References: <4AA2C7DD.2090304@opencsw.org> Message-ID: Hi Daniel 2009/9/5 Daniel Pocock : > I'd like to test release candidate for 3.1.3 (in other words, the > monitor-core-3.1 branch from upstream SVN) by building OpenCSW packages on > each of the build machines. ?This way any final issues can be resolved > before upstream tags the release. I've recently done this with the puppet 0.25 RC build. As it violates OpenCSW rules for release I built it, tested it, and made it available not through OpenCSW (advertised on the puppet dev list). I assumed RC software violates the ''no betas'' rule. Perhaps it would be OK to release this just to ''testing'' but I've not seen this done before and so didn't blaze a trail. Incidentally, this RC trial was very useful and identified at least one bug that would most likely have been missed had I not done this, and which is now fixed upstream. > What is the normal way of doing such a build? ?I notice that with my > existing Makefile for the Ganglia CSW package, it wants to download a > released ganglia-X.tar.gz Is the RC available as a downloadable tar.gz? In which case GAR can be kidded into building it AFAIK. If it's just an SVN checkout you'll have to make a tar of your own and put it where GAR expects to find it I think. Gary -- Gary Law glaw at opencsw.org From bwalton at opencsw.org Sun Sep 6 02:31:19 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 05 Sep 2009 20:31:19 -0400 Subject: [csw-maintainers] testing a release candidate from upstream In-Reply-To: References: <4AA2C7DD.2090304@opencsw.org> Message-ID: <1252197025-sup-3410@ntdws12.chass.utoronto.ca> Excerpts from Gary Law's message of Sat Sep 05 20:18:58 -0400 2009: > Is the RC available as a downloadable tar.gz? In which case GAR can be > kidded into building it AFAIK. If it's just an SVN checkout you'll > have to make a tar of your own and put it where GAR expects to find it > I think. There is some support in GAR for tracking an upstream svn repo instead of a tarball. I haven't used it and can't speak to how well it works, but it is in there. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton at opencsw.org Sun Sep 6 03:08:43 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 05 Sep 2009 21:08:43 -0400 Subject: [csw-maintainers] Summary for OpenCSW summer camp? In-Reply-To: <05320A9D-7803-4BF9-832E-72BF83950470@opencsw.org> References: <1251420014-sup-2740@ntdws12.chass.utoronto.ca> <05320A9D-7803-4BF9-832E-72BF83950470@opencsw.org> Message-ID: <1252199120-sup-3463@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sat Aug 29 04:32:38 -0400 2009: Hi Dago, > Please follow-up so it didn't get lost the second time. I just commited the updated checkpkg to GAR. It's the reference script in gar/bin/checkpkg now, although it's not used by GAR at this point. The following modification would be required to force this version into play: --snip-- Index: gar.pkg.mk =================================================================== --- gar.pkg.mk (revision 6198) +++ gar.pkg.mk (working copy) @@ -587,7 +587,7 @@ pkgcheck-%: @echo " ==> Checking compliance: $*" - @( LC_ALL=C checkpkg $(SPKG_EXPORT)/`$(call _PKG_ENV,$1) mkpackage -qs $(WORKDIR)/$*.gspec -D pkgfile`.gz ) || exit 2 + @( LC_ALL=C $(GARBIN)/checkpkg $(SPKG_EXPORT)/`$(call _PKG_ENV,$1) mkpackage -qs $(WORKDIR)/$*.gspec -D pkgfile`.gz ) || exit 2 pkgcheck-p: @$(foreach COOKIEFILE,$(PKGCHECK_TARGETS), test -e $(COOKIEDIR)/$(COOKIEFILE) ;) --snip-- This new version can handle libraries that are split out as well as inter-set dependencies. I've tested with the packages created by the bind build (since none of them are on the build farm boxes) and it seems to behave properly. If you're happy with this, I can proceed to modifying GAR so that all packages are validated together which would leverage the new capabilities. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ja at opencsw.org Sun Sep 6 06:55:51 2009 From: ja at opencsw.org (Juergen Arndt) Date: Sun, 06 Sep 2009 06:55:51 +0200 Subject: [csw-maintainers] Why do I get V8+ binaries? In-Reply-To: <4AA2D284.1030401@opencsw.org> References: <4AA2D284.1030401@opencsw.org> Message-ID: Hi Sebastian, On Sat, 05 Sep 2009 23:05:08 +0200, Sebastian Kayser wrote: > it's simple. :) You are using a custom configure target which is missing > the $(CONFIGURE_ENV) environment and thus the $(CFLAGS), in particular > the -xarch=v8 one. Uh, shame on me :) Now as you say it, it's obviously :) > Better use the pre-configure-modulated hook instead. I have committed an > adjusted version of the Makefile. Great, thanks a lot! Juergen -- Juergen Arndt From skayser at opencsw.org Sun Sep 6 07:50:21 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 06 Sep 2009 07:50:21 +0200 Subject: [csw-maintainers] testing a release candidate from upstream In-Reply-To: <1252197025-sup-3410@ntdws12.chass.utoronto.ca> References: <4AA2C7DD.2090304@opencsw.org> <1252197025-sup-3410@ntdws12.chass.utoronto.ca> Message-ID: <4AA34D9D.3060501@opencsw.org> Ben Walton wrote on 06.09.2009 02:31: > Excerpts from Gary Law's message of Sat Sep 05 20:18:58 -0400 2009: > >> Is the RC available as a downloadable tar.gz? In which case GAR can be >> kidded into building it AFAIK. If it's just an SVN checkout you'll >> have to make a tar of your own and put it where GAR expects to find it >> I think. > > There is some support in GAR for tracking an upstream svn repo instead > of a tarball. I haven't used it and can't speak to how well it works, > but it is in there. Haven't used it either, but here are a couple of examples https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/websvn/trunk/Makefile https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/xmlrpc_c/trunk/Makefile Sebastian From maciej at opencsw.org Sun Sep 6 09:07:04 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 6 Sep 2009 08:07:04 +0100 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: <625385e30909051508q2df9f78cpd1cbd9b9294edcee@mail.gmail.com> Message-ID: On Sat, Sep 5, 2009 at 11:50 PM, Gary Law wrote: > 2009/9/5 Peter Bonivart : >> Aren't /etc/opt and /var/opt installed by default in Solaris? I think >> you should start with /etc/opt/csw and /var/opt/csw respectively. Both >> those are included in CSWcommon and CSWcswclassutils. > > In which case there is a bug in CSWapache2c and my package too. I > don't have a clean Solaris install to hand to check this; if someone > could confirm this is correct I'll fix up my package and fill a mantis > bug on Apache. Yes, this is correct. You can remove this path, and ignore the warning about the missing path. Maciej From daniel at opencsw.org Sun Sep 6 09:47:14 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Sun, 06 Sep 2009 08:47:14 +0100 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA2D2FF.5050405@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> <4AA2C212.9060706@opencsw.org> <4AA2C379.1070203@opencsw.org> <4AA2D2FF.5050405@opencsw.org> Message-ID: <4AA36902.4050908@opencsw.org> Sebastian Kayser wrote: > Hi Daniel, > > Daniel Pocock wrote on 05.09.2009 22:00: > >> I've now built libconfuse on build8s, but can't complete the scp to >> www.opencsw.org as described in the document above: >> >> bash-2.03$ hostname >> build8s >> bash-2.03$ scp >> /home/daniel/staging/build-05.Sep.2009/libconfuse-2.6,REV\=2009.09.05-SunOS5.8-sparc-CSW.pkg.gz >> www.opencsw.org:/home/newpkgs >> ssh: connect to host www.opencsw.org port 22: Network is unreachable >> lost connection >> > > outgoing SSH from the build hosts is blocked. You need to scp from the > login host. > > OK, the libconfuse package is now in www.opencsw.org:/home/newpkgs How do I go about having it installed on the build machines so that I can build the Ganglia packages for release? From skayser at opencsw.org Sun Sep 6 14:34:33 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 06 Sep 2009 14:34:33 +0200 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA36902.4050908@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> <4AA2C212.9060706@opencsw.org> <4AA2C379.1070203@opencsw.org> <4AA2D2FF.5050405@opencsw.org> <4AA36902.4050908@opencsw.org> Message-ID: <4AA3AC59.4030902@opencsw.org> Daniel Pocock wrote on 06.09.2009 09:47: > Sebastian Kayser wrote: >> Daniel Pocock wrote on 05.09.2009 22:00: >>> I've now built libconfuse on build8s, but can't complete the scp to >>> www.opencsw.org as described in the document above: >>> >>> bash-2.03$ hostname >>> build8s >>> bash-2.03$ scp >>> /home/daniel/staging/build-05.Sep.2009/libconfuse-2.6,REV\=2009.09.05-SunOS5.8-sparc-CSW.pkg.gz >>> www.opencsw.org:/home/newpkgs >>> ssh: connect to host www.opencsw.org port 22: Network is unreachable >>> lost connection >>> >> outgoing SSH from the build hosts is blocked. You need to scp from the >> login host. >> >> > OK, the libconfuse package is now in www.opencsw.org:/home/newpkgs > > How do I go about having it installed on the build machines so that I > can build the Ganglia packages for release? Let Phil now that the libconfuse package resides in newpkgs (see [1] all the way down for some instructions) and once it has been published to the catalog, mail the buildfarm admins [2] to have it installed on the build farm boxes. Sebastian [1] http://opencsw.org/standards/pkg-walkthrough [2] http://opencsw.org/standards/build_farm From ja at opencsw.org Sun Sep 6 16:00:20 2009 From: ja at opencsw.org (Juergen Arndt) Date: Sun, 06 Sep 2009 16:00:20 +0200 Subject: [csw-maintainers] Spine 0.8.7e in testing Message-ID: Hi all, I put spine 0.8.7e into testing. Spine - formally known as Cactid - is a alternative poller for cacti. Feedback is welcome. Juergen -- Juergen Arndt From dam at opencsw.org Sun Sep 6 22:04:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:04:26 +0200 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: Hi Gary, Am 05.09.2009 um 17:48 schrieb Gary Law: > My latest puppet package is clashing with CSWapache2c over permissions > of /etc/opt CSWapache2c should not contain /etc/opt as it is already in SUNWcsr (with root:sys 0755). > a) what should the permissions be? The path should not be included in CSW packages. /etc/opt/csw is already in CSWcommon and should therefore also not be included (and is by default root:bin 0755) > b) should we put this in CSWcommon? It already is amongst /var/opt/csw. See the commondirs excluded from GAR here http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/etc which are extracted from the CSWcommon package. (If it is a good idea to build CSWcommon manually and derive pathes in GAR from it and not the other way round is another discussion). Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:14:20 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:14:20 +0200 Subject: [csw-maintainers] Sanity checks in GAR In-Reply-To: References: Message-ID: <911063D4-D74B-498B-953A-AA5392B7CC92@opencsw.org> Hi Maciej, Am 05.09.2009 um 18:21 schrieb Maciej (Matchek) Blizinski: > My day-to-day environment has umask set to 027; but many packages, > when built with this umask, end up with binaries having permissions > 0750. Perhaps it would be a good idea to do a GAR sanity check: bail > out if umask is set to anything else than 022 when building a package? The standard user:group are already set in cswproto, as are the permissions for directories: > # Prototype defaults > $StdOwn = 'root'; > $StdGrp = 'bin'; > $StdDirPerm = '0755'; I could imagine setting a default for files. Or changing the umask to 022 automatically on GAR invocation. BTW, we still a way of easily tweaking the prototype as PROTOTYPE_FILTERs are still too complex. Something like this could be useful: PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf PROTOTYPE_PERMS_mytweaks = 0644 PROTOTYPE_CLASS_mytweaks = cswconffile PROTOTYPE_MODIFIERS = mytweaks Here, PROTOTYPE_MODIFIERS is a list of modifiers to apply where for each modifier one or more fields can be changed. Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:17:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:17:13 +0200 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: References: <884DDCCA-830F-494A-89E2-014E9A9FA232@opencsw.org> Message-ID: Hi Maciej, Am 05.09.2009 um 18:29 schrieb Maciej (Matchek) Blizinski: > On Sat, Sep 5, 2009 at 11:42 AM, Dagobert Michelsen > wrote: >> PS: Don't get me wrong: It should not look like everytime you ask a >> question I propose more work for you ;-) > > I understand that. Such is life! Well, I've spent some time and made a > little progress with the build: > > https://sourceforge.net/apps/trac/gar/changeset/6195 A small comment: - You have removed "TEST_SCRIPTS =" and inserted "SKIPTEST = 1". The SKIPTEST is meant to be used dynamically during package when you don't want to wait, like gmake clean && SKIPTEST = 1 gmake package When the package doesn't have a test script cleaning TEST_SCRIPTS is clearer. Apart from that: good work! Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:19:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:19:45 +0200 Subject: [csw-maintainers] Why do I get V8+ binaries? In-Reply-To: References: Message-ID: Hi J?rgen, Am 05.09.2009 um 21:34 schrieb Juergen Arndt: > when compiling spine (checked in into subversion) on Solaris 8 > sparc, the binary which is created is a V8+ binary. So my questions > are: > > (1) Why it becomes a V8+? I cannot find a reason for that. > (2) Is this a critical thing or can I ignore it? It is sort of critical as the binaries are then no longer runnable on all machines supported by Solaris 8. However, as we officially deprecated Solaris 8 this is not really bad, but still a Good Thing(tm) to do. Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:22:04 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:22:04 +0200 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA2C212.9060706@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> <4AA2C212.9060706@opencsw.org> Message-ID: <076A724E-CC40-41D9-85E5-291045D393D5@opencsw.org> Hi Daniel, Am 05.09.2009 um 21:54 schrieb Daniel Pocock: >> Create a new key on the build farm and add the public half to your >> authorized_keys file. This will get you access to the build >> machines. >> > > I've just looked in ~/.ssh/ on login, and I see that is all set up - > I can actually get to some of the machines, it is just build8st that > prompts for the password The test machines don't have fully synced user accounts as they tend to be down from time to time. As we are working on LDAP accounts this will go away soon. Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:26:04 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:26:04 +0200 Subject: [csw-maintainers] testing a release candidate from upstream In-Reply-To: <4AA2C7DD.2090304@opencsw.org> References: <4AA2C7DD.2090304@opencsw.org> Message-ID: Hi Daniel, Am 05.09.2009 um 22:19 schrieb Daniel Pocock: > Ganglia 3.1.3 will have some Solaris specific fixes (e.g. a seg > fault when the first CPU is not in slot 0) > > I'd like to test release candidate for 3.1.3 (in other words, the > monitor-core-3.1 branch from upstream SVN) by building OpenCSW > packages on each of the build machines. This way any final issues > can be resolved before upstream tags the release. > > What is the normal way of doing such a build? I notice that with my > existing Makefile for the Ganglia CSW package, it wants to download > a released ganglia-X.tar.gz The easiest thing is that you roll your own ganglia-3.1.3rc1.tar.gz package and put it in /home/src. This will be tried first on downloading. You can also subscribe to SVN which is described in (4) at but "gmake garchive" will not upload the revision, so you may not always get what you expect. That's way I recommend rolling up your dist. Couldn't you just gmake tardist or something from the checked out thing? Then just copy over to /home/ src. Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:27:23 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:27:23 +0200 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA2D2FF.5050405@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> <4AA2C212.9060706@opencsw.org> <4AA2C379.1070203@opencsw.org> <4AA2D2FF.5050405@opencsw.org> Message-ID: Hi, Am 05.09.2009 um 23:07 schrieb Sebastian Kayser: > Daniel Pocock wrote on 05.09.2009 22:00: >> I've now built libconfuse on build8s, but can't complete the scp to >> www.opencsw.org as described in the document above: >> >> bash-2.03$ hostname >> build8s >> bash-2.03$ scp >> /home/daniel/staging/build-05.Sep.2009/libconfuse-2.6,REV >> \=2009.09.05-SunOS5.8-sparc-CSW.pkg.gz >> www.opencsw.org:/home/newpkgs >> ssh: connect to host www.opencsw.org port 22: Network is unreachable >> lost connection > > outgoing SSH from the build hosts is blocked. You need to scp from the > login host. To be precise: It is not blocked. The buildmachines have private IP adresses from 192.168.* and there is no natting. 'login' is dual-homed with an official and a 192.168.* address. For HTTP and SVN/WebDAV there is a proxy installed. Best regard -- Dago From dam at opencsw.org Sun Sep 6 22:29:21 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:29:21 +0200 Subject: [csw-maintainers] testing a release candidate from upstream In-Reply-To: References: <4AA2C7DD.2090304@opencsw.org> Message-ID: Hi Gary, Am 06.09.2009 um 02:18 schrieb Gary Law: > I've recently done this with the puppet 0.25 RC build. As it violates > OpenCSW rules for release I built it, tested it, and made it available > not through OpenCSW (advertised on the puppet dev list). I assumed RC > software violates the ''no betas'' rule. For release to current/: yes. > Perhaps it would be OK to > release this just to ''testing'' but I've not seen this done before > and so didn't blaze a trail. Absolutely, this is what testing/ is for. Just put in there what you want to have tested. No need to transfer the packages to other sites. Upstream is one of the things I consider very important and we are offering accounts on the build farm to upstream maintainers not making packages, btw. Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:33:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:33:43 +0200 Subject: [csw-maintainers] 'checkpkg' checking multiple packages at once In-Reply-To: <1252199120-sup-3463@ntdws12.chass.utoronto.ca> References: <1251420014-sup-2740@ntdws12.chass.utoronto.ca> <05320A9D-7803-4BF9-832E-72BF83950470@opencsw.org> <1252199120-sup-3463@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 06.09.2009 um 03:08 schrieb Ben Walton: > I just commited the updated checkpkg to GAR. It's the reference > script in gar/bin/checkpkg now, although it's not used by GAR at this > point. The following modification would be required to force this > version into play: > > --snip-- > Index: gar.pkg.mk > =================================================================== > --- gar.pkg.mk (revision 6198) > +++ gar.pkg.mk (working copy) > @@ -587,7 +587,7 @@ > > pkgcheck-%: > @echo " ==> Checking compliance: $*" > - @( LC_ALL=C checkpkg $(SPKG_EXPORT)/`$(call _PKG_ENV,$1) > mkpackage -qs $(WORKDIR)/$*.gspec -D pkgfile`.gz ) || exit 2 > + @( LC_ALL=C $(GARBIN)/checkpkg $(SPKG_EXPORT)/`$(call > _PKG_ENV,$1) mkpackage -qs $(WORKDIR)/$*.gspec -D pkgfile`.gz > ) || exit 2 > > pkgcheck-p: > @$(foreach COOKIEFILE,$(PKGCHECK_TARGETS), test -e > $(COOKIEDIR)/$(COOKIEFILE) ;) > --snip-- > > This new version can handle libraries that are split out as well as > inter-set dependencies. I've tested with the packages created by the > bind build (since none of them are on the build farm boxes) and it > seems to behave properly. > > If you're happy with this, I can proceed to modifying GAR so that all > packages are validated together which would leverage the new > capabilities. Cool! Phil: I would include that into CSWcswutils, ok? Ben: If the updated version gets into CSWcswutils there is no need for a GAR-private checkpkg. CSWcswutils is already built with GAR and checkpkg is tracked at Best regards -- Dago From maciej at opencsw.org Mon Sep 7 10:28:55 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 7 Sep 2009 09:28:55 +0100 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: References: <884DDCCA-830F-494A-89E2-014E9A9FA232@opencsw.org> Message-ID: On Sun, Sep 6, 2009 at 9:17 PM, Dagobert Michelsen wrote: > A small comment: > - You have removed "TEST_SCRIPTS =" and inserted "SKIPTEST = 1". The > SKIPTEST > ?is meant to be used dynamically during package when you don't want to wait, > like > ? ?gmake clean && SKIPTEST = 1 gmake package > ?When the package doesn't have a test script cleaning TEST_SCRIPTS is > clearer. I see, I changed it back to TEST_SCRIPTS. The build scripts for tightvnc are indeed quite convoluted. I was stuck for quite a while at a place where there was a missing flag "-f xmakefile", and gmake wasn't executing the right Makefile. I suspect some changes I'm making to the Makefile aren't really necessary, but it's very time consuming to figure out what are the perfect options, and I only want to have something running, as soon as possible, with the intention to clean it up later. What I really don't like about the way tightvnc is built is that the script don't always stop on errors. For instance: gmake[7]: Entering directory `/home/maciej/src/opencsw/pkg/tightvnc/trunk/work/build-isa-sparcv8/vnc_unixsrc/Xvnc/config/makedepend' /opt/studio/SOS11/SUNWspro/bin/cc -xO3 -xarch=v8 -I/usr/openwin/share/include/X11 -I/opt/csw/include -I/usr/openwin/share/include/X11 -I/opt/csw/include -c -o include.o include.c "/usr/openwin/share/include/X11/Xos.h", line 35: cannot find include file: cc: acomp failed for include.c gmake[7]: *** [include.o] Error 1 gmake[7]: Leaving directory `/home/maciej/src/opencsw/pkg/tightvnc/trunk/work/build-isa-sparcv8/vnc_unixsrc/Xvnc/config/makedepend' okay, continuing in programs/Xserver/cfb32 ...and then it finally fails with: cc: acomp failed for include.c gmake[7]: *** [include.o] Error 1 gmake[7]: Leaving directory `/home/maciej/src/opencsw/pkg/tightvnc/trunk/work/build-isa-sparcv8/vnc_unixsrc/Xvnc/config/makedepend' okay, continuing in programs/Xserver/hw/vnc ../../../../config/makedepend/makedepend -- -I. -I../../../../exports/include/X11 -I../../../../include/fonts -I../../../../exports/include/X11 -I../../cfb -I../../mfb -I../../mi -I../../include -I../../os -I../../../../../include -I/usr/local/include -I../../../.. -I../../../../exports/include -Dsun -DSVR4 -DSHAPE -DINCLUDE_ALLOCA_H -DNDEBUG -DUSE_LIBWRAP=1 -DDDXOSINIT -- init.c sockets.c kbdptr.c cmap.c draw.c cutpaste.c dispcur.c sprite.c rfbserver.c translate.c httpd.c auth.c rre.c corre.c stats.c hextile.c zlib.c tight.c cursor.c gmake[6]: ../../../../config/makedepend/makedepend: Command not found I'm wondering whether anybody has ever built it on Solaris; I guess not. Now I need to track where is the flag -I/usr/openwin/share/include/X11 coming from and fix it. I've committed the current state of the build to the repository: http://sourceforge.net/apps/trac/gar/changeset/6213 Maciej From schwindt at dfki.uni-kl.de Mon Sep 7 10:41:25 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 07 Sep 2009 10:41:25 +0200 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: Your message of "Sat, 05 Sep 2009 09:34:58 BST." Message-ID: <200909070841.n878fPOX017084@dfki.uni-kl.de> [...] > It doesn't print any error messages. Have you ever encountered a > problem like this? Yes - back then I used x11vnc to tunnel the display. It sucks, like vncserver - but java guis get displayed. Nicolai From james at opencsw.org Mon Sep 7 11:54:46 2009 From: james at opencsw.org (James Lee) Date: Mon, 07 Sep 2009 09:54:46 GMT Subject: [csw-maintainers] Why do I get V8+ binaries? In-Reply-To: References: Message-ID: <20090907.9544600.1130459864@gyor.oxdrove.co.uk> On 06/09/09, 21:19:45, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Why do I get V8+ binaries?: > > sparc, the binary which is created is a V8+ binary. So my questions > > are: > > > > (1) Why it becomes a V8+? I cannot find a reason for that. > > (2) Is this a critical thing or can I ignore it? > It is sort of critical as the binaries are then no longer runnable on > all > machines supported by Solaris 8. However, as we officially deprecated > Solaris 8 this is not really bad, but still a Good Thing(tm) to do. Solaris 9 runs on sun4m so the Solaris 8 point is invalid. We will continue to support 9 for some time so the sun4m question remains. Does sun4m matter? It seems to matter to a few people and although they are only small number it is 100% critical to them. I do my bit to run a living computer museum but I am long past running a sun4m machine for anything other than a toy or test. I can just see why a stand alone server might be better on a Sparc20 as my SS20 (125MHz, 512GB RAM) uses 58 Watts idle whereas my Blade2000 (1.2GHz, 8GB RAM) use 185W idle. Of course the Blade 2000 can do what a the SS20 can in one of its corners with no one noticing plus 10 times more but this assume I have the faster machine running and have more to do. Why anyone chooses to run GUI apps on such slow hardware is beyond me. However because we run an integrated system long dependency chains dictate the base arch, i.e. if one package fails the system fails. Finally it's worth pointing out that in most cases sun4m (code not chip) gives the same performance as sun4u (sparcv8plus+vis) and where it differs and matters we have the isaexec and $ISALIST mechanisms. Consider also that for many programs speed is not important and small size might be the goal (-xO3 -xspace), e.g. background daemons and network limited. James. From dam at opencsw.org Mon Sep 7 13:23:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 7 Sep 2009 13:23:55 +0200 Subject: [csw-maintainers] Why do I get V8+ binaries? In-Reply-To: <20090907.9544600.1130459864@gyor.oxdrove.co.uk> References: <20090907.9544600.1130459864@gyor.oxdrove.co.uk> Message-ID: <1B5148EF-904C-43ED-BA62-72AF77F182AC@opencsw.org> Hi James, Am 07.09.2009 um 11:54 schrieb James Lee: > On 06/09/09, 21:19:45, Dagobert Michelsen wrote > regarding >> It is sort of critical as the binaries are then no longer runnable on >> all >> machines supported by Solaris 8. However, as we officially deprecated >> Solaris 8 this is not really bad, but still a Good Thing(tm) to do. > > Solaris 9 runs on sun4m so the Solaris 8 point is invalid. We will > continue to support 9 for some time so the sun4m question remains. Ups, sorry. > Does sun4m matter? It seems to matter to a few people and although > they are only small number it is 100% critical to them. > > I do my bit to run a living computer museum but I am long past running > a sun4m machine for anything other than a toy or test. I can just see > why a stand alone server might be better on a Sparc20 as my SS20 > (125MHz, 512GB RAM) WOW! 512 GB is a hell of a lot - even for a Sparc20 :-D > uses 58 Watts idle whereas my Blade2000 (1.2GHz, > 8GB RAM) use 185W idle. Of course the Blade 2000 can do what a the > SS20 can in one of its corners with no one noticing plus 10 times more > but this assume I have the faster machine running and have more to do. > Why anyone chooses to run GUI apps on such slow hardware is beyond me. > However because we run an integrated system long dependency chains > dictate the base arch, i.e. if one package fails the system fails. Best regards -- Dago From james at opencsw.org Mon Sep 7 13:47:43 2009 From: james at opencsw.org (James Lee) Date: Mon, 07 Sep 2009 11:47:43 GMT Subject: [csw-maintainers] Why do I get V8+ binaries? In-Reply-To: <1B5148EF-904C-43ED-BA62-72AF77F182AC@opencsw.org> References: <20090907.9544600.1130459864@gyor.oxdrove.co.uk> <1B5148EF-904C-43ED-BA62-72AF77F182AC@opencsw.org> Message-ID: <20090907.11474300.259407791@gyor.oxdrove.co.uk> On 07/09/09, 12:23:55, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Why do I get V8+ binaries?: > > why a stand alone server might be better on a Sparc20 as my SS20 > > (125MHz, 512GB RAM) > WOW! 512 GB is a hell of a lot - even for a Sparc20 :-D Ha, that shows the GB has been the basic unit of RAM for so long... James. From bwalton at opencsw.org Mon Sep 7 23:09:53 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Sep 2009 17:09:53 -0400 Subject: [csw-maintainers] updated libxslt in testing Message-ID: <1252357584-sup-7025@ntdws12.chass.utoronto.ca> Hi All, I've placed updated packages (untested by myself yet) in testing/. These introduce catalog name changes for the python bindings (now py_libxslt) and the devel files (libxslt_devel now). The update includes a patch to correct a sefault while debugging xsltproc runs but otherwise should be identical to the current release. I'll be testing the packages later tonight or tomorrow, but if you happen to update from testing today you may want to be aware of these name changes. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Tue Sep 8 10:33:57 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 8 Sep 2009 09:33:57 +0100 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory Message-ID: Most packages put their files in /opt/csw; but some seem to be special, and use /opt/csw/${something}. For instance, MySQL 5 uses /opt/csw/mysql5. I understand that it's a way of having multiple versions of MySQL on one system at the same time, but it's somewhat annoying to not have the mysql binaries in the PATH right after installation. Was /opt/csw/mysql5 with a separate bin with no symlinks from /opt/csw/bin a solution that was a result of a discussion, or was is only because the maintainer just did it this way? Maciej From maciej at opencsw.org Tue Sep 8 20:46:10 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 8 Sep 2009 19:46:10 +0100 Subject: [csw-maintainers] sh: gnome-config: not found Message-ID: I'm trying to build pinentry. Here's where I'm currently stuck: $ PKG_CONFIG=/opt/csw/lib/pkgconfig pkg-config --exists gtk+-2.0 sh: gnome-config: not found The needed file is present on the disk: $ glocate gtk+-2.0.pc /opt/csw/lib/amd64/pkgconfig/gtk+-2.0.pc /opt/csw/lib/pkgconfig/gtk+-2.0.pc /usr/lib/amd64/pkgconfig/gtk+-2.0.pc /usr/lib/pkgconfig/gtk+-2.0.pc Is it a common problem? Is there a workaround? Maciej From skayser at opencsw.org Tue Sep 8 21:06:43 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 08 Sep 2009 21:06:43 +0200 Subject: [csw-maintainers] sh: gnome-config: not found In-Reply-To: References: Message-ID: <4AA6AB43.7060304@opencsw.org> Maciej (Matchek) Blizinski wrote on 08.09.2009 20:46: > I'm trying to build pinentry. Here's where I'm currently stuck: > > $ PKG_CONFIG=/opt/csw/lib/pkgconfig pkg-config --exists gtk+-2.0 > sh: gnome-config: not found > > The needed file is present on the disk: > > $ glocate gtk+-2.0.pc > /opt/csw/lib/amd64/pkgconfig/gtk+-2.0.pc > /opt/csw/lib/pkgconfig/gtk+-2.0.pc > /usr/lib/amd64/pkgconfig/gtk+-2.0.pc > /usr/lib/pkgconfig/gtk+-2.0.pc > > Is it a common problem? Is there a workaround? Seems to be a result of the CSW X11 lib relocation to /opt/csw/X11/lib. While looking for gtk+-2.0, pkg-config searches for xcb, falls back to legacy gnome-config and fails (issue pkg-config with --debug to trace this down). Pointing PKG_CONFIG_PATH to /opt/csw/X11/lib does the trick for me. Should this PKG_CONFIG_PATH be added to the GAR defaults? Sebastian From maciej at opencsw.org Tue Sep 8 21:12:22 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 8 Sep 2009 20:12:22 +0100 Subject: [csw-maintainers] sh: gnome-config: not found In-Reply-To: <4AA6AB43.7060304@opencsw.org> References: <4AA6AB43.7060304@opencsw.org> Message-ID: On Tue, Sep 8, 2009 at 8:06 PM, Sebastian Kayser wrote: > Seems to be a result of the CSW X11 lib relocation to /opt/csw/X11/lib. > While looking for gtk+-2.0, pkg-config searches for xcb, falls back to > legacy gnome-config and fails (issue pkg-config with --debug to trace > this down). > > Pointing PKG_CONFIG_PATH to /opt/csw/X11/lib does the trick for me. Works here too. Thanks! > Should this PKG_CONFIG_PATH be added to the GAR defaults? +1 Maciej From dam at opencsw.org Tue Sep 8 23:01:56 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Sep 2009 23:01:56 +0200 Subject: [csw-maintainers] Bug resolving processess Message-ID: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> Hi, after some discussion with James I made an outline for processing bugs on the wiki: Feel free to comment. Best regards -- Dago From maciej at opencsw.org Tue Sep 8 23:09:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 8 Sep 2009 22:09:46 +0100 Subject: [csw-maintainers] Bug resolving processess In-Reply-To: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> References: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> Message-ID: On Tue, Sep 8, 2009 at 10:01 PM, Dagobert Michelsen wrote: > Hi, > > after some discussion with James I made an outline for processing > bugs on the wiki: > > Feel free to comment. In the case of hard-to-reproduce bugs, there could be a timeout on the response from the reporter. In other words, if there was a bug report which a maintainer could not reproduce and the reporter has disappeared, the bug could be closed after X amount of time. Maciej From maciej at opencsw.org Tue Sep 8 23:12:09 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 8 Sep 2009 22:12:09 +0100 Subject: [csw-maintainers] Bug resolving processess In-Reply-To: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> References: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> Message-ID: On Tue, Sep 8, 2009 at 10:01 PM, Dagobert Michelsen wrote: > after some discussion with James I made an outline for processing > bugs on the wiki: > > Feel free to comment. Point 9 looks like it could be automated. If there was a machine readable information about which version fixes the issue, a script could test mirrors for this version and mail the maintainer or even close the bug automatically. Maciej From skayser at opencsw.org Tue Sep 8 23:19:34 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 08 Sep 2009 23:19:34 +0200 Subject: [csw-maintainers] Bug resolving processess In-Reply-To: References: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> Message-ID: <4AA6CA66.5000008@opencsw.org> Maciej (Matchek) Blizinski wrote on 08.09.2009 23:12: > On Tue, Sep 8, 2009 at 10:01 PM, Dagobert Michelsen wrote: >> after some discussion with James I made an outline for processing >> bugs on the wiki: >> >> Feel free to comment. > > Point 9 looks like it could be automated. If there was a machine > readable information about which version fixes the issue, a script > could test mirrors for this version and mail the maintainer or even > close the bug automatically. Or the maintainer could submit that information (think "Closes #XXXX") along with the new package in a machine readable format. The release manager could then hook this into the release process and have it close the bug automatically on package release. Sebastian From bonivart at opencsw.org Tue Sep 8 23:45:38 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 8 Sep 2009 23:45:38 +0200 Subject: [csw-maintainers] Bug resolving processess In-Reply-To: <4AA6CA66.5000008@opencsw.org> References: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> <4AA6CA66.5000008@opencsw.org> Message-ID: <625385e30909081445o6316e82dtbdc155924109461c@mail.gmail.com> On Tue, Sep 8, 2009 at 11:19 PM, Sebastian Kayser wrote: >> Point 9 looks like it could be automated. If there was a machine >> readable information about which version fixes the issue, a script >> could test mirrors for this version and mail the maintainer or even >> close the bug automatically. > > Or the maintainer could submit that information (think "Closes #XXXX") > along with the new package in a machine readable format. The release > manager could then hook this into the release process and have it close > the bug automatically on package release. I'm all for automation but in this case it seems it saves very little time and effort. Compared to the process of fixing the bug, testing the solution, releasing a new package a couple of clicks is nothing. The only real benefit I see is that we don't forget to close bugs but we already get weekly reminders so... -- /peter From maciej at opencsw.org Wed Sep 9 10:39:10 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 09:39:10 +0100 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) Message-ID: I've spent some more time on tightvnc. There was a response from their mailing list, perhaps I'll get some help there. I'm currently trying to build it the simplest way possible, just to get it to build, and then gradually tidy it up. I'm using a short shell script. It currently fails with: gmake[3]: Leaving directory `/home/maciej/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc' LD_RUN_PATH=/usr/openwin/lib /opt/studio/SOS12/SUNWspro/bin/cc -o Xvnc -xO3 -Xa -L/opt/csw/lib -L../.././/exports/lib dix/libdix.a os/libos.a ../.././/lib/Xau/libXau.a ../.././/lib/Xdmcp/libXdmcp.a ../.././/exports/lib/libfont.a hw/vnc/libvnc.a ../.././/../libvncauth/libvncauth.a cfb/libcfb.a cfb16/libcfb.a cfb24/libcfb.a cfb32/libcfb.a mfb/libmfb.a dix/libxpstubs.a mi/libmi.a Xext/libext.a -lsocket -lnsl -lm -L/usr/local/lib -ljpeg -lz -lcrypt Undefined first referenced symbol in file ffsl os/libos.a(WaitFor.o) ld: fatal: Symbol referencing errors. No output written to Xvnc gmake[2]: *** [Xvnc] Error 1 The libos.a library in fact refers to the ffsl symbol: maciej at netra ~/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver $ nm os/libos.a | grep ffsl [51] | 0| 0|FUNC |GLOB |0 |UNDEF |ffsl [91] | 0| 0|FUNC |GLOB |0 |UNDEF |ffsl [51] | 0| 0|FUNC |GLOB |0 |UNDEF |ffsl ...and libdix.a contains it: maciej at netra ~/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver $ nm dix/libdix.a | grep ffsl dix/libdix.a[ffsl.o]: [9] | 16| 72|FUNC |GLOB |0 |2 |ffsl [1] | 0| 0|FILE |LOCL |0 |ABS |ffsl.c The script and its output: http://netra.chopin.edu.pl/~maciej/tightvnc/tightvnc-1.3.10-20090909-095450-build.sh.txt http://netra.chopin.edu.pl/~maciej/tightvnc/tightvnc-1.3.10-20090909-095450.log I find it strange that it doesn't find this symbol, because dix/libdix.a is present in the cc invocation (see above). Do you have any ideas what might be the problem? Maciej From skayser at opencsw.org Wed Sep 9 11:05:46 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 09 Sep 2009 11:05:46 +0200 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: References: Message-ID: <4AA76FEA.1060408@opencsw.org> Maciej (Matchek) Blizinski wrote on 09.09.2009 10:39: > I've spent some more time on tightvnc. There was a response from their > mailing list, perhaps I'll get some help there. I'm currently trying > to build it the simplest way possible, just to get it to build, and > then gradually tidy it up. I'm using a short shell script. It > currently fails with: > > gmake[3]: Leaving directory > `/home/maciej/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc' > LD_RUN_PATH=/usr/openwin/lib /opt/studio/SOS12/SUNWspro/bin/cc -o Xvnc > -xO3 -Xa -L/opt/csw/lib -L../.././/exports/lib dix/libdix.a > os/libos.a ../.././/lib/Xau/libXau.a ../.././/lib/Xdmcp/libXdmcp.a > ../.././/exports/lib/libfont.a hw/vnc/libvnc.a > ../.././/../libvncauth/libvncauth.a cfb/libcfb.a cfb16/libcfb.a > cfb24/libcfb.a cfb32/libcfb.a mfb/libmfb.a dix/libxpstubs.a mi/libmi.a > Xext/libext.a -lsocket -lnsl -lm -L/usr/local/lib > -ljpeg -lz -lcrypt > Undefined first referenced > symbol in file > ffsl os/libos.a(WaitFor.o) > ld: fatal: Symbol referencing errors. No output written to Xvnc > gmake[2]: *** [Xvnc] Error 1 > > The libos.a library in fact refers to the ffsl symbol: > > maciej at netra ~/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver $ nm > os/libos.a | grep ffsl > [51] | 0| 0|FUNC |GLOB |0 |UNDEF |ffsl > [91] | 0| 0|FUNC |GLOB |0 |UNDEF |ffsl > [51] | 0| 0|FUNC |GLOB |0 |UNDEF |ffsl > > ...and libdix.a contains it: > > maciej at netra ~/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver $ nm > dix/libdix.a | grep ffsl > dix/libdix.a[ffsl.o]: > [9] | 16| 72|FUNC |GLOB |0 |2 |ffsl > [1] | 0| 0|FILE |LOCL |0 |ABS |ffsl.c > > The script and its output: > http://netra.chopin.edu.pl/~maciej/tightvnc/tightvnc-1.3.10-20090909-095450-build.sh.txt > http://netra.chopin.edu.pl/~maciej/tightvnc/tightvnc-1.3.10-20090909-095450.log > > I find it strange that it doesn't find this symbol, because > dix/libdix.a is present in the cc invocation (see above). Do you have > any ideas what might be the problem? AFAIR symbol resolution during the link phase takes place _once_ from left to right, where symbol references come first and symbol definitions need to be placed on the right hand side. >From ld(1): Archives are traditionally specified at the end of the command line so that their symbol definitions resolve any preceding references. However, specifying archives multiple times to satisfy their own interdependencies, can be neces- sary. Above, dix/libdix.a (symbol definition) comes before os/libos.a (symbol reference). Does it make a difference when add another dix/libdix.a _after_ os/libos.a? Sebastian From maciej at opencsw.org Wed Sep 9 11:26:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 10:26:01 +0100 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: <4AA76FEA.1060408@opencsw.org> References: <4AA76FEA.1060408@opencsw.org> Message-ID: On Wed, Sep 9, 2009 at 10:05 AM, Sebastian Kayser wrote: > Maciej (Matchek) Blizinski wrote on 09.09.2009 10:39: >> I find it strange that it doesn't find this symbol, because >> dix/libdix.a is present in the cc invocation (see above). Do you have >> any ideas what might be the problem? > > AFAIR symbol resolution during the link phase takes place _once_ from > left to right, where symbol references come first and symbol definitions > need to be placed on the right hand side. > > >From ld(1): > > Archives are > traditionally specified at the end of the command line > so that their symbol definitions resolve any preceding > references. However, specifying archives multiple times > to satisfy their own interdependencies, can be neces- > sary. > > Above, dix/libdix.a (symbol definition) comes before os/libos.a (symbol > reference). Does it make a difference when add another dix/libdix.a > _after_ os/libos.a? maciej at netra ~/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver $ LD_RUN_PATH=/usr/openwin/lib /opt/studio/SOS12/SUNWspro/bin/cc -o Xvnc -xO3 -Xa -L/opt/csw/lib -L../.././/exports/lib dix/libdix.a os/libos.a dix/libdix.a ../.././/lib/Xau/libXau.a ../.././/lib/Xdmcp/libXdmcp.a ../.././/exports/lib/libfont.a hw/vnc/libvnc.a ../.././/../libvncauth/libvncauth.a cfb/libcfb.a cfb16/libcfb.a cfb24/libcfb.a cfb32/libcfb.a mfb/libmfb.a dix/libxpstubs.a mi/libmi.a Xext/libext.a -lsocket -lnsl -lm -L/usr/local/lib -ljpeg -lz -lcrypt maciej at netra ~/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver $ Wow, it worked! Thanks! Maciej From dam at opencsw.org Wed Sep 9 11:31:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Sep 2009 11:31:45 +0200 Subject: [csw-maintainers] Updating all farm servers to current/ Message-ID: Hi, I am updating all build servers to current now. Please stand by. Sorry for the inconvenience -- Dago From maciej at opencsw.org Wed Sep 9 14:56:45 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 13:56:45 +0100 Subject: [csw-maintainers] Using package overlay with UNCOMMITTED packages Message-ID: I'm currently developing a workflow for building and testing packages at work. I'm using pkgutil's package overlay support with "-t". The current problem I see is that if a package has UNCOMMITTED status, pkgutil doesn't install it. I can (non-)solve this by committing every change before building. Otherwise, I perhaps could stop GAR from appending UNCOMMITTED, or make pkgutil accept them. Which one do you think is best? Maciej From dam at opencsw.org Wed Sep 9 15:18:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Sep 2009 15:18:22 +0200 Subject: [csw-maintainers] Using package overlay with UNCOMMITTED packages In-Reply-To: References: Message-ID: <1A0ADE92-E692-4B22-92D2-8114993702EF@opencsw.org> Hi Maciej, Am 09.09.2009 um 14:56 schrieb Maciej (Matchek) Blizinski: > I'm currently developing a workflow for building and testing packages > at work. I'm using pkgutil's package overlay support with "-t". The > current problem I see is that if a package has UNCOMMITTED status, > pkgutil doesn't install it. I can (non-)solve this by committing every > change before building. Otherwise, I perhaps could stop GAR from > appending UNCOMMITTED, or make pkgutil accept them. Which one do you > think is best? It is not related to pkgutil as my catalog generation tool skips files with UNCOMMITTED in them. If we consider it generally ok to have those packages in testing I can change that and include them in the catalog. I'll write something up as it is related to the new release process we have been talking about in Oslo. Best regards -- Dago From skayser at opencsw.org Wed Sep 9 15:23:24 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 09 Sep 2009 15:23:24 +0200 Subject: [csw-maintainers] Using package overlay with UNCOMMITTED packages In-Reply-To: <1A0ADE92-E692-4B22-92D2-8114993702EF@opencsw.org> References: <1A0ADE92-E692-4B22-92D2-8114993702EF@opencsw.org> Message-ID: <4AA7AC4C.6050100@opencsw.org> Dagobert Michelsen wrote on 09.09.2009 15:18: > Am 09.09.2009 um 14:56 schrieb Maciej (Matchek) Blizinski: >> I'm currently developing a workflow for building and testing packages >> at work. I'm using pkgutil's package overlay support with "-t". The >> current problem I see is that if a package has UNCOMMITTED status, >> pkgutil doesn't install it. I can (non-)solve this by committing every >> change before building. Otherwise, I perhaps could stop GAR from >> appending UNCOMMITTED, or make pkgutil accept them. Which one do you >> think is best? > > It is not related to pkgutil as my catalog generation tool skips > files with UNCOMMITTED in them. If we consider it generally ok to > have those packages in testing I can change that and include them > in the catalog. Sounds like something that should rather go into "experimental". Would be nice to get testing a bit more stable so that users can test stuff in there without hosing their system. Sebastian From maciej at opencsw.org Wed Sep 9 16:01:45 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 15:01:45 +0100 Subject: [csw-maintainers] Using package overlay with UNCOMMITTED packages In-Reply-To: <4AA7AC4C.6050100@opencsw.org> References: <1A0ADE92-E692-4B22-92D2-8114993702EF@opencsw.org> <4AA7AC4C.6050100@opencsw.org> Message-ID: On Wed, Sep 9, 2009 at 2:23 PM, Sebastian Kayser wrote: >> It is not related to pkgutil as my catalog generation tool skips >> files with UNCOMMITTED in them. If we consider it generally ok to >> have those packages in testing I can change that and include them >> in the catalog. > > Sounds like something that should rather go into "experimental". Would > be nice to get testing a bit more stable so that users can test stuff in > there without hosing their system. Maybe this could be an option to bldcat: --experimental or --include-uncommitted, or something similar. Maciej From dam at opencsw.org Wed Sep 9 16:15:54 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Sep 2009 16:15:54 +0200 Subject: [csw-maintainers] Using package overlay with UNCOMMITTED packages In-Reply-To: References: <1A0ADE92-E692-4B22-92D2-8114993702EF@opencsw.org> <4AA7AC4C.6050100@opencsw.org> Message-ID: <851E90D7-B2FD-427C-8CDF-BC1220E26974@opencsw.org> Hi Maciej, Am 09.09.2009 um 16:01 schrieb Maciej (Matchek) Blizinski: > On Wed, Sep 9, 2009 at 2:23 PM, Sebastian > Kayser wrote: >>> It is not related to pkgutil as my catalog generation tool skips >>> files with UNCOMMITTED in them. If we consider it generally ok to >>> have those packages in testing I can change that and include them >>> in the catalog. >> >> Sounds like something that should rather go into "experimental". >> Would >> be nice to get testing a bit more stable so that users can test >> stuff in >> there without hosing their system. > > Maybe this could be an option to bldcat: --experimental or > --include-uncommitted, or something similar. Ok, maybe I didn't make that clear: It is my tool linking packages to the subdir where the catalog is made. bldcat just takes everything in there and adds it to the catalog, the files are just linked in there. Best regards -- Dago From maciej at opencsw.org Wed Sep 9 17:32:28 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 16:32:28 +0100 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: References: <4AA76FEA.1060408@opencsw.org> Message-ID: Dago, I could get it to build, but only when I didn't use the USE_LIBWRAP bit. Here's a change that builds on Solaris 10 with SOS12 for me: http://sourceforge.net/apps/trac/gar/changeset/6245 I'll now test it on the buildfarm. Can you tell me why USE_LIBWRAP and is it important that it's being used? Maciej From bwalton at opencsw.org Wed Sep 9 17:37:03 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Sep 2009 11:37:03 -0400 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: References: <4AA76FEA.1060408@opencsw.org> Message-ID: <1252510559-sup-591@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Sep 09 11:32:28 -0400 2009: > Can you tell me why USE_LIBWRAP and is it important that it's being used? If the old package was using libwrap, it's fairly important for the update to use it also. Users would need a BIG BOLD notice if this behaviour changed since they may be relying on that security layer. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Wed Sep 9 17:44:59 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Sep 2009 17:44:59 +0200 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: References: <4AA76FEA.1060408@opencsw.org> Message-ID: <21CC7EA2-B1FB-4079-A8F7-177C4F60C608@opencsw.org> Hi Maciej, Am 09.09.2009 um 17:32 schrieb Maciej (Matchek) Blizinski: > Dago, I could get it to build, but only when I didn't use the > USE_LIBWRAP bit. Here's a change that builds on Solaris 10 with SOS12 > for me: > > http://sourceforge.net/apps/trac/gar/changeset/6245 > > I'll now test it on the buildfarm. > > Can you tell me why USE_LIBWRAP and is it important that it's being > used? That is TCPWrappers, allowing to restrict access to the port centrally to certain IP-adresses or ranges. Where is the problem? The tcpwrappers version we have is current (7.6), but without 64 bit libraries. Phil: Do you mind pushing the build notes so I can get it into GAR with 64 bit libs? Best regards -- Dago From maciej at opencsw.org Wed Sep 9 18:16:24 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 17:16:24 +0100 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: <21CC7EA2-B1FB-4079-A8F7-177C4F60C608@opencsw.org> References: <4AA76FEA.1060408@opencsw.org> <21CC7EA2-B1FB-4079-A8F7-177C4F60C608@opencsw.org> Message-ID: On Wed, Sep 9, 2009 at 4:44 PM, Dagobert Michelsen wrote: > That is TCPWrappers, allowing to restrict access to the port > centrally to certain IP-adresses or ranges. Where is the problem? /usr/ccs/bin/ar cq libvnc.a init.o sockets.o kbdptr.o cmap.o draw.o cutpaste.o dispcur.o sprite.o rfbserver.o translate.o httpd.o auth.o rre.o corre.o stats.o hextile.o zlib.o tight.o cursor.o gmake[5]: Leaving directory `/home/maciej/src/opencsw/pkg/tightvnc/trunk/work/build-isa-sparcv8/vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc' LD_RUN_PATH=/usr/openwin/lib /opt/studio/SOS11/SUNWspro/bin/cc -o Xvnc -xO3 -Xa -L/opt/csw/lib -L../.././/exports/lib dix/libdix.a os/libos.a ../.././/lib/Xau/libXau.a ../.././/lib/Xdmcp/libXdmcp.a dix/libdix.a ../.././/exports/lib/libfont.a hw/vnc/libvnc.a ../.././/../libvncauth/libvncauth.a cfb/libcfb.a cfb16/libcfb.a cfb24/libcfb.a cfb32/libcfb.a mfb/libmfb.a dix/libxpstubs.a mi/libmi.a Xext/libext.a -lsocket -lnsl -lm -L/usr/local/lib -ljpeg -lz -lcrypt Undefined first referenced symbol in file hosts_ctl hw/vnc/libvnc.a(sockets.o) ld: fatal: Symbol referencing errors. No output written to Xvnc gmake[4]: *** [Xvnc] Error 1 The build ignores the EXTRA_LIBRARIES variable. It's present in the generated Makefile, but set to something different that what's in the GAR Makefile. Maciej From bwalton at opencsw.org Wed Sep 9 18:34:28 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Sep 2009 12:34:28 -0400 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: References: <4AA76FEA.1060408@opencsw.org> <21CC7EA2-B1FB-4079-A8F7-177C4F60C608@opencsw.org> Message-ID: <1252514027-sup-683@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Sep 09 12:16:24 -0400 2009: > The build ignores the EXTRA_LIBRARIES variable. It's present in the > generated Makefile, but set to something different that what's in the > GAR Makefile. So you're adding -lwrap (or whatever the format is) to EXTRA_LIBRARIES and it's completely ignoring it? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Wed Sep 9 18:49:50 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 17:49:50 +0100 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: <1252514027-sup-683@ntdws12.chass.utoronto.ca> References: <4AA76FEA.1060408@opencsw.org> <21CC7EA2-B1FB-4079-A8F7-177C4F60C608@opencsw.org> <1252514027-sup-683@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Sep 9, 2009 at 5:34 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Wed Sep 09 12:16:24 -0400 2009: > >> The build ignores the EXTRA_LIBRARIES variable. It's present in the >> generated Makefile, but set to something different that what's in the >> GAR Makefile. > > So you're adding -lwrap (or whatever the format is) to EXTRA_LIBRARIES > and it's completely ignoring it? Yes. Tired of being a gentleman with this build, I took a big hammer and forced -lwrap down its throat: diff --git a/Xvnc/config/cf/vnclibs.def b/Xvnc/config/cf/vnclibs.def index c033ca7..948fd7a 100644 --- a/Xvnc/config/cf/vnclibs.def +++ b/Xvnc/config/cf/vnclibs.def @@ -11,7 +11,7 @@ VNCLIBS = $(TOP)/../libvncauth/libvncauth.a /* Avoid linking with different libjpeg in /usr/shlib under Tru64. */ VNCSYSLIBS = /usr/local/lib/libjpeg.a /usr/local/lib/libz.a -lcrypt #else -VNCSYSLIBS = -L/usr/local/lib -ljpeg -lz -lcrypt +VNCSYSLIBS = -L/usr/local/lib -ljpeg -lz -lcrypt -lwrap #endif VNCCPPFLAGS = -I$(TOP)/../include -I/usr/local/include -- 1.6.3.2 It builds now! Maciej From maciej at opencsw.org Wed Sep 9 21:15:33 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 20:15:33 +0100 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: <200909070841.n878fPOX017084@dfki.uni-kl.de> References: <200909070841.n878fPOX017084@dfki.uni-kl.de> Message-ID: I've just successfully built tightvnc-1.3.10. It passed the smoke test, including running Sun Studio in it -- it works! The binaries are available in testing. Enjoy! Maciej From maciej at opencsw.org Wed Sep 9 21:18:41 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 20:18:41 +0100 Subject: [csw-maintainers] Basic X fonts from OpenCSW Message-ID: When one installs vncserver from OpenCSW and tries to run it, one gets: $ vncserver :1 Couldn't start Xvnc; trying default font path. Please set correct fontPath in the vncserver script. How about providing a dependency -- a package with basic X fonts? Has anyone here tried that yet? Maciej From maciej at opencsw.org Wed Sep 9 21:35:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 20:35:39 +0100 Subject: [csw-maintainers] Builds that are difficult on Solaris 8 Message-ID: Some builds are more difficult on Solaris 8 than others. For instance, pinentry contains code which doesn't compile with SOS11. I could probably fix it, but I'm not really willing to spend more time re-writing bits of code to compile there, but there are thing I feel are more important to me than that. What's the best way of going about it? Is it okay to build and release Solaris 10-only packages? (I mean small things like pinentry, that is.) Maciej From bwalton at opencsw.org Wed Sep 9 21:46:46 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Sep 2009 15:46:46 -0400 Subject: [csw-maintainers] Builds that are difficult on Solaris 8 In-Reply-To: References: Message-ID: <1252525541-sup-901@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Sep 09 15:35:39 -0400 2009: > it? Is it okay to build and release Solaris 10-only packages? (I mean > small things like pinentry, that is.) Don't forget about solaris 9! :) Also, if the build would go with gcc on solaris 8, that's still a better option[1], imo. -Ben [1] Says the guy who still has solaris 8 boxes using the CSW stack in production... :( -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ihsan at dogan.ch Thu Sep 10 09:07:27 2009 From: ihsan at dogan.ch (Ihsan Dogan) Date: Thu, 10 Sep 2009 09:07:27 +0200 Subject: [csw-maintainers] Oracle Says ... Message-ID: <4AA8A5AF.6010807@dogan.ch> http://www.oracle.com/features/suncustomers.html -- ihsan at dogan.ch http://blog.dogan.ch/ From daniel at opencsw.org Thu Sep 10 19:26:27 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 10 Sep 2009 18:26:27 +0100 Subject: [csw-maintainers] Ganglia update In-Reply-To: <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> Message-ID: <4AA936C3.1090002@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 05.09.2009 um 01:26 schrieb Daniel Pocock: >> One other thing that caused some issues, I tried adding these lines: >> >> ARCHALL_CSWgangliadevel = 1 >> ARCHALL_CSWgangliaweb = 1 >> >> but when it gets to the install-custom code, it looks for files in >> the wrong place, specifically: >> >> @cd $(WORKSRC)/web; \ >> cp -R * $(DESTDIR)$(WWWGANGLIA) >> >> and the other lines referencing $(WORKSRC) look in the wrong place. >> Any hints would be welcome. > > Theoretically this can't happen as ARCHALL_* only changes the gspec > file. However, > I would like to reproduce it, but libconfuse has neither been released > nor is it > in testing/. Please build it so I can install it on build8st and > retry. There is > also no harm in releasing libconfuse as it is a new library. Phil has accepted it, but I notice errors about mantis on the package page: http://www.opencsw.org/packages/libconfuse "Err: cannot find maintainer for libconfuse in mantis." I've tried creating an account for myself in Mantis using the same email address that I included in the package, but the error remains. Not sure how long it takes to appear in the mirrors, or is there anything else I need to do before that happens? From maciej at opencsw.org Thu Sep 10 20:41:14 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Sep 2009 19:41:14 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: After considering all the options, I wrote an example implementation[1] of the one that does symlinks, and used it for the unixodbc package. Trygvis had objected to putting it into testing, and then disappeared in a black hole. I pulled the package from testing; moved it into a subdirectory. Meanwhile, there is more and more packages that are being held back by this issue, notably, there are cups and tightvnc. Let's get it sorted out and move forward! The issue isn't entirely new, one might point out. There are packages which already migrate their configuration files[2]. The case currently discussed isn't as simple though, because it's a migration from a single shared configuration instance into many per-zone configuration instances. There is a number of options discussed on the wiki page[3]. I'd like to ask if people have any other options to offer. There another case to consider: the case when the configuration files can't be automatically migrated. Should the preinstall script abort the installation? (Can it really abort the installation?) Any other ideas? At the end of the discussion, I'd be happy if we had a canonical implementation of the migration; possibly using a common script, put into cswclassutils. Please respond to the mailing list, and I'll update the wiki page. Maciej [1] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/unixodbc/trunk/files/CSWunixodbc.postinstall [2] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/phpldapadmin/trunk/files/CSWphpldapadmin.preinstall [3] http://opencsw.wikidot.com/configuration-directory-migration From phil at bolthole.com Thu Sep 10 21:49:16 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Sep 2009 12:49:16 -0700 Subject: [csw-maintainers] Oracle Says ... In-Reply-To: <4AA8A5AF.6010807@dogan.ch> References: <4AA8A5AF.6010807@dogan.ch> Message-ID: Would have been nice to have a summary, Ihsan ;-) Nice pointer though. summary: oracle plans to double sun's previous spending on hardware dev, AND solaris dev. "we're in it to win it", Larry Ellison says. interesting. On Thu, Sep 10, 2009 at 12:07 AM, Ihsan Dogan wrote: > http://www.oracle.com/features/suncustomers.html > > -- From phil at bolthole.com Thu Sep 10 21:50:41 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Sep 2009 12:50:41 -0700 Subject: [csw-maintainers] Builds that are difficult on Solaris 8 In-Reply-To: References: Message-ID: On Wed, Sep 9, 2009 at 12:35 PM, Maciej (Matchek) Blizinski wrote: > Some builds are more difficult on Solaris 8 than others. For instance, > pinentry contains code which doesn't compile with SOS11. I could > probably fix it, but I'm not really willing to spend more time > re-writing bits of code to compile there, but there are thing I feel > are more important to me than that. What's the best way of going about > it? I think that it is ALWAYS a good idea, when you feel stumped/overwhelmed yourself, to post your specific errors encountered to the maint list. Your own "impossible block" problem, may be someone else's "been there done that". From bwalton at opencsw.org Thu Sep 10 21:55:16 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 10 Sep 2009 15:55:16 -0400 Subject: [csw-maintainers] Oracle Says ... In-Reply-To: References: <4AA8A5AF.6010807@dogan.ch> Message-ID: <1252612402-sup-9351@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Sep 10 15:49:16 -0400 2009: > summary: oracle plans to double sun's previous spending on hardware > dev, AND solaris dev. SPARC dev, not just hardware, which could be taken to mean their x86 server engineering. It'll be interesting to watch, for sure. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Thu Sep 10 21:55:31 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Sep 2009 12:55:31 -0700 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA936C3.1090002@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA936C3.1090002@opencsw.org> Message-ID: On Thu, Sep 10, 2009 at 10:26 AM, Daniel Pocock wrote: > > I've tried creating an account for myself in Mantis using the same email > address that I included in the package, but the error remains. > > Not sure how long it takes to appear in the mirrors, or is there anything > else I need to do before that happens? > arg. ok, bumped things. From maciej at opencsw.org Fri Sep 11 00:13:57 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Sep 2009 23:13:57 +0100 Subject: [csw-maintainers] Pinentry compilation problem Message-ID: I'm trying to compile pinentry with SOS11 on Solaris 8. I'm getting the following error: gmake[4]: Entering directory `/home/maciej/src/opencsw/pkg/pinentry/trunk/work/build-isa-sparcv8/pinentry-0.7.6/secmem' source='secmem.c' object='secmem.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../depcomp \ /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I.. -I/opt/csw/X11/include -I/opt/csw/include -xO3 -xarch=v8 -I/opt/csw/X11/include -I/opt/csw/include -c secmem.c source='util.c' object='util.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../depcomp \ /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I.. -I/opt/csw/X11/include -I/opt/csw/include -xO3 -xarch=v8 -I/opt/csw/X11/include -I/opt/csw/include -c util.c "util.c", line 57: syntax error before or at: { "util.c", line 57: undefined symbol: __result "util.c", line 57: undefined symbol: __result "util.c", line 57: undefined symbol: __result "util.c", line 57: syntax error before or at: ) "util.c", line 58: warning: syntax error: empty declaration "util.c", line 59: cannot recover from previous errors cc: acomp failed for util.c gmake[4]: *** [util.o] Error 2 The place in the code that causes the problem is: #ifndef TEMP_FAILURE_RETRY #define TEMP_FAILURE_RETRY(expression) \ ( \ ({ long int __result; \ do __result = (long int) (expression); \ while (__result == -1L && errno == EINTR); \ __result; })) #endif With SOS12, this code compiles just fine. Any ideas? Maciej From james at opencsw.org Fri Sep 11 10:41:28 2009 From: james at opencsw.org (James Lee) Date: Fri, 11 Sep 2009 08:41:28 GMT Subject: [csw-maintainers] Pinentry compilation problem In-Reply-To: References: Message-ID: <20090911.8412800.3475687791@gyor.oxdrove.co.uk> On 10/09/09, 23:13:57, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] Pinentry compilation problem: > "util.c", line 57: syntax error before or at: { > "util.c", line 57: undefined symbol: __result > "util.c", line 57: undefined symbol: __result > "util.c", line 57: undefined symbol: __result > "util.c", line 57: syntax error before or at: ) > "util.c", line 58: warning: syntax error: empty declaration > "util.c", line 59: cannot recover from previous errors > cc: acomp failed for util.c > gmake[4]: *** [util.o] Error 2 > The place in the code that causes the problem is: > #ifndef TEMP_FAILURE_RETRY > #define TEMP_FAILURE_RETRY(expression) \ > ( \ > ({ long int __result; \ > do __result = (long int) (expression); \ > while (__result == -1L && errno == EINTR); \ > __result; })) > #endif It's so nasty it deserves to fail anyway but let's look at the syntax. It condenses to: answer = ( { 1; 2; } ); in the hope that answer is assigned to 2. I'd object to it and it isn't valid in Java either. Try passing the lvalue to the macro and using like a void function: #define TEMP_FAILURE_RETRY(result, expression) \ { long int __result; \ do __result = (long int) (expression); \ while (__result == -1L && errno == EINTR); \ result = __result; } #endif Or rewrite as a function, this might not be work depending on the values used for expression: long int TEMP_FAILURE_RETRY(long int (*expression)(void)) { long int __result; do __result = (long int) (expression); while (__result == -1L && errno == EINTR); return __result; } Clean up: long int TEMP_FAILURE_RETRY(long int (*expression)(void)) { long int result; while ((result = (long int) (expression)) == -1L && errno == EINTR); return result; } James. From james at opencsw.org Fri Sep 11 10:51:04 2009 From: james at opencsw.org (James Lee) Date: Fri, 11 Sep 2009 08:51:04 GMT Subject: [csw-maintainers] Pinentry compilation problem In-Reply-To: <20090911.8412800.3475687791@gyor.oxdrove.co.uk> References: <20090911.8412800.3475687791@gyor.oxdrove.co.uk> Message-ID: <20090911.8510400.1335098705@gyor.oxdrove.co.uk> On 11/09/09, 09:41:28, James Lee wrote regarding Re: [csw-maintainers] Pinentry compilation problem: I really should try things before emailing :-) it's been too long since I wrote any pointer to functions. long int TEMP_FAILURE_RETRY(long int (*expression)(void)) { long int __result; do __result = expression(); while (__result == -1L && errno == EINTR); return __result; } Clean up: long int TEMP_FAILURE_RETRY(long int (*expression)(void)) { long int result; while ((result = expression()) == -1L && errno == EINTR); return result; } That looks better - but I've still not tried it. James. From dam at opencsw.org Fri Sep 11 12:02:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 11 Sep 2009 12:02:13 +0200 Subject: [csw-maintainers] Release of updated cairo In-Reply-To: <4AAA1F2F.30806@pocock.com.au> References: <4AA522F3.6070903@pocock.com.au> <9D68CA91-DBC1-4756-B90F-007E2122F831@opencsw.org> <4AA56225.1050307@pocock.com.au> <6130367B-C3FE-49B3-81B0-B3850DBAC572@opencsw.org> <4AAA1B8B.7030700@pocock.com.au> <60378F51-D464-46B7-8A85-16B771E6D104@opencsw.org> <4AAA1F2F.30806@pocock.com.au> Message-ID: Hi, Am 11.09.2009 um 11:58 schrieb Daniel Pocock: > Dagobert Michelsen wrote: >> Hi Daniel, >> >> Am 11.09.2009 um 11:42 schrieb Daniel Pocock: >>> I also need the rrdtool package on all the build machines so I can >>> build my packages. >> >> ?? rrdtool is already on all build machines, or are you missing >> something? > > Actually, you are right - rrd.h is there, it is the cairo issue John: How about releasing the updated cairo from testing? Best regards -- Dago From dam at opencsw.org Fri Sep 11 16:52:08 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 11 Sep 2009 16:52:08 +0200 Subject: [csw-maintainers] Updated OpenLDAP and other things In-Reply-To: References: <4A37FE7D.5080608@opencsw.org> Message-ID: <26D3D290-8AC5-4530-BC8B-314B0E7877FA@opencsw.org> Hi, Updated packages with the latest OpenLDAP 2.4.18 is in testing. Mike: It would be great if you could take a look at the startup scripts and do some more testing on it. The build recipe is fully committed. Dominique, Sebastian and I had a terrific day hacking at OpenLDAP and also Kerberos 1.7 is almost finished :) To anyone with spare cycles: There is *a lot* of updated stuff in testing/. Please try it out and give feedback of any kind. Best regards -- Dago From dam at opencsw.org Fri Sep 11 16:56:01 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 11 Sep 2009 16:56:01 +0200 Subject: [csw-maintainers] libconfuse and Solaris 10 version Message-ID: Hi Daniel, there are two versions of libconfuse in testing, one for Solaris 8+9 and one for Solaris 10. There is only one version synced to the mirrors: Solaris 8. Is this what you intended? Best regards -- Dago From trygvis at opencsw.org Fri Sep 11 17:11:27 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Fri, 11 Sep 2009 17:11:27 +0200 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: <4AAA689F.1030703@opencsw.org> Dagobert Michelsen wrote: > Hi Gary, > > Am 05.09.2009 um 17:48 schrieb Gary Law: >> My latest puppet package is clashing with CSWapache2c over permissions >> of /etc/opt > > CSWapache2c should not contain /etc/opt as it is already in SUNWcsr > (with root:sys 0755). > >> a) what should the permissions be? > > The path should not be included in CSW packages. /etc/opt/csw is already > in CSWcommon and should therefore also not be included (and is by > default root:bin 0755) > >> b) should we put this in CSWcommon? > > It already is amongst /var/opt/csw. See the commondirs excluded from GAR > here > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/etc > which are extracted from the CSWcommon package. (If it is a good idea > to build CSWcommon manually and derive pathes in GAR from it and not > the other way round is another discussion). These requirements sounds like something that should be implemented in checkpkg. -- Trygve From phil at bolthole.com Fri Sep 11 18:01:15 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Sep 2009 09:01:15 -0700 Subject: [csw-maintainers] Basic X fonts from OpenCSW In-Reply-To: References: Message-ID: If the system already HAS "basic X fonts", this seems rather a waste of space. We sometimes duplicate sun packages, but usually only because there is a specific benefit to it. I'm not sure there is a benefit in this case, though. It may be better to simply declare a dependancy on the SUNW basic fonts package. On Wed, Sep 9, 2009 at 12:18 PM, Maciej (Matchek) Blizinski wrote: > When one installs vncserver from OpenCSW and tries to run it, one gets: > > $ vncserver :1 > Couldn't start Xvnc; trying default font path. > Please set correct fontPath in the vncserver script. > > How about providing a dependency -- a package with basic X fonts? Has > anyone here tried that yet? > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > From phil at bolthole.com Fri Sep 11 18:04:23 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Sep 2009 09:04:23 -0700 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: Message-ID: well,, there are multiple potential "issues" at play here. on the one hand, I understand your frustration at not having it normally in the path. But what would be the side effects of having a symlink /opt/csw/bin/mysql -> /opt/csw/mysql5/bin/mysql ? Would it break auto-detection of mysql location, when compiling? and... is that ok anyway, since we dont have auto-detection now anyway? :-) It may indeed be appropriate to adjust our mysql5 package to have the symlink in there. BTW: would you be intersted in taking over our mysql package, for purposes of updating, and putting the symlink in there? (pleasepleasepleaseplease? :-) On Tue, Sep 8, 2009 at 1:33 AM, Maciej (Matchek) Blizinski wrote: > Most packages put their files in /opt/csw; but some seem to be > special, and use /opt/csw/${something}. For instance, MySQL 5 uses > /opt/csw/mysql5. I understand that it's a way of having multiple > versions of MySQL on one system at the same time, but it's somewhat > annoying to not have the mysql binaries in the PATH right after > installation. Was /opt/csw/mysql5 with a separate bin with no symlinks > from /opt/csw/bin a solution that was a result of a discussion, or was > is only because the maintainer just did it this way? > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > From phil at bolthole.com Fri Sep 11 18:22:05 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Sep 2009 09:22:05 -0700 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: On Thu, Sep 10, 2009 at 11:41 AM, Maciej (Matchek) Blizinski wrote: > > There another case to consider: the case when the configuration files > can't be automatically migrated. Should the preinstall script abort > the installation? (Can it really abort the installation?) Any other > ideas? > I did already give my own opinion on this one; yes it should stop the install. and yes it has the power to do that. simply exit with non-zero status. From phil at bolthole.com Fri Sep 11 20:11:08 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Sep 2009 11:11:08 -0700 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: On Sat, Sep 5, 2009 at 8:48 AM, Gary Law wrote: > Hi > > My latest puppet package is clashing with CSWapache2c over permissions > of /etc/opt > > a) what should the permissions be? The permissions are "none of your business" :-) neither you, nor CSWapache2c, should be setting permissions on /etc/opt itself. We do not "own" it. we do not have rights to set permissions on it. only /etc/opt/csw and below. From dam at opencsw.org Fri Sep 11 20:14:38 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 11 Sep 2009 20:14:38 +0200 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: Hi, Am 11.09.2009 um 20:11 schrieb Philip Brown: > On Sat, Sep 5, 2009 at 8:48 AM, Gary Law wrote: >> Hi >> >> My latest puppet package is clashing with CSWapache2c over >> permissions >> of /etc/opt >> >> a) what should the permissions be? > > The permissions are "none of your business" :-) > > neither you, nor CSWapache2c, should be setting permissions on > /etc/opt itself. We do not "own" it. we do not have rights to set > permissions on it. only /etc/opt/csw and below. Ok then, checkpkg could check that there are no pathes from CSWcommon in the package and no pathes "before them". Best regards -- Dago From phil at bolthole.com Fri Sep 11 20:22:57 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Sep 2009 11:22:57 -0700 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: On Fri, Sep 11, 2009 at 11:14 AM, Dagobert Michelsen wrote: > > > Ok then, checkpkg could check that there are no pathes from > CSWcommon in the package and no pathes "before them". it's kind of a pain to check for *ANY* path, considering the various permutations and "tricky stuff" people might do. there is currently a check for bare "/opt". that's the most common case. are you proposing checks for... "/opt /etc /etc/opt /var /var/opt" ? From dam at opencsw.org Fri Sep 11 20:37:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 11 Sep 2009 20:37:51 +0200 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: Hi Phil, Am 11.09.2009 um 20:22 schrieb Philip Brown: > On Fri, Sep 11, 2009 at 11:14 AM, Dagobert Michelsen > wrote: >> >> >> Ok then, checkpkg could check that there are no pathes from >> CSWcommon in the package and no pathes "before them". > > > it's kind of a pain to check for *ANY* path, considering the various > permutations and "tricky stuff" people might do. > > there is currently a check for bare "/opt". that's the most common > case. > are you proposing checks for... "/opt /etc /etc/opt /var /var/opt" ? Sure. Take all pathes in CSWcommon, generate every prefix path and check that there are none of them in there. And there must be a direct prefix of every file in the package in CSWcommon. Best regards -- Dago From phil at bolthole.com Fri Sep 11 22:59:08 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Sep 2009 13:59:08 -0700 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: On Fri, Sep 11, 2009 at 11:37 AM, Dagobert Michelsen wrote: > Hi Phil, > > Am 11.09.2009 um 20:22 schrieb Philip Brown: >> >> >> it's kind of a pain to check for *ANY* path, considering the various >> permutations and "tricky stuff" people might do. >> >> there is currently a check for bare "/opt". that's the most common case. >> are you proposing checks for... "/opt /etc /etc/opt /var /var/opt" ? > > Sure. Take all pathes in CSWcommon, generate every prefix path and check > that there are none of them in there. And there must be a direct prefix > of every file in the package in CSWcommon. > Errr.. that's not what I was saying at all. From schwindt at dfki.uni-kl.de Fri Sep 11 23:33:17 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Fri, 11 Sep 2009 23:33:17 +0200 (CEST) Subject: [csw-maintainers] libsmi in testiing Message-ID: <33062.88.134.82.77.1252704797.squirrel@www.dfki.uni-kl.de> This is 'A Library to Access SMI MIB Information' It will be needed for a new version of wireshark. Nicolai ----------------------------------------- This email was sent using SquirrelMail. "Webmail for nuts!" http://squirrelmail.org/ From trygvis at opencsw.org Sat Sep 12 07:33:26 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sat, 12 Sep 2009 07:33:26 +0200 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: <4AAB32A6.5060305@opencsw.org> Maciej (Matchek) Blizinski wrote: > After considering all the options, I wrote an example > implementation[1] of the one that does symlinks, and used it for the > unixodbc package. Trygvis had objected to putting it into testing, and > then disappeared in a black hole. I pulled the package from testing; > moved it into a subdirectory. Meanwhile, there is more and more > packages that are being held back by this issue, notably, there are > cups and tightvnc. Let's get it sorted out and move forward! > > The issue isn't entirely new, one might point out. There are packages > which already migrate their configuration files[2]. The case currently > discussed isn't as simple though, because it's a migration from a > single shared configuration instance into many per-zone configuration > instances. > > There is a number of options discussed on the wiki page[3]. I'd like > to ask if people have any other options to offer. > > There another case to consider: the case when the configuration files > can't be automatically migrated. Should the preinstall script abort > the installation? (Can it really abort the installation?) Any other > ideas? > > At the end of the discussion, I'd be happy if we had a canonical > implementation of the migration; possibly using a common script, put > into cswclassutils. > > Please respond to the mailing list, and I'll update the wiki page. As I see it there are actually two discussions going on here simultaneously: * Handling configuration files for zones and NFS environments For this point I think we need to find more examples to be able to figure out a reasonable policy. * The actual upgrade process and the physical moving of existing configuration files -- Trygve From bwalton at opencsw.org Sat Sep 12 16:01:53 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 12 Sep 2009 10:01:53 -0400 Subject: [csw-maintainers] gar default change... Message-ID: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> Hi All, I'd like to make a change to the GAR defaults that would see our recently agreed upon /opt/csw/{etc,var} -> /{etc,var}opt/csw become the norm. This would mean that any packages wanting to stay in their current locations would need to set sysconfdir, etc manually. If you're never intending to move your files these modifications would become permanent parts of your recipes. Is everyone ok with this? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Sat Sep 12 16:45:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 12 Sep 2009 16:45:49 +0200 Subject: [csw-maintainers] gar default change... In-Reply-To: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> References: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 12.09.2009 um 16:01 schrieb Ben Walton: > I'd like to make a change to the GAR defaults that would see our > recently agreed upon /opt/csw/{etc,var} -> /{etc,var}opt/csw become > the norm. This would mean that any packages wanting to stay in their > current locations would need to set sysconfdir, etc manually. If > you're never intending to move your files these modifications would > become permanent parts of your recipes. > > Is everyone ok with this? I propose something slightly different: The default of sysconfdir will be changed to /etc/opt/csw and localstatedir to /var/opt/csw. Additionally, every Makefile containing $(sysconfdir) or $(localstatedir) will get something like this in the head of the file in the same commit: # The default has been changed to /etc/opt/csw and /var/opt/csw. # Please remove the lines below after reviewing that your package still works. sysconfdir = /opt/csw/etc localstatedur = /opt/csw/var Best regards -- Dago From dam at opencsw.org Sat Sep 12 16:48:05 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 12 Sep 2009 16:48:05 +0200 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: Hi Phil, Am 11.09.2009 um 22:59 schrieb Philip Brown: > On Fri, Sep 11, 2009 at 11:37 AM, Dagobert Michelsen > wrote: >> Am 11.09.2009 um 20:22 schrieb Philip Brown: >>> it's kind of a pain to check for *ANY* path, considering the various >>> permutations and "tricky stuff" people might do. >>> >>> there is currently a check for bare "/opt". that's the most common >>> case. >>> are you proposing checks for... "/opt /etc /etc/opt /var /var/opt" ? >> >> Sure. Take all pathes in CSWcommon, generate every prefix path and >> check >> that there are none of them in there. And there must be a direct >> prefix >> of every file in the package in CSWcommon. > > Errr.. that's not what I was saying at all. What I said boils down to what you said, only that I would infer that from CSWcommon instead of hardcoding it. Best regards -- Dago From bwalton at opencsw.org Sat Sep 12 17:05:37 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 12 Sep 2009 11:05:37 -0400 Subject: [csw-maintainers] gar default change... In-Reply-To: References: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> Message-ID: <1252767797-sup-6541@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sat Sep 12 10:45:49 -0400 2009: Hi Dago, > /var/opt/csw. Additionally, every Makefile containing $(sysconfdir) > or $(localstatedir) will get something like this in the head of the > file in the same commit: > > # The default has been changed to /etc/opt/csw and /var/opt/csw. > # Please remove the lines below after reviewing that your package > # > still works. > sysconfdir = /opt/csw/etc > localstatedur = > # /opt/csw/var I like this. Do you mean every Makefile _not_ containing explicit settings for those variables though? This could potentially cause problems for packages that only override $(prefix) too... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From trygvis at opencsw.org Sat Sep 12 17:07:10 2009 From: trygvis at opencsw.org (=?UTF-8?B?VHJ5Z3ZlIExhdWdzdMO4bA==?=) Date: Sat, 12 Sep 2009 17:07:10 +0200 Subject: [csw-maintainers] gar default change... In-Reply-To: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> References: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> Message-ID: <4AABB91E.4090208@opencsw.org> Ben Walton wrote: > Hi All, > > I'd like to make a change to the GAR defaults that would see our > recently agreed upon /opt/csw/{etc,var} -> /{etc,var}opt/csw become > the norm. This would mean that any packages wanting to stay in their > current locations would need to set sysconfdir, etc manually. If > you're never intending to move your files these modifications would > become permanent parts of your recipes. > > Is everyone ok with this? +1 -- Trygve From william at wbonnet.net Sat Sep 12 23:25:51 2009 From: william at wbonnet.net (William Bonnet) Date: Sat, 12 Sep 2009 23:25:51 +0200 Subject: [csw-maintainers] [security-notice] Firefox 3.0.14 is available Message-ID: <4AAC11DF.6030600@wbonnet.net> Hi, Several vulnerabilities have been fixed by the latest version of Firefox 3.0 ( 3.0.14 ). This version is a security release, and will be in current in a version short time, and is right now available from testing. . http://mirror.opencsw.org/testing/firefox-3.0.14,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz . http://mirror.opencsw.org/testing/firefox-3.0.14,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz The list of fixed vulnerabilities is available from here : http://www.mozilla.org/security/known-vulnerabilities/firefox30.html Fixed in Firefox 3.0.14 MFSA 2009-51 Chrome privilege escalation with FeedWriter MFSA 2009-50 Location bar spoofing via tall line-height Unicode characters MFSA 2009-49 TreeColumns dangling pointer vulnerability MFSA 2009-48 Insufficient warning for PKCS11 module installation and removal MFSA 2009-47 Crashes with evidence of memory corruption (rv:1.9.1.3/1.9.0.14) cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From dam at opencsw.org Sun Sep 13 22:11:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 13 Sep 2009 22:11:17 +0200 Subject: [csw-maintainers] gar default change... In-Reply-To: <1252767797-sup-6541@ntdws12.chass.utoronto.ca> References: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> <1252767797-sup-6541@ntdws12.chass.utoronto.ca> Message-ID: <60DF8571-9660-4975-AD7C-8D9F13F8C46B@opencsw.org> Hi Ben, Am 12.09.2009 um 17:05 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Sat Sep 12 10:45:49 > -0400 2009: > > Hi Dago, > >> /var/opt/csw. Additionally, every Makefile containing $(sysconfdir) >> or $(localstatedir) will get something like this in the head of the >> file in the same commit: >> >> # The default has been changed to /etc/opt/csw and /var/opt/csw. >> # Please remove the lines below after reviewing that your package >> # > still works. > sysconfdir = /opt/csw/etc > localstatedur = >> # /opt/csw/var > > I like this. Do you mean every Makefile _not_ containing explicit > settings for those variables though? This could potentially cause > problems for packages that only override $(prefix) too... Ok, so it would be safest to add the header and existing default to *every* Makefile to ensure the issue has been looked at when the package is next reviewed. Better safe and remove some lines then get strange effects after release. Thoughts? Best regards -- Dago From dam at opencsw.org Sun Sep 13 22:16:47 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 13 Sep 2009 22:16:47 +0200 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: Hi Phil, Am 11.09.2009 um 18:22 schrieb Philip Brown: > On Thu, Sep 10, 2009 at 11:41 AM, Maciej (Matchek) Blizinski > wrote: >> >> There another case to consider: the case when the configuration files >> can't be automatically migrated. Should the preinstall script abort >> the installation? (Can it really abort the installation?) Any other >> ideas? > > I did already give my own opinion on this one; yes it should stop the > install. and yes it has the power to do that. simply exit with > non-zero status. Let me remind you that this is contrary to what you advised me on transitioning Mantis: Am 21.03.2008 um 22:08 schrieb Philip Brown: > On Fri, Mar 21, 2008 at 09:56:16PM +0100, Dagobert Michelsen wrote: >> No. If someone has a modified config-file I'll need to take >> care of it or the symlink in htdocs could not be created. >> This must be tested and this all takes some time. >> >> If you say I should just move the stuff over I'll it right >> now, but this is not a smooth transitions for users. > > yeah. just move it over. > > it would be nice if you just had a quicky postinstall check for, > "was there an older install? if so, post a warning message for 30 sec" > but that's about it. > It's too messy otherwise. And I think it was the right thing you advised me: Make the transition automatic if possible and stop if it can't be migrated safely. Best regards -- Dago From trygvis at opencsw.org Sun Sep 13 22:24:56 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 13 Sep 2009 22:24:56 +0200 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: <4AAD5518.1080708@opencsw.org> Dagobert Michelsen wrote: > Hi Phil, > > Am 11.09.2009 um 18:22 schrieb Philip Brown: >> On Thu, Sep 10, 2009 at 11:41 AM, Maciej (Matchek) Blizinski >> wrote: >>> >>> There another case to consider: the case when the configuration files >>> can't be automatically migrated. Should the preinstall script abort >>> the installation? (Can it really abort the installation?) Any other >>> ideas? >> >> I did already give my own opinion on this one; yes it should stop the >> install. and yes it has the power to do that. simply exit with >> non-zero status. > > Let me remind you that this is contrary to what you advised me on > transitioning Mantis: > > Am 21.03.2008 um 22:08 schrieb Philip Brown: >> On Fri, Mar 21, 2008 at 09:56:16PM +0100, Dagobert Michelsen wrote: >>> No. If someone has a modified config-file I'll need to take >>> care of it or the symlink in htdocs could not be created. >>> This must be tested and this all takes some time. >>> >>> If you say I should just move the stuff over I'll it right >>> now, but this is not a smooth transitions for users. >> >> yeah. just move it over. >> >> it would be nice if you just had a quicky postinstall check for, >> "was there an older install? if so, post a warning message for 30 sec" >> but that's about it. >> It's too messy otherwise. > > And I think it was the right thing you advised me: Make the transition > automatic if possible and stop if it can't be migrated safely. If it is obvious where it was and where it should be moved to (like mpd's mpd.conf file), just move it. Otherwise just fail. -- Trygve From trygvis at opencsw.org Mon Sep 14 14:12:01 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Mon, 14 Sep 2009 14:12:01 +0200 Subject: [csw-maintainers] OpenCSW summer camp: What were your impressions? Brainstorming for further camps. In-Reply-To: <4A999C1B.9010506@opencsw.org> References: <4A999C1B.9010506@opencsw.org> Message-ID: <4AAE3311.5040601@opencsw.org> Sebastian Kayser wrote: > Hi, > > thanks again to Ihsan for dealing with organizational stuff and Trygve > for setting us up with the gorgeous venue above Olso. "After the game, > is before the game" (as the saying goes in soccer), hence i would like > to capture some of the impressions that you took away from Oslo while > they are still fresh so that we know what to take care of for further > meetings. > > - How would you sum up the weekend and what you took away from it? > > - What would you like to see again? > > - What would you have wished to be different? How? > > - Any other ideas that don't fit into the two above? Stuff that we > should try next time? I liked it that we just sat until we got hungry and everyone was fed up with hacking. It makes it kinda harder to prepare a place up front, but if you don't go for anything very fancy it was quite easy to find a decent place to eat at. Being able to bring a laptop or at least notes is probably nice as not everyone feel like getting drunk and would like to continue to talk/work throughout the evening. -- Trygve From schwindt at dfki.uni-kl.de Mon Sep 14 15:12:45 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 14 Sep 2009 15:12:45 +0200 Subject: [csw-maintainers] Transmission 1.75 in testing Message-ID: <200909141312.n8EDCj8H021207@dfki.uni-kl.de> I put Transmission 1.75 into testing. Transmission is a cross-platform BitTorrent client Nicolai From william at wbonnet.net Mon Sep 14 16:07:58 2009 From: william at wbonnet.net (William Bonnet) Date: Mon, 14 Sep 2009 16:07:58 +0200 Subject: [csw-maintainers] /testing Seamonkey 1.1.18 is available Message-ID: <4AAE4E3E.2060703@wbonnet.net> Hi Seamonkey 1.1.18 is available from testing for Solaris 8+ http://mirror.opencsw.org/testing/seamonkey-1.1.18,REV=2009.09.14-SunOS5.8-i386-CSW.pkg.gz http://mirror.opencsw.org/testing/seamonkey-1.1.18,REV=2009.09.14-SunOS5.8-sparc-CSW.pkg.gz Feedbacks are welcome since it is my first version of the package. This package will be updated with the rest of the Mozilla's applications. cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From daniel at opencsw.org Mon Sep 14 17:49:50 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Mon, 14 Sep 2009 16:49:50 +0100 Subject: [csw-maintainers] Release of updated cairo In-Reply-To: References: <4AA522F3.6070903@pocock.com.au> <9D68CA91-DBC1-4756-B90F-007E2122F831@opencsw.org> <4AA56225.1050307@pocock.com.au> <6130367B-C3FE-49B3-81B0-B3850DBAC572@opencsw.org> <4AAA1B8B.7030700@pocock.com.au> <60378F51-D464-46B7-8A85-16B771E6D104@opencsw.org> <4AAA1F2F.30806@pocock.com.au> Message-ID: <4AAE661E.4000000@opencsw.org> Dagobert Michelsen wrote: > Hi, > > Am 11.09.2009 um 11:58 schrieb Daniel Pocock: >> Dagobert Michelsen wrote: >>> Hi Daniel, >>> >>> Am 11.09.2009 um 11:42 schrieb Daniel Pocock: >>>> I also need the rrdtool package on all the build machines so I can >>>> build my packages. >>> >>> ?? rrdtool is already on all build machines, or are you missing >>> something? >> >> Actually, you are right - rrd.h is there, it is the cairo issue > > John: How about releasing the updated cairo from testing? > I haven't seen any problems with the new cairo package on my test machine running the Ganglia packages. Is there any further work to do to get the new cairo package out of testing, and is it something I could assist with? From phil at bolthole.com Mon Sep 14 19:20:01 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Sep 2009 10:20:01 -0700 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: On Sun, Sep 13, 2009 at 1:16 PM, Dagobert Michelsen wrote: > Hi Phil, >.... > > Let me remind you that this is contrary to what you advised me on > transitioning Mantis: >... and this is why I am AGAINST having a strict policy on the issue of transitioning etc files, but believe that each package should be carefully considered on its own merits :-) It's a potentially very sticky issue. I do not think people should do it casually. I think that having a deep "policy" on this issue, would discorage people from actually THINKING about what is best for their package. This would be the opposite of best practice, in my opinion. I think that "the policy" should not be much more than, "keep local configs in /etc/opt/csw, and local state in /var/opt/csw", and leave the "how to get there" mostly to the maintainer. From dam at opencsw.org Mon Sep 14 20:29:40 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 14 Sep 2009 20:29:40 +0200 Subject: [csw-maintainers] Release of updated cairo In-Reply-To: <4AAE661E.4000000@opencsw.org> References: <4AA522F3.6070903@pocock.com.au> <9D68CA91-DBC1-4756-B90F-007E2122F831@opencsw.org> <4AA56225.1050307@pocock.com.au> <6130367B-C3FE-49B3-81B0-B3850DBAC572@opencsw.org> <4AAA1B8B.7030700@pocock.com.au> <60378F51-D464-46B7-8A85-16B771E6D104@opencsw.org> <4AAA1F2F.30806@pocock.com.au> <4AAE661E.4000000@opencsw.org> Message-ID: <89247C5F-4220-4E69-B6B9-26959592B7F6@opencsw.org> Hi Daniel, Am 14.09.2009 um 17:49 schrieb Daniel Pocock: > Dagobert Michelsen wrote: >> Hi, >> Am 11.09.2009 um 11:58 schrieb Daniel Pocock: >>> Dagobert Michelsen wrote: >>>> Hi Daniel, >>>> >>>> Am 11.09.2009 um 11:42 schrieb Daniel Pocock: >>>>> I also need the rrdtool package on all the build machines so I >>>>> can build my packages. >>>> >>>> ?? rrdtool is already on all build machines, or are you missing >>>> something? >>> >>> Actually, you are right - rrd.h is there, it is the cairo issue >> John: How about releasing the updated cairo from testing? > > I haven't seen any problems with the new cairo package on my test > machine running the Ganglia packages. > > Is there any further work to do to get the new cairo package out of > testing, and is it something I could assist with? Yes, you need to copy them over from 'login' to www.opencsw.org:/home/newpkgs and write an email to phil@ with "newpkgs" in the subject stating what should be released and what has changed. Best regards -- Dago From phil at bolthole.com Mon Sep 14 21:16:44 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Sep 2009 12:16:44 -0700 Subject: [csw-maintainers] Release of updated cairo In-Reply-To: <89247C5F-4220-4E69-B6B9-26959592B7F6@opencsw.org> References: <4AA522F3.6070903@pocock.com.au> <9D68CA91-DBC1-4756-B90F-007E2122F831@opencsw.org> <4AA56225.1050307@pocock.com.au> <6130367B-C3FE-49B3-81B0-B3850DBAC572@opencsw.org> <4AAA1B8B.7030700@pocock.com.au> <60378F51-D464-46B7-8A85-16B771E6D104@opencsw.org> <4AAA1F2F.30806@pocock.com.au> <4AAE661E.4000000@opencsw.org> <89247C5F-4220-4E69-B6B9-26959592B7F6@opencsw.org> Message-ID: On Mon, Sep 14, 2009 at 11:29 AM, Dagobert Michelsen wrote: > > Yes, you need to copy them over from 'login' to > ?www.opencsw.org:/home/newpkgs > and write an email to phil@ with "newpkgs" in the subject stating what > should be > released and what has changed. > > erm.... thats sligthly overkill. It is helpful to know which packages are "brand new", vs "upgrades to prior ones". Also, if anything MAJOR has changed, it's useful to let me know. But it isnt neccessary to email me a changelog or anything :-) From daniel at opencsw.org Mon Sep 14 21:33:16 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Mon, 14 Sep 2009 20:33:16 +0100 Subject: [csw-maintainers] newpks Re: Release of updated cairo In-Reply-To: References: <4AA522F3.6070903@pocock.com.au> <9D68CA91-DBC1-4756-B90F-007E2122F831@opencsw.org> <4AA56225.1050307@pocock.com.au> <6130367B-C3FE-49B3-81B0-B3850DBAC572@opencsw.org> <4AAA1B8B.7030700@pocock.com.au> <60378F51-D464-46B7-8A85-16B771E6D104@opencsw.org> <4AAA1F2F.30806@pocock.com.au> <4AAE661E.4000000@opencsw.org> <89247C5F-4220-4E69-B6B9-26959592B7F6@opencsw.org> Message-ID: <4AAE9A7C.5020309@opencsw.org> Philip Brown wrote: > On Mon, Sep 14, 2009 at 11:29 AM, Dagobert Michelsen wrote: >> Yes, you need to copy them over from 'login' to >> www.opencsw.org:/home/newpkgs >> and write an email to phil@ with "newpkgs" in the subject stating what >> should be >> released and what has changed. >> >> > > erm.... thats sligthly overkill. It is helpful to know which packages > are "brand new", vs "upgrades to prior ones". > > Also, if anything MAJOR has changed, it's useful to let me know. But > it isnt neccessary to email me a changelog or anything :-) This appears to be a minor upgrade from 1.8.6 to 1.8.8 It appears to resolve issues when linking with rrdtool, therefore, even though I don't maintain the libcairo package, I am putting it in newpkgs so people can use rrdtool again Phil, please let Dago know when it is ready so he can put it on the build farm and I can build the Ganglia packages. daniel at login [login]:/home/testing > ls -l libcai* -rw-r--r-- 1 ellson csw 496243 Aug 4 20:45 libcairo-1.8.8,REV=2009.08.04-SunOS5.8-i386-CSW.pkg.gz -rw-r--r-- 1 ellson csw 620887 Aug 4 20:45 libcairo-1.8.8,REV=2009.08.04-SunOS5.8-sparc-CSW.pkg.gz -rw-r--r-- 1 ellson csw 26668 Aug 4 20:45 libcairo_devel-1.8.8,REV=2009.08.04-SunOS5.8-i386-CSW.pkg.gz -rw-r--r-- 1 ellson csw 26540 Aug 4 20:45 libcairo_devel-1.8.8,REV=2009.08.04-SunOS5.8-sparc-CSW.pkg.gz -rw-r--r-- 1 ellson csw 149356 Aug 4 20:45 libcairo_doc-1.8.8,REV=2009.08.04-SunOS5.8-all-CSW.pkg.gz daniel at login [login]:/home/testing > scp libcai* www.opencsw.org:/home/newpkgs/ libcairo-1.8.8,REV=2 100% |*****************************| 484 KB 00:00 libcairo-1.8.8,REV=2 100% |*****************************| 606 KB 00:00 libcairo_devel-1.8.8 100% |*****************************| 26668 00:00 libcairo_devel-1.8.8 100% |*****************************| 26540 00:00 libcairo_doc-1.8.8,R 100% |*****************************| 145 KB 00:00 From maciej at opencsw.org Mon Sep 14 21:37:10 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 14 Sep 2009 20:37:10 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: <4AAB32A6.5060305@opencsw.org> References: <4A939902.3050808@opencsw.org> <4AAB32A6.5060305@opencsw.org> Message-ID: 2009/9/12 Trygve Laugst?l : > As I see it there are actually two discussions going on here simultaneously: > > * Handling configuration files for zones and NFS environments > > For this point I think we need to find more examples to be able to figure > out a reasonable policy. > > * The actual upgrade process and the physical moving of existing > configuration files If you want to split it up, I'd suggest three discussions: 1. What should be the guidelines for configuration files for environments with shared/read-only /opt.[1] 2. The actual migration process which does not involve shared/read-only /opt ("just move it" works) 3. The actual migration process involving shared/read-only /opt. ("just move it" does not work) I'm mostly concerned with the discussion number 3, as it's blocking my work with three pieces of software (cups, unixodbc and tightvnc). Trygve, since you objected to putting my sample implementation into testing, can you comment on the suggested solutions or suggest one of your own? Maciej [1] Phil suggests: http://lists.opencsw.org/pipermail/maintainers/2009-September/004144.html From bwalton at opencsw.org Tue Sep 15 01:44:11 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 14 Sep 2009 19:44:11 -0400 Subject: [csw-maintainers] CSWcommon update request Message-ID: <1252971767-sup-7257@ntdws12.chass.utoronto.ca> Hi Phil, Please add the following directories to CSWcommon: /etc/opt/csw/pkg-hooks/prebatchinstall.d/ /etc/opt/csw/pkg-hooks/postbatchinstall.d/ /etc/opt/csw/pkg-hooks/prebatchupgrade.d/ /etc/opt/csw/pkg-hooks/postbatchupgrade.d/ /etc/opt/csw/pkg-hooks/prebatchremove.d/ /etc/opt/csw/pkg-hooks/postbatchremove.d/ /etc/opt/csw/pkg-hooks/preinstall.d/ /etc/opt/csw/pkg-hooks/postinstall.d/ /etc/opt/csw/pkg-hooks/preupgrade.d/ /etc/opt/csw/pkg-hooks/postupgrade.d/ /etc/opt/csw/pkg-hooks/preremove.d/ /etc/opt/csw/pkg-hooks/postremove.d/ /var/opt/csw/pkg-hooks Hooks are implemented in pkgutil 1.7, and I'll soon start releasing packages that use them. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Tue Sep 15 02:13:38 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Sep 2009 17:13:38 -0700 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: On Sat, Sep 12, 2009 at 7:48 AM, Dagobert Michelsen wrote: > >> >> Errr.. that's not what I was saying at all. > > What I said boils down to what you said, only that I would infer that > from CSWcommon instead of hardcoding it. > > no. i was only saying, "check for, and warn about, any paths in a package that are not under /opt/csw, or /etc/opt/csw, or /var/opt/etc". You are saying, "AND in addition, check for any paths that are in CSWcommon, and gripe about that". I think that's going too far. If a package wants to declare some of the same directories/perms as what is in CSWcommon, it's a little redundant, but it's not "wrong". From dam at opencsw.org Tue Sep 15 10:14:25 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Sep 2009 10:14:25 +0200 Subject: [csw-maintainers] Release of updated cairo In-Reply-To: <89247C5F-4220-4E69-B6B9-26959592B7F6@opencsw.org> References: <4AA522F3.6070903@pocock.com.au> <9D68CA91-DBC1-4756-B90F-007E2122F831@opencsw.org> <4AA56225.1050307@pocock.com.au> <6130367B-C3FE-49B3-81B0-B3850DBAC572@opencsw.org> <4AAA1B8B.7030700@pocock.com.au> <60378F51-D464-46B7-8A85-16B771E6D104@opencsw.org> <4AAA1F2F.30806@pocock.com.au> <4AAE661E.4000000@opencsw.org> <89247C5F-4220-4E69-B6B9-26959592B7F6@opencsw.org> Message-ID: <4C245342-60D8-4BA6-BD8E-F31E089C6727@opencsw.org> Hi, Am 14.09.2009 um 20:29 schrieb Dagobert Michelsen: > Am 14.09.2009 um 17:49 schrieb Daniel Pocock: >> I haven't seen any problems with the new cairo package on my test >> machine running the Ganglia packages. >> Is there any further work to do to get the new cairo package out of >> testing, and is it something I could assist with? > > Yes, you need to copy them over from 'login' to > www.opencsw.org:/home/newpkgs > and write an email to phil@ with "newpkgs" in the subject stating > what should be > released and what has changed. The updated libcairo has been installed on all buildfarm servers. Now work can proceed with Ganglia and Graphviz :-) Best regards -- Dago From trygvis at opencsw.org Tue Sep 15 10:40:18 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 15 Sep 2009 10:40:18 +0200 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: <4AAF52F2.4060804@opencsw.org> Philip Brown wrote: > On Sun, Sep 13, 2009 at 1:16 PM, Dagobert Michelsen wrote: >> Hi Phil, >> .... >> >> Let me remind you that this is contrary to what you advised me on >> transitioning Mantis: >> ... > > and this is why I am AGAINST having a strict policy on the issue of > transitioning etc files, but believe that each package should be > carefully considered on its own merits :-) > > It's a potentially very sticky issue. I do not think people should do > it casually. I think that having a deep "policy" on this issue, would > discorage people from actually THINKING about what is best for their > package. This would be the opposite of best practice, in my opinion. I think it is very important to have a policy on how it is supposed to be. If not people will INVENT their own methods and we will have no CONSISTENCY leading to OpenCSW packages being hard to use. I agree that you can't and shouldn't make a policy that goes into every detail, but having guidelines explaining why we do thing this way is a good thing. It is very confusing for new maintainers to figure out where stuff is supposed to go. By having a set of reason it is easier to understand why it is supposed to be that way and to make your own choices when that is required. > I think that "the policy" should not be much more than, "keep local > configs in /etc/opt/csw, and local state in /var/opt/csw", and leave > the "how to get there" mostly to the maintainer. A policy definitely needs to mention when it is correct to use /opt/csw/etc vs /etc/opt/csw. -- Trygve From phil at bolthole.com Tue Sep 15 18:27:34 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Sep 2009 09:27:34 -0700 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: <4AAF52F2.4060804@opencsw.org> References: <4A939902.3050808@opencsw.org> <4AAF52F2.4060804@opencsw.org> Message-ID: 2009/9/15 Trygve Laugst?l : > Philip Brown wrote: >> >> It's a potentially very sticky issue. I do not think people should do >> it casually. I think that having a deep "policy" on this issue, would >> discorage people from actually THINKING about what is best for their >> package. This would be the opposite of best practice, in my opinion. > > I think it is very important to have a policy on how it is supposed to be. > If not people will INVENT their own methods and we will have no CONSISTENCY > leading to OpenCSW packages being hard to use. > rather than call that part "policy", I would rather say we should have a set of recommendations, and offer tools, so that maintainers can re-use solutions, rather than have to invent their own. Sometimes, they will HAVE to. but for most people, if you offer them a tool that works, they will use it by their own preference. > A policy definitely needs to mention when it is correct to use /opt/csw/etc > vs /etc/opt/csw. true enough. and I thought we had a writeup of that already. .... we do. http://www.opencsw.org/standards/layout Subdirectories of /opt/csw ... etc Global Configuration files. (Machine-local conf files should go in /etc/opt/csw/[softwarename] or /etc/opt/csw) Seems to be explicit, and clear. From maciej at opencsw.org Tue Sep 15 20:11:52 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Sep 2009 19:11:52 +0100 Subject: [csw-maintainers] CUPS issues Message-ID: There's an issue with cups-polld that I've been investigating for some time now. When I attempted to reproduce it under a debugger, another bug surfaced, I'm just about to file a bug report with CUPS developers. After implementing a workaround against the second bug, the original issue doesn't show up at all. I'm suspecting that it's something dependent on the optimization level. To summarize: with -xO2 bug1 is triggered, but bug2 is not with -xO0 bug1 is not triggered, but bug2 is. Since bug2 seems to be relatively easy to fix, I got working binaries by compiling cups with -xO0 and thus hiding bug1. The dilemma is as follows: - optimized binaries work for most people but fail miserably in my production environment - unoptimized binaries work fine in my environment, but I feel it's wrong to ship unoptimized binaries from OpenCSW I'm stuck here. I can't debug it. I can't ship it. Help! Maciej P.S. I'll do more testing, perhaps I'll be able to reproduce bug1, but I haven't been so far. From maciej at opencsw.org Tue Sep 15 20:14:17 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Sep 2009 19:14:17 +0100 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: Message-ID: On Fri, Sep 11, 2009 at 5:04 PM, Philip Brown wrote: > well,, there are multiple potential "issues" at play here. > on the one hand, I understand your frustration at not having it > normally in the path. > But what would be the side effects of having a symlink > /opt/csw/bin/mysql -> /opt/csw/mysql5/bin/mysql ? I was thinking about this... what if someone has mysql4 also installed? Perhaps some sort of "switch" app, which would change the symlinks, would be good. I need to think about it some more. > Would it break auto-detection of mysql location, when compiling? It depends on how is the autodetection done (if at all ;-) ), I'd give symlinks a shot and see if there is any yelling from the users. > It may indeed be appropriate to adjust our mysql5 package to have the > symlink in there. > > BTW: would you be intersted in taking over our mysql package, for > purposes of updating, and putting the symlink in there? > (pleasepleasepleaseplease? :-) :-) I've already done some work towards this end, but I was recently shaving a yak. I should have something to show within a week or two. I don't use MySQL on Solaris myself, I'm not sure if I'm the best candidate for a long-term MySQL maintainer, but I can at least, for the fun of it, bring the build to the form in which it works and can be easily handed off to another person. Maciej From phil at bolthole.com Tue Sep 15 20:49:17 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Sep 2009 11:49:17 -0700 Subject: [csw-maintainers] article on opensolaris vs linux Message-ID: interesting article on opensolaris vs linux. Some of the comments on the article are actually useful, too. I learned a thing or two. http://www.tuxradar.com/content/opensolaris-vs-linux From phil at bolthole.com Tue Sep 15 20:53:06 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Sep 2009 11:53:06 -0700 Subject: [csw-maintainers] CUPS issues In-Reply-To: References: Message-ID: On Tue, Sep 15, 2009 at 11:11 AM, Maciej (Matchek) Blizinski wrote: > > > To summarize: > > with -xO2 bug1 is triggered, but bug2 is not > with -xO0 bug1 is not triggered, but bug2 is. > > Since bug2 seems to be relatively easy to fix, I got working binaries > by compiling cups with -xO0 and thus hiding bug1. owch. Please remember that, odds are, its only ONE FILE, that needs to be compiled this way. If you feel masochistic,you might try substituting files around to see which ones are critical. Then again... do you REAAALLY need optimized cups? :-) oh, btw; you are concerned about a specific demon, not the library (yes?), you also certainly have the option of compiling with gcc without it affecting anything else(?). Although you might also use older/newer version of sun compiler as alternative, too! From daniel at opencsw.org Tue Sep 15 22:40:19 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Tue, 15 Sep 2009 21:40:19 +0100 Subject: [csw-maintainers] dependency issue while checking packages Message-ID: <4AAFFBB3.7000106@opencsw.org> My ganglia Makefile generates a number of packages: PACKAGES = CSWgangliart CSWgangliaagent CSWgangliadevel CSWgangliagmetad CSWgangliaweb CSWgangliamodpython When I run gmake package it builds CSWgangliaagent, and then complains because CSWgangliart doesn't exist or is not installed When I build on my own machine (Solaris 10 x86 + current + Sun Studio 12) I am able to build all the packages successfully without this error. On build8s, however, only the ganglia_agent package file is generated and the build goes no further: Examining 'depend' file P CSWcswclassutils cswclassutils - CSW class action utilities P CSWexpat expat - XML Parser Toolkit P CSWlibconfuse libconfuse - a configuration file parser library P CSWapache2rt apache2rt - A high performance Unix-based HTTP server. P CSWgangliart ganglia_rt - Ganglia runtime libraries P CSWcommon common - common files and dirs for CSW packages application CSWapache2rt apache2rt - A high performance Unix-based HTTP server. system CSWcommon common - common files and dirs for CSW packages application CSWcswclassutils cswclassutils - CSW class action utilities application CSWexpat expat - XML Parser Toolkit ERROR: information for "CSWgangliart" was not found ERROR: Invalid package CSWgangliart specified. Check of /tmp/ganglia_agent-3.1.3,REV=2009.09.15-SunOS5.8-sparc-UNCOMMITTED.pkg.gz fails gmake: *** [pkgcheck-CSWgangliaagent] Error 2 bash-2.03$ ls ~/staging/build-15.Sep.2009/ ganglia_agent-3.1.3,REV=2009.09.15-SunOS5.8-sparc-UNCOMMITTED.pkg.gz From skayser at opencsw.org Tue Sep 15 23:27:27 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 15 Sep 2009 23:27:27 +0200 Subject: [csw-maintainers] Solaris 8&9: No header file for (get|set|end)usershell, but libc provides it? Message-ID: <4AB006BF.1000302@opencsw.org> Hi, does anyone know why there would be no include files with function declarations for the (get|set|end)usershell functions on Solaris 8 & 9, although the functions are documented and provided by libc? I have an application that tries to build with -errwarn and bails out with implicit function declaration warnings. On both build8s and build9s the situation is about the same $ apropos usershell endusershell getusershell (3c) - get legal user shells getusershell getusershell (3c) - get legal user shells setusershell getusershell (3c) - get legal user shells $ ggrep -Er '(get|set|end)usershell' /usr/include/ $ $ nm -p /usr/lib/libc.so | ggrep -Er '(get|set|end)usershell' 0000247760 T endusershell 0000247684 T getusershell 0000000000 f getusershell.c 0000247860 T setusershell build10s does have the function declaration in unistd.h $ ggrep -Er '(get|set|end)usershell' /usr/include/ /usr/include/unistd.h:extern void endusershell(void); /usr/include/unistd.h:extern char *getusershell(void); /usr/include/unistd.h:extern void setusershell(void); /usr/include/unistd.h:extern void endusershell(); /usr/include/unistd.h:extern char *getusershell(); /usr/include/unistd.h:extern void setusershell(); What i noticed so far is that the man page for the affected libc calls (in contrast to others) does not mention an include file on Solaris 8 & 9 ... never seen this before. Sebastian From phil at bolthole.com Tue Sep 15 23:36:25 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Sep 2009 14:36:25 -0700 Subject: [csw-maintainers] Solaris 8&9: No header file for (get|set|end)usershell, but libc provides it? In-Reply-To: <4AB006BF.1000302@opencsw.org> References: <4AB006BF.1000302@opencsw.org> Message-ID: It happens sometimes. just fake your own extern.h file if you must, or something like that. On Tue, Sep 15, 2009 at 2:27 PM, Sebastian Kayser wrote: > Hi, > > does anyone know why there would be no include files with function > declarations for the (get|set|end)usershell functions on Solaris 8 & 9, > although the functions are documented and provided by libc? > From maciej at opencsw.org Wed Sep 16 00:30:24 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Sep 2009 23:30:24 +0100 Subject: [csw-maintainers] dependency issue while checking packages In-Reply-To: <4AAFFBB3.7000106@opencsw.org> References: <4AAFFBB3.7000106@opencsw.org> Message-ID: On Tue, Sep 15, 2009 at 9:40 PM, Daniel Pocock wrote: > > > > My ganglia Makefile generates a number of packages: > > PACKAGES = CSWgangliart CSWgangliaagent CSWgangliadevel CSWgangliagmetad > CSWgangliaweb CSWgangliamodpython > > When I run > > gmake package > > it builds CSWgangliaagent, and then complains because CSWgangliart doesn't > exist or is not installed A workaround: ENABLE_CHECK=0 gmake package There's going to be a fix, but I don't think it has been released yet. Maciej From daniel at opencsw.org Wed Sep 16 01:23:34 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 16 Sep 2009 00:23:34 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing Message-ID: <4AB021F6.3050505@opencsw.org> Thanks for all the assistance and feedback about the CSW packaging process I've finally got the unofficial 3.1.3 code into testing now - feedback is welcome Please note the following about versions: 3.1.2 is the latest official release - this builds successfully on Solaris 10 with Sun Studio 12, no patching required - it doesn't build successfully on Sun Studio 11 or Solaris 8 (multiple issues) 3.1.3 is not yet in the RC stage, but very close to it - I have used the code from the monitor-core-3.1 branch upstream, and built a sample 3.1.3 package which is now in OpenCSW testing. During this process, I identified one further change that is required to support Sun Studio 11, otherwise, it seems to be good for Solaris 8 and above, Sun Studio 11 or 12. For a bare minimum install: - put ganglia_agent on all machines to be monitored - put ganglia_web on the machine which is meant to be the monitoring server - restart Apache on the monitoring server - browse to http:///ganglia/ The agent interoperates smoothly with the Linux agent on the same network. Any feedback is welcome - if anyone has configuration/deployment questions outside the scope of OpenCSW, please feel free to email me personally or use the Ganglia discussion lists. From skayser at opencsw.org Wed Sep 16 17:48:22 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 16 Sep 2009 17:48:22 +0200 (CEST) Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB021F6.3050505@opencsw.org> References: <4AB021F6.3050505@opencsw.org> Message-ID: <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> Hi Daniel, Daniel Pocock wrote: > Thanks for all the assistance and feedback about the CSW packaging process > > I've finally got the unofficial 3.1.3 code into testing now - feedback > is welcome your packages have the UNCOMMITED status (see their file names), which means that you had uncommitted local changes when building the package. UNCOMITTED packages won't be considered for the testing catalog. Issue 'svn status' to see which files are still uncomitted, take care of them (commit or branch if necessary), rebuild the packages and replace the current ones in /home/testing. Thanks Sebastian From bwalton at opencsw.org Wed Sep 16 17:55:02 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 16 Sep 2009 11:55:02 -0400 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> Message-ID: <1253116461-sup-7722@ntdws12.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Wed Sep 16 11:48:22 -0400 2009: > Issue 'svn status' to see which files are still uncomitted, take care of > them (commit or branch if necessary), rebuild the packages and replace the > current ones in /home/testing. If you still have the build/install files in work/, you can commit the changes and simply issue `gmake repackage` without having to do the build, test, etc steps. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From daniel at opencsw.org Wed Sep 16 17:55:57 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 16 Sep 2009 16:55:57 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> Message-ID: <4AB10A8D.2040504@opencsw.org> Sebastian Kayser wrote: > Hi Daniel, > > Daniel Pocock wrote: > > Thanks for all the assistance and feedback about the CSW packaging > process > > > > I've finally got the unofficial 3.1.3 code into testing now - feedback > > is welcome > > your packages have the UNCOMMITED status (see their file names), which > means that you had uncommitted local changes when building the package. > UNCOMITTED packages won't be considered for the testing catalog. > > Issue 'svn status' to see which files are still uncomitted, take care of > them (commit or branch if necessary), rebuild the packages and replace the > current ones in /home/testing. That is because I don't want to commit the checksum for ganglia-3.1.3.tar.gz as it is not an official release There are a couple of Makefile changes that are safe to commit though. I'm planning to tag 3.1.3 upstream on Friday, but I would like to get feedback from OpenCSW users before I do that. From maciej at opencsw.org Wed Sep 16 17:58:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 16 Sep 2009 16:58:30 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB10A8D.2040504@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> Message-ID: On Wed, Sep 16, 2009 at 4:55 PM, Daniel Pocock wrote: > Sebastian Kayser wrote: >> >> Hi Daniel, >> >> Daniel Pocock wrote: >> > Thanks for all the assistance and feedback about the CSW packaging >> > process >> > >> > I've finally got the unofficial 3.1.3 code into testing now - feedback >> > is welcome >> >> your packages have the UNCOMMITED status (see their file names), which >> means that you had uncommitted local changes when building the package. >> UNCOMITTED packages won't be considered for the testing catalog. >> >> Issue 'svn status' to see which files are still uncomitted, take care of >> them (commit or branch if necessary), rebuild the packages and replace the >> current ones in /home/testing. > > That is because I don't want to commit the checksum for ganglia-3.1.3.tar.gz > as it is not an official release I'd suggest creating a branch, and committing your code there. Maciej From skayser at opencsw.org Wed Sep 16 18:15:33 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 16 Sep 2009 18:15:33 +0200 (CEST) Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB10A8D.2040504@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> Message-ID: <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> Daniel Pocock schrieb: > Sebastian Kayser wrote: >> Daniel Pocock wrote: >> > Thanks for all the assistance and feedback about the CSW packaging >> process >> > >> > I've finally got the unofficial 3.1.3 code into testing now - feedback >> > is welcome >> >> your packages have the UNCOMMITED status (see their file names), which >> means that you had uncommitted local changes when building the package. >> UNCOMITTED packages won't be considered for the testing catalog. >> >> Issue 'svn status' to see which files are still uncomitted, take care of >> them (commit or branch if necessary), rebuild the packages and replace >> the >> current ones in /home/testing. > > That is because I don't want to commit the checksum for > ganglia-3.1.3.tar.gz as it is not an official release > > There are a couple of Makefile changes that are safe to commit though. > I'm planning to tag 3.1.3 upstream on Friday, but I would like to get > feedback from OpenCSW users before I do that. You could simply create a branch to work on the upcoming release. ~/mgar/pkg/ganglia$ svn cp trunk/ branches/ganglia-3.1.3-rc Then continue your work there, commit the changes and you will get packages without the UNCOMMITTED status. The point being: packages with the UNCOMITTED status (as your current ones) are skipped by the script that builds the testing catalog, i.e. pkg-get / pkgutil will NOT see them (although they are happily stored in /home/testing). Sebastian P.S.: No need to CC me, i am on the list. From bwalton at opencsw.org Wed Sep 16 18:37:22 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 16 Sep 2009 12:37:22 -0400 Subject: [csw-maintainers] interdependent packages moving to /etc/opt/csw Message-ID: <1253118865-sup-4588@ntdws12.chass.utoronto.ca> Hi All, I've got a large stack of interdependent packages that will be all changing $sysconfdir to /etc/opt/csw. I don't see a clean way to handle this move short of manually removing all of the packages and then adding them back. [Some packages register things in files provided by other packages, etc.] If I provide detailed instructions on the ordering of these operations, is that sufficient for our user base? NOTE: This is completely separate from the other changes that have been discussed recently. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Wed Sep 16 20:33:17 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Sep 2009 11:33:17 -0700 Subject: [csw-maintainers] interdependent packages moving to /etc/opt/csw In-Reply-To: <1253118865-sup-4588@ntdws12.chass.utoronto.ca> References: <1253118865-sup-4588@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Sep 16, 2009 at 9:37 AM, Ben Walton wrote: > > Hi All, > > I've got a large stack of interdependent packages that will be all > changing $sysconfdir to /etc/opt/csw. ?I don't see a clean way to > handle this move short of manually removing all of the packages and > then adding them back. ?[Some packages register things in files > provided by other packages, etc.] > > If I provide detailed instructions on the ordering of these > operations, is that sufficient for our user base? It sounds "highly complex". yikes. I would suggest that,for the sake of our users, you provide some sort of migration script, that first verifies everything is at the minimum level required (or does a "strings xyz" to see that the paths have changed), and then does the neccessary backflips. Or bombs out with appropriate error messages, if not up to date. You might provide the migration script, as part of the "highest level"(if there is one) package. possibly in the "docs" dir, along with an explaination there of why it is neccessary. From bwalton at opencsw.org Wed Sep 16 20:39:59 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 16 Sep 2009 14:39:59 -0400 Subject: [csw-maintainers] interdependent packages moving to /etc/opt/csw In-Reply-To: References: <1253118865-sup-4588@ntdws12.chass.utoronto.ca> Message-ID: <1253126281-sup-4486@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Sep 16 14:33:17 -0400 2009: > It sounds "highly complex". yikes. It's all the docbook junk which has packages register themselves, etc. Ordering is very important, which is the real fly in the ointment. > I would suggest that,for the sake of our users, you provide some sort > of migration script, that first verifies everything is at the minimum > level required (or does a "strings xyz" to see that the paths have > changed), and then does the neccessary backflips. Or bombs out with > appropriate error messages, if not up to date. This sounds reasonable. I'll put something together and make it available. I don't think it should go in any one ofhe packages though, since it's of limited future value. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Wed Sep 16 20:48:42 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Sep 2009 11:48:42 -0700 Subject: [csw-maintainers] interdependent packages moving to /etc/opt/csw In-Reply-To: <1253126281-sup-4486@ntdws12.chass.utoronto.ca> References: <1253118865-sup-4588@ntdws12.chass.utoronto.ca> <1253126281-sup-4486@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Sep 16, 2009 at 11:39 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Wed Sep 16 14:33:17 -0400 2009: > >> I would suggest that,for the sake of our users, you provide some sort >> of migration script, that first verifies everything is at the minimum >> level required (or does a "strings xyz" to see that the paths have >> changed), and then does the neccessary backflips. Or bombs out with >> appropriate error messages, if not up to date. > > This sounds reasonable. ?I'll put something together and make it > available. ?I don't think it should go in any one ofhe packages > though, since it's of limited future value. > well, consider keeping it in a package,for a year then? People do go a year without updates. and it's really nice to have it all there with the packages. From dam at opencsw.org Wed Sep 16 18:39:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 16 Sep 2009 18:39:02 +0200 Subject: [csw-maintainers] Minutes for the SummerCamp 2009 online now Message-ID: Hi, the minutes from the Summer Camp 2009 in Oslo are now available at and ready for discussion! Sorry for the delay -- Dago From maciej at opencsw.org Thu Sep 17 10:40:17 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 17 Sep 2009 09:40:17 +0100 Subject: [csw-maintainers] The source code of www.opencsw.org In-Reply-To: <20090726154345.GB28096@bolthole.com> References: <20090723220149.GB8541@bolthole.com> <20090724041722.GA50043@bolthole.com> <20090724042720.GB50043@bolthole.com> <4A6979F4.5050904@opencsw.org> <20090724160343.GC91227@bolthole.com> <4A6B4DFE.1050307@opencsw.org> <20090725203035.GA24170@bolthole.com> <4A6C2341.8060600@opencsw.org> <20090726154345.GB28096@bolthole.com> Message-ID: On Sun, Jul 26, 2009 at 4:43 PM, Philip Brown wrote: > On Sun, Jul 26, 2009 at 11:34:57AM +0200, Trygve Laugst?l wrote: >> Can you explain what the security reason for not putting it an SCM is? > > "a" source code control mechanism, I dont have much problem with. > putting it in a PUBLIC one, is where my concerns lay. > > Beyond that, I dont see the need to force everyone to use one particular > type of scm, just for small web page "code". > If the assorted people working on opencsw web stuff agree to standardize on > one internal-only scheme, i'd go along with it. But frankly, most of the > web related stuff is small enough that the old cycle of > > "make a save copy, tweak with the new stuff, publish it, forget about old > ?stuff" > > is perfectly adequate. Okay, so what's the process? I can't write to the htdocs directory, so what do I do? Make my own copy of everything and create a patch? When I have a patch ready, say, http://www.opencsw.org/~maciej/0001-Parseable-HTML-in-mirrors.shtml.patch -- what do I do with it next? Maciej From maciej at opencsw.org Thu Sep 17 12:24:15 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 17 Sep 2009 11:24:15 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> <4AAB32A6.5060305@opencsw.org> Message-ID: On Mon, Sep 14, 2009 at 8:37 PM, Maciej (Matchek) Blizinski wrote: > 3. The actual migration process involving shared/read-only /opt. > ("just move it" does not work) > > I'm mostly concerned with the discussion number 3, as it's blocking my > work with three pieces of software (cups, unixodbc and tightvnc). > Trygve, since you objected to putting my sample implementation into > testing, can you comment on the suggested solutions or suggest one of > your own? Trygve, ping? From skayser at opencsw.org Thu Sep 17 12:45:06 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 17 Sep 2009 12:45:06 +0200 (CEST) Subject: [csw-maintainers] GAR RFE: Variable(s) to tag files for classes instead of PROTOTYPE_FILTER In-Reply-To: <3E39F7BB-726B-4250-8388-43EEF3D24B3F@opencsw.org> References: <51363.194.246.122.22.1246478936.squirrel@ssl.skayser.de> <3E39F7BB-726B-4250-8388-43EEF3D24B3F@opencsw.org> Message-ID: <62623.194.246.122.22.1253184306.squirrel@ssl.skayser.de> Dagobert Michelsen wrote: > Am 01.07.2009 um 22:08 schrieb Sebastian Kayser: >> while working on postfix 2.6 i have noticed again that it is not quite >> straight-forward to assign files to classes. Instead of exposing the >> inner >> workings of the prototype stuff to the Makefile, could we maybe get >> some >> variables to assign files to classes (functions)? >> >> So instead of having: >> >> CONFIG_BASE = \/etc\/opt\/csw\/postfix\/ >> CONFIG_FILES = access aliases canonical generic header_checks >> CONFIG_FILES += main.cf master.cf >> CONFIG_FILES += relocated transport virtual >> >> PROTOTYPE_FILTER = awk '\ >> $(foreach C,$(prefix $(CONFIG_BASE),$(CONFIG_FILES)), \ >> $$$$3 ~ /^$(C)$$$$/ { $$$$2 = "cswcpsampleconf" }) \ >> .... >> >> just have something like: >> >> CONFIG_FILES = /etc/default/cswpostgrey >> CONFIG_FILES += /etc/opt/csw/postfix/access >> CONFIG_FILES += /etc/opt/csw/postfix/aliases >> CONFIG_FILES += /etc/opt/csw/postfix/canonical >> CONFIG_FILES += /etc/opt/csw/postfix/generic >> CONFIG_FILES += /etc/opt/csw/postfix/header_checks >> CONFIG_FILES += /etc/opt/csw/postfix/main.cf >> CONFIG_FILES += /etc/opt/csw/postfix/master.cf >> CONFIG_FILES += /etc/opt/csw/postfix/relocated >> CONFIG_FILES += /etc/opt/csw/postfix/transport >> CONFIG_FILES += /etc/opt/csw/postfix/virtual >> >> To me this would feel more declarative instead of the procedural way >> we do >> it with PROTOTYE_FILTER right now (note, it can be shortened with >> $(foreach and $(prefix, just like above). It would not only tag the >> class, >> but also wrap the other housekeeping, like moving the config files >> to .CSW >> during the build process. >> >> (Side note: Thinking ahead, it could also be an conceptual abstraction >> level WRT to IPS: Do IPS packages still have a prototype file?) >> >> This is only an example for config files, which i encounter most >> often. >> Other classes could be "wrapped" as well. One would just have to >> come up >> with the requirements, a proper naming scheme for the variables, >> and .... >> actually implement it in GAR. > > For CSWcswclassutils this is already in there :-) Just define > > SAMPLECONF > PRESERVECONF > INITSMF > > and everything else will be taken cared of. Heads up: There was a small bug in SAMPLECONF. Class assignment ended up in cswsampleconf instead of cswcpsampleconf. Fixed in r6329. Sebastian From skayser at opencsw.org Thu Sep 17 13:08:18 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 17 Sep 2009 13:08:18 +0200 (CEST) Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> <4AAB32A6.5060305@opencsw.org> Message-ID: <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Maciej (Matchek) Blizinski wrote: > On Mon, Sep 14, 2009 at 8:37 PM, Maciej (Matchek) Blizinski > wrote: >> 3. The actual migration process involving shared/read-only /opt. >> ("just move it" does not work) >> >> I'm mostly concerned with the discussion number 3, as it's blocking my >> work with three pieces of software (cups, unixodbc and tightvnc). >> Trygve, since you objected to putting my sample implementation into >> testing, can you comment on the suggested solutions or suggest one of >> your own? > > Trygve, ping? My concern with simply placing symlinks in /etc is that it doesn't reduce the clutter that i feel we have today. Some files reside in /opt others in /etc. I know there is the definition about what has to go into /etc/opt/csw and what has to go into /opt/csw/etc, but i see how this confuses people (including me). My preference would be to have it all in /etc, i.e. move config files over. To not break with setup like yours, couldn't we introduce a csw.conf variable that would indicate such a setup? cswclassutils scripts running in such an environment would know that they need to behave different. This way we could focus on having a simple baseline that works with the traditional "one host" (or "full root zone") setup and treat special setups in a special way (i don't feel we can fully address all of them with one single approach). I haven't thought that through completely, but it might be an alternative approach. Might also turn out to be even more complex. Sebastian From maciej at opencsw.org Thu Sep 17 15:44:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 17 Sep 2009 14:44:46 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> References: <4A939902.3050808@opencsw.org> <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: On Thu, Sep 17, 2009 at 12:08 PM, Sebastian Kayser wrote: > My concern with simply placing symlinks in /etc is that it doesn't reduce > the clutter that i feel we have today. Some files reside in /opt others in > /etc. I support that, I agree that one place for configuration is better then two places. (One might argue that creating /opt/csw/etc was unnecessary, as there already was /etc. I'd be personally happier with everything sitting in /etc as nature intended.) > I know there is the definition about what has to go into > /etc/opt/csw and what has to go into /opt/csw/etc, but i see how this > confuses people (including me). It's one of the things that in practice you're always forced to "just learn" and get over. Eradicating /opt/csw/etc would be great, but I don't think it's happening in foreseeable future. But we can do a lot to ease the pain by installing signposts in appropriate places. > My preference would be to have it all in /etc, i.e. move config files over. Or, in the case of shared /opt, copy them or link them (to leave them shared). > To not break with setup like yours, couldn't we introduce a csw.conf > variable that would indicate such a setup? cswclassutils scripts running > in such an environment would know that they need to behave different. What would be the cases and how would they be handled? I guess the cases could be: shared /opt => link files local /opt => move files > This way we could focus on having a simple baseline that works with the > traditional "one host" (or "full root zone") setup and treat special > setups in a special way That's a possibility; it would be good to indicate during installation, that such configuration variable is needed. > (i don't feel we can fully address all of them > with one single approach). I haven't thought that through completely, but > it might be an alternative approach. Might also turn out to be even more > complex. Perhaps, it's good to have many eyeballs look at the issue. In the meantime, Sebastian and I have added a section on incentives to move to /etct/opt/csw: http://wiki.opencsw.org/configuration-directory-migration Maciej From daniel at opencsw.org Thu Sep 17 16:43:39 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 17 Sep 2009 15:43:39 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> Message-ID: <4AB24B1B.6020101@opencsw.org> Sebastian Kayser wrote: > Daniel Pocock schrieb: > > Sebastian Kayser wrote: > >> Daniel Pocock wrote: > >>> Thanks for all the assistance and feedback about the CSW packaging > >> process > >>> I've finally got the unofficial 3.1.3 code into testing now - feedback > >>> is welcome > >> your packages have the UNCOMMITED status (see their file names), which > >> means that you had uncommitted local changes when building the package. > >> UNCOMITTED packages won't be considered for the testing catalog. > >> > >> Issue 'svn status' to see which files are still uncomitted, take > care of > >> them (commit or branch if necessary), rebuild the packages and replace > >> the > >> current ones in /home/testing. > > That is because I don't want to commit the checksum for > > ganglia-3.1.3.tar.gz as it is not an official release > > > > There are a couple of Makefile changes that are safe to commit though. > > I'm planning to tag 3.1.3 upstream on Friday, but I would like to get > > feedback from OpenCSW users before I do that. > > You could simply create a branch to work on the upcoming release. > > ~/mgar/pkg/ganglia$ svn cp trunk/ branches/ganglia-3.1.3-rc > Thanks for the advice about this - I have done as you suggest, and now the new packages are in testing again From phil at bolthole.com Thu Sep 17 18:25:09 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 17 Sep 2009 09:25:09 -0700 Subject: [csw-maintainers] The source code of www.opencsw.org In-Reply-To: References: <20090723220149.GB8541@bolthole.com> <20090724042720.GB50043@bolthole.com> <4A6979F4.5050904@opencsw.org> <20090724160343.GC91227@bolthole.com> <4A6B4DFE.1050307@opencsw.org> <20090725203035.GA24170@bolthole.com> <4A6C2341.8060600@opencsw.org> <20090726154345.GB28096@bolthole.com> Message-ID: On Thu, Sep 17, 2009 at 1:40 AM, Maciej (Matchek) Blizinski wrote: > > Okay, so what's the process? I can't write to the htdocs directory, so > what do I do? Make my own copy of everything and create a patch? When > I have a patch ready, say, > http://www.opencsw.org/~maciej/0001-Parseable-HTML-in-mirrors.shtml.patch > -- what do I do with it next? > forget "patch". you have a "live" html directory for a reason :) get it working. then when it works well enough, it will either replace what is already there, or be put in its own appropriate place. and you get full read/write access to it there. BTW: i kinda lost contact for what you are aiming for now. I think I maybe already provided you with the code chunk you asked from me. but if you need anything else, please let me know, specifically, what you need from me. From phil at bolthole.com Thu Sep 17 18:31:53 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 17 Sep 2009 09:31:53 -0700 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: On Thu, Sep 17, 2009 at 6:44 AM, Maciej (Matchek) Blizinski wrote: > > > I support that, I agree that one place for configuration is better > then two places. (One might argue that creating /opt/csw/etc was > unnecessary, as there already was [/etc/opt/csw]. On the contrary; it is quite NECCESSARY. As our filesystem layout guide already mentions! Sometimes, you WANT global, shared, identical preferences for an application. Sometimes you DONT. For things that almost never change, or get site-modified once and then mostly left alone for eternity, it is best to have them in /opt/csw/etc, for cases where /opt/csw is NFS shared, or shared across multiple zones. It makes life much simpler for the sysadmin. From maciej at opencsw.org Fri Sep 18 06:00:55 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 18 Sep 2009 05:00:55 +0100 Subject: [csw-maintainers] The source code of www.opencsw.org In-Reply-To: References: <20090723220149.GB8541@bolthole.com> <4A6979F4.5050904@opencsw.org> <20090724160343.GC91227@bolthole.com> <4A6B4DFE.1050307@opencsw.org> <20090725203035.GA24170@bolthole.com> <4A6C2341.8060600@opencsw.org> <20090726154345.GB28096@bolthole.com> Message-ID: On Thu, Sep 17, 2009 at 5:25 PM, Philip Brown wrote: > On Thu, Sep 17, 2009 at 1:40 AM, Maciej (Matchek) Blizinski > wrote: >> >> Okay, so what's the process? I can't write to the htdocs directory, so >> what do I do? Make my own copy of everything and create a patch? When >> I have a patch ready, say, >> http://www.opencsw.org/~maciej/0001-Parseable-HTML-in-mirrors.shtml.patch >> -- what do I do with it next? >> > > forget "patch". you have a "live" html directory for a reason :) > get it working. It's working! Sure, I can send a whole updated file too. Where should I deliver it? > BTW: i kinda lost contact for what you are aiming for now. The sample patch is just a random change. It only deals with comment code, removing bits that make it difficult to parse this page with less forgiving HTML parsers. Maciej From bonivart at opencsw.org Fri Sep 18 09:58:13 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 18 Sep 2009 09:58:13 +0200 Subject: [csw-maintainers] 1. VM image of OpenSolaris with OpenCSW, 2. Custom streams Message-ID: <625385e30909180058n709f044at1ce9756bd56a1e5d@mail.gmail.com> I would like to make available an image (for VMWare/VirtualBox) of OpenSolaris with OpenCSW bootstrapped. I tried it in VirtualBox and exported it as OVF and it's about 1,3 GB which is not that much today. We could even publish it as a torrent on Pirate Bay. :-) VMWare can also publish it for us. Sure we can't do this for Solaris 8-10 but even Sun is moving towards OpenSolaris now providing official support for it and many people are curious about it, it's time that we show our presence on that platform. Maybe we could get our "distro" publish on the OpenSolaris web site? The second idea is to allow people to customize their downloads on our (new) web site. They could click any number of packages and a stream would be prepared for download with all dependencies included. What do you think? -- /peter From schwindt at dfki.uni-kl.de Fri Sep 18 10:30:47 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Fri, 18 Sep 2009 10:30:47 +0200 Subject: [csw-maintainers] Updated libiconv in testing, testing appreciated In-Reply-To: Your message of "Fri, 31 Jul 2009 09:22:43 +0200." <49274.217.227.42.13.1249024963.squirrel@ssl.skayser.de> Message-ID: <200909180830.n8I8Ulu1005821@dfki.uni-kl.de> [...] > > I will give your version a try, as I always did have a patched version of > > iconv > > around, and am using a self compiled version of 1.13.1 for quite some time > > now. > > I can state that this version generally functions well, troublemaker like > > subversion works perfect with it. > > > > I'll let you know how things worked out > > cool, thanks for the support. Note though: I recently pulled the iconv > packages from testing, because they were ones, aimed at the CSWiconv -> > CSWlibiconv package name change. With various bits and pieces of our stack > currently being under heavy change (gtk, pango, bdb) I would like to > postpone such a (purely cosmetical) change. > > I will put new iconv packages with the current naming scheme into testing > later this day. Will keep you updated. This has been around for quite some time now - I installed und succesfully used on all our machines. Subversion - being the most picky package about iconv utf8/646 conversion - still works like a charme. How aboout releasing it from testing ? Or did anybody have issues with this ? Nicolai. From dam at opencsw.org Fri Sep 18 16:57:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 18 Sep 2009 16:57:32 +0200 Subject: [csw-maintainers] 1. VM image of OpenSolaris with OpenCSW, 2. Custom streams In-Reply-To: <625385e30909180058n709f044at1ce9756bd56a1e5d@mail.gmail.com> References: <625385e30909180058n709f044at1ce9756bd56a1e5d@mail.gmail.com> Message-ID: <4AE6D0E2-9D74-4C37-A139-ACE7C2DA2E37@opencsw.org> Hi Peter, Am 18.09.2009 um 09:58 schrieb Peter Bonivart: > I would like to make available an image (for VMWare/VirtualBox) of > OpenSolaris with OpenCSW bootstrapped. I tried it in VirtualBox and > exported it as OVF and it's about 1,3 GB which is not that much today. > We could even publish it as a torrent on Pirate Bay. :-) VMWare can > also publish it for us. Sure we can't do this for Solaris 8-10 but > even Sun is moving towards OpenSolaris now providing official support > for it and many people are curious about it, it's time that we show > our presence on that platform. Maybe we could get our "distro" publish > on the OpenSolaris web site? Good idea. And a good start to verify things before going IPS. > The second idea is to allow people to customize their downloads on our > (new) web site. They could click any number of packages and a stream > would be prepared for download with all dependencies included. > > What do you think? Well, that's what I wanted the stream-flag for initially :-) Best regards -- Dago From phil at bolthole.com Fri Sep 18 17:08:47 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Sep 2009 08:08:47 -0700 Subject: [csw-maintainers] serf - how to correctly depend on libapr ? In-Reply-To: <4A0F6B37.9090703@opencsw.org> References: <6af4270905161141t16480a31u917bacc3a4c2a303@mail.gmail.com> <4A0F6B37.9090703@opencsw.org> Message-ID: Going back a ways... On Sat, May 16, 2009 at 6:41 PM, Mike Watters wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > rupert THURNER wrote: >> i tried to create a package for libserf, which should replace libneon >> in future, as it is able to multithread subversion calls to a server. >> >> as there is no libapr, .... FYI, we just had an explicit pkg request for a separate apr package. From bonivart at opencsw.org Fri Sep 18 17:11:27 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 18 Sep 2009 17:11:27 +0200 Subject: [csw-maintainers] 1. VM image of OpenSolaris with OpenCSW, 2. Custom streams In-Reply-To: <4AE6D0E2-9D74-4C37-A139-ACE7C2DA2E37@opencsw.org> References: <625385e30909180058n709f044at1ce9756bd56a1e5d@mail.gmail.com> <4AE6D0E2-9D74-4C37-A139-ACE7C2DA2E37@opencsw.org> Message-ID: <625385e30909180811k70bea2fbs1e964d97c4b4d445@mail.gmail.com> On Fri, Sep 18, 2009 at 4:57 PM, Dagobert Michelsen wrote: >> The second idea is to allow people to customize their downloads on our >> (new) web site. They could click any number of packages and a stream >> would be prepared for download with all dependencies included. >> >> What do you think? > > Well, that's what I wanted the stream-flag for initially :-) Yes, it's not really my idea, I admit that. :-) I think it should be integrated into the new package browser on the new web site. Just click checkboxes next to the packages in the list and click "Create stream". -- /peter From phil at bolthole.com Fri Sep 18 17:59:51 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Sep 2009 08:59:51 -0700 Subject: [csw-maintainers] 1. VM image of OpenSolaris with OpenCSW, 2. Custom streams In-Reply-To: <625385e30909180811k70bea2fbs1e964d97c4b4d445@mail.gmail.com> References: <625385e30909180058n709f044at1ce9756bd56a1e5d@mail.gmail.com> <4AE6D0E2-9D74-4C37-A139-ACE7C2DA2E37@opencsw.org> <625385e30909180811k70bea2fbs1e964d97c4b4d445@mail.gmail.com> Message-ID: On Fri, Sep 18, 2009 at 8:11 AM, Peter Bonivart wrote: > > > I think it should be integrated into the new package browser on the > new web site. Just click checkboxes next to the packages in the list > and click "Create stream". > its a nice idea.... but do we have the bandwidth for this?? I thought that we were at least somewhat constrained in that reguard. I think that the preconfigured OS+CSW images are a great idea. Maybe we should just standardize on two,though: "desktop" and "server" perhaps? oh: in addition to "virtual machine" images... methinks it would be a very useful thing to have actual "install to bare iron" images? piggyback on the standard opensolaris installer somehow? and/or a livecd. From schwindt at dfki.uni-kl.de Fri Sep 18 18:31:38 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Fri, 18 Sep 2009 18:31:38 +0200 Subject: [csw-maintainers] geany 0.18 in testing Message-ID: <200909181631.n8IGVca9015020@dfki.uni-kl.de> Geany is a text editor using the GTK2 toolkit with basic features of an integrated development environment. It was developed to provide a small and fast IDE, which has only a few dependencies from other packages. It supports many filetypes and has some nice features. Feedback welcome Nicolai From dam at opencsw.org Fri Sep 18 22:39:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 18 Sep 2009 22:39:17 +0200 Subject: [csw-maintainers] New catalog for farm managers Message-ID: <1D5696A4-2E60-46F2-BCE3-4B5292D20445@opencsw.org> Hi, to ease the setup of buildfarms I have set up an additional catalog for farm-manager-only packages. These currently include - JDK 5 - JDK 6 - Sun Studio 11 - Sun Studio 12 - Sun Studio 12u1 All software is packaged as one package for most easy install: http://mirror.opencsw.org/opencsw/farm/ The packages are not meant for redistribution. Best regards -- Dago From phil at bolthole.com Sat Sep 19 00:15:05 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Sep 2009 15:15:05 -0700 Subject: [csw-maintainers] New catalog for farm managers In-Reply-To: <1D5696A4-2E60-46F2-BCE3-4B5292D20445@opencsw.org> References: <1D5696A4-2E60-46F2-BCE3-4B5292D20445@opencsw.org> Message-ID: On Fri, Sep 18, 2009 at 1:39 PM, Dagobert Michelsen wrote: > > All software is packaged as one package for most easy install: > > ?http://mirror.opencsw.org/opencsw/farm/ > > The packages are not meant for redistribution. > I would suggest then, that you rename the package filenames to NOT match our usual standard naming conventions? From dam at opencsw.org Sat Sep 19 14:04:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 19 Sep 2009 14:04:26 +0200 Subject: [csw-maintainers] Detection of libstdc++ in pkgcheck Message-ID: <0A00EB96-0F7F-4E30-8E34-7213A0C51B5F@opencsw.org> Hi, I noticed that pkgcheck warns me about a missing dependency to CSWgcc3g ++ because of the library libstdc++.so.6. It looks like this: /opt/csw/gcc3/lib/libstdc++.so.6=./../../lib/libstdc++.so.6 s none CSWgcc3g++ /opt/csw/gcc3/lib/libstdc++.so.6.0.1=./../../lib/libstdc++.so.6.0.1 s none CSWgcc3g++ /opt/csw/gcc3/lib/libstdc++.so.6.0.2=./../../lib/libstdc++.so.6.0.2 s none CSWgcc3g++ /opt/csw/gcc3/lib/libstdc++.so.6.0.3=./../../lib/libstdc++.so.6.0.3 s none CSWgcc3g++ /opt/csw/lib/libstdc++.so=./libstdc++.so.6.0.3 s none CSWgcc3g++rt /opt/csw/lib/libstdc++.so.6=./libstdc++.so.6.0.3 s none CSWgcc3g++rt /opt/csw/lib/libstdc++.so.6.0.1 f none 0755 root bin 1318628 61448 1248201928 CSWgcc3g++rt Shouldn't /opt/csw/gcc3/lib/libstdc++.so.6 belong to CSWgcc4g++rt instead of CSWgcc3g++? Best regards -- Dago From dam at opencsw.org Sat Sep 19 16:34:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 19 Sep 2009 16:34:28 +0200 Subject: [csw-maintainers] C++ hell with Sun Studio and GCC Message-ID: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> Hi, I am currently compiling xapian, a probabilistic search engine. The software is written in C++ and compiles under Sun Studio 11, 12 and GCC 3 and 4. There exist bindings for Ruby, Python and other languages. As Ruby is compiled with GCC I need to compile xapian with GCC too, otherwise the mangling does not work. However, Python requires Sun Studio. Is there any kind of "mangling conversion" between Sun Studio and GCC or must I really provide two versions of the xapian libraries? Best regards -- Dago From bwalton at opencsw.org Sat Sep 19 20:38:16 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Sep 2009 14:38:16 -0400 Subject: [csw-maintainers] C++ hell with Sun Studio and GCC In-Reply-To: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> References: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> Message-ID: <1253385314-sup-8901@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sat Sep 19 10:34:28 -0400 2009: Hi Dago, > As Ruby is compiled with GCC I need to compile xapian with GCC > too, otherwise the mangling does not work. However, Python requires > Sun Studio. Is there any kind of "mangling conversion" between > Sun Studio and GCC or must I really provide two versions of the > xapian libraries? I don't have an answer to your question, but I'm thinking about providing a 'split' ruby package. On solaris 8, I'd build with gcc4 as it is now. On 9 (and thus the package for 10), I'd use SOS12, which can apparently build ruby cleanly. This would allow me to meet my need to have ruby packages for sol8 still[1] while providing you a cleaner target to build against for the officially supported platforms. Work for you? Thanks -Ben [1] My fingers are crossed that we'll be getting a new platform to run our RoR apps, so this personal need may disappear soon too. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton at opencsw.org Sun Sep 20 01:55:44 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Sep 2009 19:55:44 -0400 Subject: [csw-maintainers] big package update in testing/ Message-ID: <1253403883-sup-5997@ntdws12.chass.utoronto.ca> Hi All, I've just stuffed the following packages into testing: asciidoc-8.4.5,REV=2009.09.18-SunOS5.8-all-CSW.pkg.gz docbookdsssl-1.79,REV=2009.09.15-SunOS5.8-all-CSW.pkg.gz docbookdtds-4.5,REV=2009.09.16-SunOS5.8-all-CSW.pkg.gz docbookxsl-1.74.3,REV=2009.09.11-SunOS5.8-all-CSW.pkg.gz docbookxsldoc-1.74.3,REV=2009.09.11-SunOS5.8-all-CSW.pkg.gz gitosis-0.2,REV=2009.09.19_rev=73a03-SunOS5.8-all-CSW.pkg.gz gnulinks-1.2,REV=2009.09.18-SunOS5.8-all-CSW.pkg.gz libxml2-2.7.3,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz libxml2-2.7.3,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz libxml2_devel-2.7.3,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz libxml2_devel-2.7.3,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz libxslt-1.1.24,REV=2009.09.08-SunOS5.8-i386-CSW.pkg.gz libxslt-1.1.24,REV=2009.09.08-SunOS5.8-sparc-CSW.pkg.gz libxslt_devel-1.1.24,REV=2009.09.08-SunOS5.8-i386-CSW.pkg.gz libxslt_devel-1.1.24,REV=2009.09.08-SunOS5.8-sparc-CSW.pkg.gz openjade-1.3.2,REV=2009.09.11-SunOS5.8-i386-CSW.pkg.gz openjade-1.3.2,REV=2009.09.11-SunOS5.8-sparc-CSW.pkg.gz py_libxml2-2.7.3,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz py_libxml2-2.7.3,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz py_libxslt-1.1.24,REV=2009.09.08-SunOS5.8-i386-CSW.pkg.gz py_libxslt-1.1.24,REV=2009.09.08-SunOS5.8-sparc-CSW.pkg.gz sgmlcommon-0.6.3,REV=2009.09.13-SunOS5.8-all-CSW.pkg.gz xmlcommon-0.6.3,REV=2009.09.13-SunOS5.8-all-CSW.pkg.gz xmlto-0.0.22,REV=2009.09.16-SunOS5.8-i386-CSW.pkg.gz xmlto-0.0.22,REV=2009.09.16-SunOS5.8-sparc-CSW.pkg.gz These are all somewhat interrelated/interdependent, so if you update one of these from testing, please update all of the others in use on your systems. The attached script (which I haven't tested on my own systems yet since I'm waiting for catalog updates) may ease this process. ...as you can see from the script, there is no good place to include this with any one of the packages. Please let me know of any issues you encounter. Also, if any of your packages depend on one of these and do xml/sgml catalog registration, let me know. I'll hold the release of these until you can provide an updated package too. Feedback is welcome. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: update_xml_pkgs.sh Type: application/x-sh Size: 912 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton at opencsw.org Sun Sep 20 16:12:18 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 20 Sep 2009 10:12:18 -0400 Subject: [csw-maintainers] mantis mail Message-ID: <1253455888-sup-7101@ntdws12.chass.utoronto.ca> Hi All, Is it possible to have mantis send only a single piece of mail per bug update? I seem to get 2 per update... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: not available URL: From bchill at opencsw.org Mon Sep 21 00:31:42 2009 From: bchill at opencsw.org (Brian Hill) Date: Sun, 20 Sep 2009 22:31:42 +0000 Subject: [csw-maintainers] librsync 0.9.7 uploaded to testing Message-ID: <20090920223142.GB24322@vm-1.bch.net> I have loaded librsync for testing. It isn't all that useful by itself, but it is needed for rdiff-backup, which is coming soon. Does the descriptions file update at regular intervals or is it done by hand? A pkg-get of librsync from testing doesn't work yet. Brian From bchill at opencsw.org Mon Sep 21 03:21:08 2009 From: bchill at opencsw.org (Brian Hill) Date: Mon, 21 Sep 2009 01:21:08 +0000 Subject: [csw-maintainers] rdiff-backup 1.2.8 uploaded to testing Message-ID: <20090921012108.GA5266@vm-1.bch.net> I have uploaded rdiff-backup for testing. Brian From bonivart at opencsw.org Mon Sep 21 10:04:07 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 21 Sep 2009 10:04:07 +0200 Subject: [csw-maintainers] librsync 0.9.7 uploaded to testing In-Reply-To: <20090920223142.GB24322@vm-1.bch.net> References: <20090920223142.GB24322@vm-1.bch.net> Message-ID: <625385e30909210104r3848006drfb465c3d3039644f@mail.gmail.com> On Mon, Sep 21, 2009 at 12:31 AM, Brian Hill wrote: > ? ? ? ?I have loaded librsync for testing. It isn't all that useful by > itself, but it is needed for rdiff-backup, which is coming soon. > > ? ? ? ?Does the descriptions file update at regular intervals or is it > done by hand? A pkg-get of librsync from testing doesn't work yet. I only saw Sparc packages there and those seem to work with pkgutil: New packages: CSWlibrsync-0.9.7,REV=2009.09.05 CSWpython-rt-2.6.2,REV=2009.08.12 CSWrdiff-backup-1.2.8,REV=2009.09.20 Updated packages: CSWcommon-1.4.7,REV=2009.09.20 CSWiconv-1.13.1,REV=2009.07.31 CSWzlib-1.2.3,REV=2009.04.05 Current packages: CSWbzip2-1.0.5,REV=2009.01.17 CSWggettextrt-0.17,REV=2009.02.13 CSWlibpopt-1.14,REV=2009.02.24 Total size: 4.7 MB 6 packages to fetch. Do you want to continue? [Y,n] -- /peter From skayser at opencsw.org Mon Sep 21 17:22:00 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 21 Sep 2009 17:22:00 +0200 (CEST) Subject: [csw-maintainers] Xlibs regression when building xterm (Xrender.h/Xft.h not found, ...) Message-ID: <65323.194.246.122.22.1253546520.squirrel@ssl.skayser.de> Hi, i just wanted to bump the xterm [1] version, ran into build issues, and noticed that i can't even build the version which i had released a few months ago any more (was r4246). ./configure fails to detect freetype support due to missing Xrender.h and Xft.h files [2]. What's the proper way to fix this? Or, rephrased, what's the canonical way to build X11 stuff in general, now that we have introduced our own X11 libs? For now i simply tried to point EXTRA_INC and EXTRA_LIB to /opt/csw/X11{include,lib} and EXTRA_PKG_CONFIG_PATH to /opt/csw/X11/lib/pkgconfig, which cures the Xrender.h/Xft.h issue, but raises another one. Now some Xutf8* symbols (which belong to /opt/csw/X11/lib/libX11.so) can't be resolved during linking. Excerpt below, for details see [3]. Undefined first referenced symbol in file Xutf8TextListToTextProperty button.o XA_UTF8_STRING button.o Xutf8TextPropertyToTextList button.o Xutf8LookupString input.o Help appreciated Sebastian [1] https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/xterm/trunk/Makefile [2] http://dpaste.com/96324/ [3] http://dpaste.com/96333/ From phil at bolthole.com Mon Sep 21 17:24:11 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Sep 2009 08:24:11 -0700 Subject: [csw-maintainers] Detection of libstdc++ in pkgcheck In-Reply-To: <0A00EB96-0F7F-4E30-8E34-7213A0C51B5F@opencsw.org> References: <0A00EB96-0F7F-4E30-8E34-7213A0C51B5F@opencsw.org> Message-ID: On Sat, Sep 19, 2009 at 5:04 AM, Dagobert Michelsen wrote: > Hi, > > I noticed that pkgcheck warns me about a missing dependency to CSWgcc3g++ > because of the library libstdc++.so.6. >[...] > Shouldn't /opt/csw/gcc3/lib/libstdc++.so.6 belong to CSWgcc4g++rt instead of > CSWgcc3g++? > yes. this is a long time known bug. If you have a suggested FIX for this bug, please feel free to contribute :-) however, I will say ahead of time, that you should consider the overall behaviour of how checkpkg works. your fix should not take away from functionality. (for example, it works as non-root user. One proposal to "fix" it, required running as root. So, I rejected that change) From phil at bolthole.com Mon Sep 21 17:28:04 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Sep 2009 08:28:04 -0700 Subject: [csw-maintainers] Xlibs regression when building xterm (Xrender.h/Xft.h not found, ...) In-Reply-To: <65323.194.246.122.22.1253546520.squirrel@ssl.skayser.de> References: <65323.194.246.122.22.1253546520.squirrel@ssl.skayser.de> Message-ID: On Mon, Sep 21, 2009 at 8:22 AM, Sebastian Kayser wrote: > Hi, > > i just wanted to bump the xterm [1] version, ran into build issues, and > noticed that i can't even build the version which i had released a few > months ago any more (was r4246). > > ./configure fails to detect freetype support due to missing Xrender.h and > Xft.h files [2]. What's the proper way to fix this? as a reminder to people who may not be familiar with things: previously, we provided an "Xrender" package, that provided the header files. The extension is somewhat odd, in that it only needs the header files to compile, not libraries. So, you could compile it on 8, even though it would not support xrender on 8. but it woudl automatically work right with later versions of solaris. (something like that, anyways). HOWEVER; our new xrender package, provides actual libs, which tie into the "new" X11. So, I think your choices are basically either A) grab the "old" headers and keep em around, and compile the old way or B) make xterm depend fully on our new, modern X11 libs from now on. But I'll let our new X11 lib maintainers chime in now. From skayser at opencsw.org Mon Sep 21 18:39:12 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 21 Sep 2009 18:39:12 +0200 (CEST) Subject: [csw-maintainers] Xlibs regression when building xterm (Xrender.h/Xft.h not found, ...) In-Reply-To: References: <65323.194.246.122.22.1253546520.squirrel@ssl.skayser.de> Message-ID: <65064.194.246.122.22.1253551152.squirrel@ssl.skayser.de> Philip Brown wrote: > On Mon, Sep 21, 2009 at 8:22 AM, Sebastian Kayser > wrote: >> i just wanted to bump the xterm [1] version, ran into build issues, and >> noticed that i can't even build the version which i had released a few >> months ago any more (was r4246). >> >> ./configure fails to detect freetype support due to missing Xrender.h >> and >> Xft.h files [2]. What's the proper way to fix this? > > > as a reminder to people who may not be familiar with things: > > previously, we provided an "Xrender" package, that provided the header > files. > The extension is somewhat odd, in that it only needs the header files > to compile, not libraries. > So, you could compile it on 8, even though it would not support > xrender on 8. but it woudl automatically work right with later > versions of solaris. > (something like that, anyways). > > HOWEVER; our new xrender package, provides actual libs, which tie into > the "new" X11. > > So, I think your choices are basically either > > A) grab the "old" headers and keep em around, and compile the old way > or > B) make xterm depend fully on our new, modern X11 libs from now on. > > But I'll let our new X11 lib maintainers chime in now. Thanks for the info, Phil. Update: i worked towards using the CSWlibx11 bits (xterm has --x-includes and --x-libraries ./configure flags, no need for EXTRA_INC or EXTRA_LIB) and now i am down to some remaining linkage errors. Undefined first referenced symbol in file FcCharSetHasChar fontutils.o (symbol belongs to implicit dependency /opt/csw/lib/libfontconfig.so.1) FcPatternBuild fontutils.o (symbol belongs to implicit dependency /opt/csw/lib/libfontconfig.so.1) FcPatternDestroy fontutils.o (symbol belongs to implicit dependency /opt/csw/lib/libfontconfig.so.1) XA_UTF8_STRING button.o ^^ Non-wrapped output and cc invocation available on dpaste [1]. Sebastian [1] http://dpaste.com/96366/ From bwalton at opencsw.org Mon Sep 21 19:11:34 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 21 Sep 2009 13:11:34 -0400 Subject: [csw-maintainers] C++ hell with Sun Studio and GCC In-Reply-To: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> References: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> Message-ID: <1253553057-sup-1892@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sat Sep 19 10:34:28 -0400 2009: Hi Dago, > As Ruby is compiled with GCC I need to compile xapian with GCC > too, otherwise the mangling does not work. However, Python requires > Sun Studio. Is there any kind of "mangling conversion" between > Sun Studio and GCC or must I really provide two versions of the > xapian libraries? I think moving ruby to SOS12 is the better long term solution, but could this be handled with modulations? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From glaw at opencsw.org Mon Sep 21 23:07:35 2009 From: glaw at opencsw.org (Gary Law) Date: Mon, 21 Sep 2009 22:07:35 +0100 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: 2009/9/15 Philip Brown : > I think that's going too far. > If a package wants to declare some of the same directories/perms as > what is in CSWcommon, it's a little redundant, but it's not "wrong". Well, I've put a new puppet package together that doesn't lay claim to those dirs anyway. It's in testing. Gary -- Gary Law Email: garylaw at garylaw.net Chat googletalk/messenger: gary.law at gmail.com iChat/jabber/AIM: gary.law at mac.com From glaw at opencsw.org Tue Sep 22 01:08:52 2009 From: glaw at opencsw.org (Gary Law) Date: Tue, 22 Sep 2009 00:08:52 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: 2009/9/17 Philip Brown : > On Thu, Sep 17, 2009 at 6:44 AM, Maciej (Matchek) Blizinski [snip] >> I support that, I agree that one place for configuration is better >> then two places. (One might argue that creating /opt/csw/etc was >> unnecessary, as there already was [/etc/opt/csw]. [snip] > Sometimes, you WANT global, shared, identical preferences for an application. > Sometimes you DONT. > > For things that almost never change, or get site-modified once and > then mostly left alone for eternity, it is best to have them in > /opt/csw/etc, for cases where /opt/csw is NFS shared, or shared across > multiple zones. It makes life much simpler for the sysadmin. I beg to differ. The increased complexity of two places outweighs any possible benefits. Everything in /etc/opt/csw please. -- Gary Law glaw at blastwave.org From dam at opencsw.org Tue Sep 22 07:45:33 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 07:45:33 +0200 Subject: [csw-maintainers] C++ hell with Sun Studio and GCC In-Reply-To: <1253553057-sup-1892@ntdws12.chass.utoronto.ca> References: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> <1253553057-sup-1892@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 21.09.2009 um 19:11 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Sat Sep 19 10:34:28 > -0400 2009: >> As Ruby is compiled with GCC I need to compile xapian with GCC >> too, otherwise the mangling does not work. However, Python requires >> Sun Studio. Is there any kind of "mangling conversion" between >> Sun Studio and GCC or must I really provide two versions of the >> xapian libraries? > > I think moving ruby to SOS12 is the better long term solution, but > could this be handled with modulations? Definitely. That would mean Ruby for Solaris 8 with GCC and starting with Solaris 9 with Sun Studio 12? That would make things of additional packages awfully hard as they would require modulations too. I like deprecation of Solaris 8 better here due to the massive complexities introduced with the splitted compilation. Anyway, an example for a compiler modulation is libtool. So I propose making a Solaris 8 Ruby with GCC if you really need it and starting with Solaris 9 and Sun Studio 12 for eveything else. BTW, are you interested in packaging up RubeEE and Phusion Passenger? I would need that also for my project, but as Ruby maintainer this would naturally be more on your side ;-) Best regards -- Dago From dam at opencsw.org Tue Sep 22 07:52:21 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 07:52:21 +0200 Subject: [csw-maintainers] Xlibs regression when building xterm (Xrender.h/Xft.h not found, ...) In-Reply-To: <65064.194.246.122.22.1253551152.squirrel@ssl.skayser.de> References: <65323.194.246.122.22.1253546520.squirrel@ssl.skayser.de> <65064.194.246.122.22.1253551152.squirrel@ssl.skayser.de> Message-ID: Hi Sebastian, Am 21.09.2009 um 18:39 schrieb Sebastian Kayser: > Philip Brown wrote: > Thanks for the info, Phil. Update: i worked towards using the > CSWlibx11 > bits (xterm has --x-includes and --x-libraries ./configure flags, no > need > for EXTRA_INC or EXTRA_LIB) and now i am down to some remaining > linkage > errors. > > Undefined first referenced > symbol in file > FcCharSetHasChar fontutils.o (symbol belongs to > implicit dependency /opt/csw/lib/libfontconfig.so.1) > FcPatternBuild fontutils.o (symbol belongs to > implicit dependency /opt/csw/lib/libfontconfig.so.1) > FcPatternDestroy fontutils.o (symbol belongs to > implicit dependency /opt/csw/lib/libfontconfig.so.1) > XA_UTF8_STRING button.o > > ^^ Non-wrapped output and cc invocation available on dpaste [1]. > > Sebastian > > [1] http://dpaste.com/96366/ I have not seen this before. Maybe a dependency has not been correctly compiled in there. Could you please verify where the symbols come from? Best regards -- Dago From maciej at opencsw.org Tue Sep 22 09:30:16 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 08:30:16 +0100 Subject: [csw-maintainers] GAR classes list variable name Message-ID: Is it CLASSES as described at [1] or SPKG_CLASSES as used in [2]? Maciej [1] http://wiki.opencsw.org/cswclassutils-package#toc6 [2] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gitosis/trunk/Makefile From bonivart at opencsw.org Tue Sep 22 09:38:31 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 22 Sep 2009 09:38:31 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: Message-ID: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> On Tue, Sep 22, 2009 at 9:30 AM, Maciej (Matchek) Blizinski wrote: > Is it CLASSES as described at [1] or SPKG_CLASSES as used in [2]? It's CLASSES when doing manual stuff in pkginfo and it's SPKG_CLASSES when using mGAR v2. But now it's even simpler to do when using GAR so you don't even have to bother with setting the classes. -- /peter From maciej at opencsw.org Tue Sep 22 10:02:22 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 09:02:22 +0100 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> Message-ID: On Tue, Sep 22, 2009 at 8:38 AM, Peter Bonivart wrote: > On Tue, Sep 22, 2009 at 9:30 AM, Maciej (Matchek) Blizinski > wrote: >> Is it CLASSES as described at [1] or SPKG_CLASSES as used in [2]? > > It's CLASSES when doing manual stuff in pkginfo and it's SPKG_CLASSES > when using mGAR v2. But now it's even simpler to do when using GAR so > you don't even have to bother with setting the classes. I've read the instructions on the and they don't seem complete to me. There are 2 things needed to set the file ownership: 1. A file defining users and groups (USERGROUP = ...) 2. A prototype with the ugfiles class The second bit needs to be done by filtering the prototype, is that right? A sample piece of code: USERGROUP = /opt/csw/etc/pkg/CSWmysql5/cswusergroup PROTOTYPE_FILTER = awk ' \ $$$$3 ~ /\/var\/opt\/csw\/mysql5$$$$/ { $$$$2 = "ugfiles"; \ $$$$4 = "0700"; \ $$$$5 = "mysql"; \ $$$$6 = "mysql" } \ { print }' SPKG_CLASSES = none ugfiles Without the last line (SPKG_CLASSES), my ugfiles-class file wasn't created on the disk during package installation. Maciej From dam at opencsw.org Tue Sep 22 10:09:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 10:09:49 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> Message-ID: <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> Hi Maciej, Am 22.09.2009 um 10:02 schrieb Maciej (Matchek) Blizinski: > On Tue, Sep 22, 2009 at 8:38 AM, Peter Bonivart > wrote: >> On Tue, Sep 22, 2009 at 9:30 AM, Maciej (Matchek) Blizinski >> wrote: >>> Is it CLASSES as described at [1] or SPKG_CLASSES as used in [2]? >> >> It's CLASSES when doing manual stuff in pkginfo and it's SPKG_CLASSES >> when using mGAR v2. But now it's even simpler to do when using GAR so >> you don't even have to bother with setting the classes. > > I've read the instructions on the and they don't seem complete to me. > There are 2 things needed to set the file ownership: > > 1. A file defining users and groups (USERGROUP = ...) > 2. A prototype with the ugfiles class > > The second bit needs to be done by filtering the prototype, is that > right? A sample piece of code: > > USERGROUP = /opt/csw/etc/pkg/CSWmysql5/cswusergroup > PROTOTYPE_FILTER = awk ' \ > $$$$3 ~ /\/var\/opt\/csw\/mysql5$$$$/ { $$$$2 = "ugfiles"; \ > $$$$4 = "0700"; \ > $$$$5 = "mysql"; \ > $$$$6 = "mysql" } \ > { print }' > SPKG_CLASSES = none ugfiles > > Without the last line (SPKG_CLASSES), my ugfiles-class file wasn't > created on the disk during package installation. What do you think about my proposal I sent some time ago? Am 06.09.2009 um 22:14 schrieb Dagobert Michelsen: > Am 05.09.2009 um 18:21 schrieb Maciej (Matchek) Blizinski: >> My day-to-day environment has umask set to 027; but many packages, >> when built with this umask, end up with binaries having permissions >> 0750. Perhaps it would be a good idea to do a GAR sanity check: bail >> out if umask is set to anything else than 022 when building a >> package? > > The standard user:group are already set in cswproto, as are the > permissions > for directories: > >> # Prototype defaults >> $StdOwn = 'root'; >> $StdGrp = 'bin'; >> $StdDirPerm = '0755'; > > I could imagine setting a default for files. Or changing the umask > to 022 > automatically on GAR invocation. BTW, we still a way of easily > tweaking > the prototype as PROTOTYPE_FILTERs are still too complex. > > Something like this could be useful: > > PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf > PROTOTYPE_PERMS_mytweaks = 0644 > PROTOTYPE_CLASS_mytweaks = cswconffile > > PROTOTYPE_MODIFIERS = mytweaks > > Here, PROTOTYPE_MODIFIERS is a list of modifiers to apply where for > each > modifier one or more fields can be changed. And PROTOTYPE_USER_mytweaks = myuser which would trigger the addition of 'ugfiles' to classes. Sounds good? Best regards -- Dago From bonivart at opencsw.org Tue Sep 22 10:16:34 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 22 Sep 2009 10:16:34 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> Message-ID: <625385e30909220116ya50f1d2i6bc611776efe5bd5@mail.gmail.com> On Tue, Sep 22, 2009 at 10:02 AM, Maciej (Matchek) Blizinski wrote: > I've read the instructions on the and they don't seem complete to me. > There are 2 things needed to set the file ownership: > > 1. A file defining users and groups (USERGROUP = ...) > 2. A prototype with the ugfiles class > > The second bit needs to be done by filtering the prototype, is that > right? A sample piece of code: > > USERGROUP = /opt/csw/etc/pkg/CSWmysql5/cswusergroup > PROTOTYPE_FILTER = awk ' \ > ? ?$$$$3 ~ /\/var\/opt\/csw\/mysql5$$$$/ { $$$$2 = "ugfiles"; \ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?$$$$4 = "0700"; \ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?$$$$5 = "mysql"; \ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?$$$$6 = "mysql" } \ > ? ?{ print }' > SPKG_CLASSES = none ugfiles > > Without the last line (SPKG_CLASSES), my ugfiles-class file wasn't > created on the disk during package installation. I haven't actually used the new GAR definitions since they arrived but I don't think there's a problem with the other ones, it's just the usergroup class that's a pain to explain. I've had lots of questions about it and tried to improve the documentation several times but now I don't think I can until I try the changes myself. I guess you still need the prototype filter in GAR after all just for this case. Maybe Dago and Sebastian can help simplifying this? -- /peter From maciej at opencsw.org Tue Sep 22 10:42:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 09:42:13 +0100 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> Message-ID: On Tue, Sep 22, 2009 at 9:09 AM, Dagobert Michelsen wrote: > What do you think about my proposal I sent some time ago? > > Am 06.09.2009 um 22:14 schrieb Dagobert Michelsen: >> >> Am 05.09.2009 um 18:21 schrieb Maciej (Matchek) Blizinski: >>> >>> My day-to-day environment has umask set to 027; but many packages, >>> when built with this umask, end up with binaries having permissions >>> 0750. Perhaps it would be a good idea to do a GAR sanity check: bail >>> out if umask is set to anything else than 022 when building a package? >> >> The standard user:group are already set in cswproto, as are the >> permissions >> for directories: >> >>> # Prototype defaults >>> $StdOwn = 'root'; >>> $StdGrp = 'bin'; >>> $StdDirPerm = '0755'; >> >> I could imagine setting a default for files. Or changing the umask to 022 >> automatically on GAR invocation. I would suggest having something like this in the ~/.garrc file: STOP_ON_WRONG_UMASK = 1 If the umask is not 022, the build would stop. >> BTW, we still a way of easily tweaking >> the prototype as PROTOTYPE_FILTERs are still too complex. >> >> Something like this could be useful: >> >> PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf >> PROTOTYPE_PERMS_mytweaks = 0644 >> PROTOTYPE_CLASS_mytweaks = cswconffile >> >> PROTOTYPE_MODIFIERS = mytweaks >> >> Here, PROTOTYPE_MODIFIERS is a list of modifiers to apply where for each >> modifier one or more fields can be changed. > > > And > PROTOTYPE_USER_mytweaks = myuser > which would trigger the addition of 'ugfiles' to classes. > > > Sounds good? >From the user's perspective, it's easier to think in terms of accomplishing a specific task. If I want to set user/group/permissions for a specific file, I'd find it more intuitive to use "USERGROUP" prefix rather than "PROTOTYPE", even though it's where the tweaking takes place under the hood. How about the following? USERGROUP_PASSWD = /etc/opt/csw/pkg/CSWfoo/cswusergroup USERGROUP_MODIFIERS = mytweaks USERGROUP_mytweaks_USER = mysql USERGROUP_mytweaks_GROUP = mysql USERGROUP_mytweaks_PERMS = 0700 USERGROUP_mytweaks_FILES = /var/opt/csw/mysql5 Maciej From skayser at opencsw.org Tue Sep 22 10:42:32 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 10:42:32 +0200 Subject: [csw-maintainers] Xlibs regression when building xterm (Xrender.h/Xft.h not found, ...) In-Reply-To: References: <65323.194.246.122.22.1253546520.squirrel@ssl.skayser.de> <65064.194.246.122.22.1253551152.squirrel@ssl.skayser.de> Message-ID: <4AB88DF8.5080301@opencsw.org> Dagobert Michelsen wrote on 22.09.2009 07:52: > Am 21.09.2009 um 18:39 schrieb Sebastian Kayser: >> Philip Brown wrote: >> Thanks for the info, Phil. Update: i worked towards using the >> CSWlibx11 >> bits (xterm has --x-includes and --x-libraries ./configure flags, no >> need >> for EXTRA_INC or EXTRA_LIB) and now i am down to some remaining >> linkage >> errors. >> >> Undefined first referenced >> symbol in file >> FcCharSetHasChar fontutils.o (symbol belongs to >> implicit dependency /opt/csw/lib/libfontconfig.so.1) >> FcPatternBuild fontutils.o (symbol belongs to >> implicit dependency /opt/csw/lib/libfontconfig.so.1) >> FcPatternDestroy fontutils.o (symbol belongs to >> implicit dependency /opt/csw/lib/libfontconfig.so.1) >> XA_UTF8_STRING button.o >> >> ^^ Non-wrapped output and cc invocation available on dpaste [1]. >> >> Sebastian >> >> [1] http://dpaste.com/96366/ > > I have not seen this before. Maybe a dependency has not been correctly > compiled > in there. Could you please verify where the symbols come from? Regarding the XA_UTF8_STRING symbol: it comes with a recent [1] libXmu library (X11 utility library) for which we don't yet have a CSW pkg. xterm _also_ ships with an implementation of XA_UTF8_STRING, but when it finds that X_HAVE_UTF8_STRING is defined (set by our Xlib.h), it assumes the system has an implementation of its own. In our case however, the system doesn't have have it, thus the build breaks. The stock Solaris Xlib.h which i used for the build a few months ago, doesn't set X_HAVE_UTF8_STRING. That's why the build was fine. Technically, xterm's assumption about the XA_UTF8_STRING presence might be wrong though, as it only checks for a Xlib UTF8 #define and then assumes the presence of a libXmu function. Guess i might have to talk to upstream. Still not sure about the Fc* symbol woes. Sebastian [1] Solaris 10 has a libXmu version that comes with XA_UTF8_STRING, Solaris 8 and 9 don't. From dam at opencsw.org Tue Sep 22 11:07:38 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 11:07:38 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> Message-ID: <8ACE4AB2-ACBB-4069-BC88-66BE92A2E586@opencsw.org> Hi Maciej, Am 22.09.2009 um 10:42 schrieb Maciej (Matchek) Blizinski: > On Tue, Sep 22, 2009 at 9:09 AM, Dagobert Michelsen > wrote: >> What do you think about my proposal I sent some time ago? >> >> Am 06.09.2009 um 22:14 schrieb Dagobert Michelsen: >>> >>> Am 05.09.2009 um 18:21 schrieb Maciej (Matchek) Blizinski: >>>> >>>> My day-to-day environment has umask set to 027; but many packages, >>>> when built with this umask, end up with binaries having permissions >>>> 0750. Perhaps it would be a good idea to do a GAR sanity check: >>>> bail >>>> out if umask is set to anything else than 022 when building a >>>> package? >>> >>> The standard user:group are already set in cswproto, as are the >>> permissions >>> for directories: >>> >>>> # Prototype defaults >>>> $StdOwn = 'root'; >>>> $StdGrp = 'bin'; >>>> $StdDirPerm = '0755'; >>> >>> I could imagine setting a default for files. Or changing the umask >>> to 022 >>> automatically on GAR invocation. > > I would suggest having something like this in the ~/.garrc file: > > STOP_ON_WRONG_UMASK = 1 > > If the umask is not 022, the build would stop. > >>> BTW, we still a way of easily tweaking >>> the prototype as PROTOTYPE_FILTERs are still too complex. >>> >>> Something like this could be useful: >>> >>> PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf >>> PROTOTYPE_PERMS_mytweaks = 0644 >>> PROTOTYPE_CLASS_mytweaks = cswconffile >>> >>> PROTOTYPE_MODIFIERS = mytweaks >>> >>> Here, PROTOTYPE_MODIFIERS is a list of modifiers to apply where >>> for each >>> modifier one or more fields can be changed. >> >> >> And >> PROTOTYPE_USER_mytweaks = myuser >> which would trigger the addition of 'ugfiles' to classes. >> >> >> Sounds good? > >> From the user's perspective, it's easier to think in terms of > accomplishing a specific task. If I want to set user/group/permissions > for a specific file, I'd find it more intuitive to use "USERGROUP" > prefix rather than "PROTOTYPE", even though it's where the tweaking > takes place under the hood. How about the following? > > USERGROUP_PASSWD = /etc/opt/csw/pkg/CSWfoo/cswusergroup > USERGROUP_MODIFIERS = mytweaks > USERGROUP_mytweaks_USER = mysql > USERGROUP_mytweaks_GROUP = mysql > USERGROUP_mytweaks_PERMS = 0700 > USERGROUP_mytweaks_FILES = /var/opt/csw/mysql5 The point is that you can modify all fields from the prototype here, ftype, class, major, minor, owner, mode, link-destinations, just everything. It is meant to replace the PROTOTYPE_FILTER, not just as a shortcut to cswusergroup. So fixating only on USERGROUP seems wrong to me. Best regards -- Dago From skayser at opencsw.org Tue Sep 22 11:08:54 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 11:08:54 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> Message-ID: <4AB89426.3090903@opencsw.org> Maciej (Matchek) Blizinski wrote on 22.09.2009 10:42: > On Tue, Sep 22, 2009 at 9:09 AM, Dagobert Michelsen wrote: >> What do you think about my proposal I sent some time ago? >> >> Am 06.09.2009 um 22:14 schrieb Dagobert Michelsen: >>> Am 05.09.2009 um 18:21 schrieb Maciej (Matchek) Blizinski: >>>> My day-to-day environment has umask set to 027; but many packages, >>>> when built with this umask, end up with binaries having permissions >>>> 0750. Perhaps it would be a good idea to do a GAR sanity check: bail >>>> out if umask is set to anything else than 022 when building a package? >>> The standard user:group are already set in cswproto, as are the >>> permissions >>> for directories: >>> >>>> # Prototype defaults >>>> $StdOwn = 'root'; >>>> $StdGrp = 'bin'; >>>> $StdDirPerm = '0755'; >>> I could imagine setting a default for files. Or changing the umask to 022 >>> automatically on GAR invocation. > > I would suggest having something like this in the ~/.garrc file: > > STOP_ON_WRONG_UMASK = 1 > > If the umask is not 022, the build would stop. > >>> BTW, we still a way of easily tweaking >>> the prototype as PROTOTYPE_FILTERs are still too complex. >>> >>> Something like this could be useful: >>> >>> PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf >>> PROTOTYPE_PERMS_mytweaks = 0644 >>> PROTOTYPE_CLASS_mytweaks = cswconffile >>> >>> PROTOTYPE_MODIFIERS = mytweaks >>> >>> Here, PROTOTYPE_MODIFIERS is a list of modifiers to apply where for each >>> modifier one or more fields can be changed. >> >> And >> PROTOTYPE_USER_mytweaks = myuser >> which would trigger the addition of 'ugfiles' to classes. >> >> Sounds good? +1 For the idea to introduce an easier interface to PROTOTYPE_FILTER. >>From the user's perspective, it's easier to think in terms of > accomplishing a specific task. If I want to set user/group/permissions > for a specific file, I'd find it more intuitive to use "USERGROUP" > prefix rather than "PROTOTYPE", even though it's where the tweaking > takes place under the hood. How about the following? > > USERGROUP_PASSWD = /etc/opt/csw/pkg/CSWfoo/cswusergroup > USERGROUP_MODIFIERS = mytweaks > USERGROUP_mytweaks_USER = mysql > USERGROUP_mytweaks_GROUP = mysql > USERGROUP_mytweaks_PERMS = 0700 > USERGROUP_mytweaks_FILES = /var/opt/csw/mysql5 I don't quite like the PROTOTYPE_ prefix from a user perspective when it comes to variable naming (it exposes internal details), but it feels a bit cleaner to me right now. 1) Generic: possible prototype adjustments are not restricted to USERGROUP related actions. You might only want to set the suid bit for example. 2) Consistent naming: GAR has a suffix way of declaring things right now (PKGFILES_, CATALOGNAME_, ...), which i think we should be consistent with when it comes to new features. Sebastian From skayser at opencsw.org Tue Sep 22 11:18:49 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 11:18:49 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> Message-ID: <4AB89679.1040007@opencsw.org> Maciej (Matchek) Blizinski wrote on 22.09.2009 10:02: > On Tue, Sep 22, 2009 at 8:38 AM, Peter Bonivart wrote: >> On Tue, Sep 22, 2009 at 9:30 AM, Maciej (Matchek) Blizinski >> wrote: >>> Is it CLASSES as described at [1] or SPKG_CLASSES as used in [2]? >> It's CLASSES when doing manual stuff in pkginfo and it's SPKG_CLASSES >> when using mGAR v2. But now it's even simpler to do when using GAR so >> you don't even have to bother with setting the classes. > > I've read the instructions on the and they don't seem complete to me. > There are 2 things needed to set the file ownership: > > 1. A file defining users and groups (USERGROUP = ...) > 2. A prototype with the ugfiles class > > The second bit needs to be done by filtering the prototype, is that > right? A sample piece of code: > > USERGROUP = /opt/csw/etc/pkg/CSWmysql5/cswusergroup > PROTOTYPE_FILTER = awk ' \ > $$$$3 ~ /\/var\/opt\/csw\/mysql5$$$$/ { $$$$2 = "ugfiles"; \ > $$$$4 = "0700"; \ > $$$$5 = "mysql"; \ > $$$$6 = "mysql" } \ > { print }' > SPKG_CLASSES = none ugfiles > > Without the last line (SPKG_CLASSES), my ugfiles-class file wasn't > created on the disk during package installation. Does everything works as desired with the above setup? I could see a possible problem as the USERGROUP related class which takes care of adding the user/group (cswusergroup) is automatically _appended_ to the SPKG_CLASSES variable by GAR. IIRC correctly however, it must be listed _before_ the class ugfiles class, which lists files that should have their ownership set to such newly created accounts. Sebastian From bonivart at opencsw.org Tue Sep 22 11:28:58 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 22 Sep 2009 11:28:58 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <4AB89679.1040007@opencsw.org> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <4AB89679.1040007@opencsw.org> Message-ID: <625385e30909220228oabd2ab2n3844e75489b2202b@mail.gmail.com> On Tue, Sep 22, 2009 at 11:18 AM, Sebastian Kayser wrote: > I could see a possible problem as the USERGROUP related class which > takes care of adding the user/group (cswusergroup) is automatically > _appended_ to the SPKG_CLASSES variable by GAR. > > IIRC correctly however, it must be listed _before_ the class ugfiles > class, which lists files that should have their ownership set to such > newly created accounts. Yes, you're right. The cswusergroup needs to create the user/groups before any files can be assigned to them (with ugfiles). -- /peter From skayser at opencsw.org Tue Sep 22 11:44:49 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 11:44:49 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <625385e30909220228oabd2ab2n3844e75489b2202b@mail.gmail.com> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <4AB89679.1040007@opencsw.org> <625385e30909220228oabd2ab2n3844e75489b2202b@mail.gmail.com> Message-ID: <4AB89C91.7040707@opencsw.org> Peter Bonivart wrote on 22.09.2009 11:28: > On Tue, Sep 22, 2009 at 11:18 AM, Sebastian Kayser wrote: >> I could see a possible problem as the USERGROUP related class which >> takes care of adding the user/group (cswusergroup) is automatically >> _appended_ to the SPKG_CLASSES variable by GAR. >> >> IIRC correctly however, it must be listed _before_ the class ugfiles >> class, which lists files that should have their ownership set to such >> newly created accounts. > > Yes, you're right. The cswusergroup needs to create the user/groups > before any files can be assigned to them (with ugfiles). Ok, while the ugfiles handling is not more tightly integrated into GAR (Dago, already hacking? ;), one needs to also explicitly add the cswusergroup class to SPKG_CLASSES. SPKG_CLASSES = none cswusergroup ugfiles Sebastian From dam at opencsw.org Tue Sep 22 11:58:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 11:58:45 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <4AB89C91.7040707@opencsw.org> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <4AB89679.1040007@opencsw.org> <625385e30909220228oabd2ab2n3844e75489b2202b@mail.gmail.com> <4AB89C91.7040707@opencsw.org> Message-ID: <2E8DDCE4-C585-4BD9-A627-1CAD070A48DA@opencsw.org> Hi Sebastian, Am 22.09.2009 um 11:44 schrieb Sebastian Kayser: > Peter Bonivart wrote on 22.09.2009 11:28: >> On Tue, Sep 22, 2009 at 11:18 AM, Sebastian Kayser > > wrote: >>> I could see a possible problem as the USERGROUP related class which >>> takes care of adding the user/group (cswusergroup) is automatically >>> _appended_ to the SPKG_CLASSES variable by GAR. >>> >>> IIRC correctly however, it must be listed _before_ the class ugfiles >>> class, which lists files that should have their ownership set to >>> such >>> newly created accounts. >> >> Yes, you're right. The cswusergroup needs to create the user/groups >> before any files can be assigned to them (with ugfiles). > > Ok, while the ugfiles handling is not more tightly integrated into GAR > one needs to also explicitly add the > cswusergroup class to SPKG_CLASSES. > > SPKG_CLASSES = none cswusergroup ugfiles This should be done automatically in the right order, yes. > Sebastian > (Dago, already hacking? ;) Yes, on your X11 stuff :-P From skayser at opencsw.org Tue Sep 22 12:13:22 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 12:13:22 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <2E8DDCE4-C585-4BD9-A627-1CAD070A48DA@opencsw.org> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <4AB89679.1040007@opencsw.org> <625385e30909220228oabd2ab2n3844e75489b2202b@mail.gmail.com> <4AB89C91.7040707@opencsw.org> <2E8DDCE4-C585-4BD9-A627-1CAD070A48DA@opencsw.org> Message-ID: <4AB8A342.8000905@opencsw.org> Dagobert Michelsen wrote on 22.09.2009 11:58: > Am 22.09.2009 um 11:44 schrieb Sebastian Kayser: >> Peter Bonivart wrote on 22.09.2009 11:28: >>> On Tue, Sep 22, 2009 at 11:18 AM, Sebastian Kayser >>> wrote: >>>> I could see a possible problem as the USERGROUP related class which >>>> takes care of adding the user/group (cswusergroup) is automatically >>>> _appended_ to the SPKG_CLASSES variable by GAR. >>>> >>>> IIRC correctly however, it must be listed _before_ the class ugfiles >>>> class, which lists files that should have their ownership set to >>>> such >>>> newly created accounts. >>> Yes, you're right. The cswusergroup needs to create the user/groups >>> before any files can be assigned to them (with ugfiles). >> Ok, while the ugfiles handling is not more tightly integrated into GAR >> one needs to also explicitly add the >> cswusergroup class to SPKG_CLASSES. >> >> SPKG_CLASSES = none cswusergroup ugfiles > > This should be done automatically in the right order, yes. > >> Sebastian > >> (Dago, already hacking? ;) > > Yes, on your X11 stuff :-P Hehe :) I just saw your commits, following the libXmu dependency chain, thanks alot. Very, very much appreciated. Sebastian From dam at opencsw.org Tue Sep 22 13:06:35 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 13:06:35 +0200 Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s Message-ID: Hi Sebastian, Am 22.09.2009 um 12:13 schrieb Sebastian Kayser: > Hehe :) I just saw your commits, following the libXmu dependency > chain, > thanks alot. Very, very much appreciated. You can try out libXmu on test8s now. Please let me know if it works, there are 5 packages in a row to be updated, so the full release will take some time. Best regards -- Dago From skayser at opencsw.org Tue Sep 22 14:02:49 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 14:02:49 +0200 (CEST) Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s In-Reply-To: References: Message-ID: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> Dagobert Michelsen wrote: > Am 22.09.2009 um 12:13 schrieb Sebastian Kayser: >> Hehe :) I just saw your commits, following the libXmu dependency >> chain, >> thanks alot. Very, very much appreciated. > > You can try out libXmu on test8s now. Please let me know if it > works, there are 5 packages in a row to be updated, so the full > release will take some time. Mhh, on test8s ./configure fails to find a libXaw checking for XawSimpleMenuAddGlobalActions in -lXaw -lXmu... no checking for XawSimpleMenuAddGlobalActions in -lXaw -lXpm -lXmu... no checking for XawSimpleMenuAddGlobalActions in -lXaw_s -lXmu_s... no checking for -lXaw -lXmu in /usr/contrib/X11R6... no checking for -lXaw -lXpm -lXmu in /usr/contrib/X11R6... no checking for -lXaw_s -lXmu_s in /usr/contrib/X11R6... no checking for -lXaw -lXmu in /usr/contrib/X11R5... no checking for -lXaw -lXpm -lXmu in /usr/contrib/X11R5... no checking for -lXaw_s -lXmu_s in /usr/contrib/X11R5... no checking for -lXaw -lXmu in /usr/lib/X11R5... no checking for -lXaw -lXpm -lXmu in /usr/lib/X11R5... no checking for -lXaw_s -lXmu_s in /usr/lib/X11R5... no checking for -lXaw -lXmu in /usr/local... no checking for -lXaw -lXpm -lXmu in /usr/local... no checking for -lXaw_s -lXmu_s in /usr/local... no configure: error: Unable to successfully link Athena library (-lXaw) with test program config.log holds many lines similar to configure:8632: checking for XawSimpleMenuAddGlobalActions in -lXaw -lXmu configure:8648: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 -xarch=v8 -I/opt/csw/include -I/opt/csw/include -D__EXTENSIONS__ -I/opt/csw/X11/include -L/opt/csw/X11/lib -R/opt/csw/X11/lib -xarch=v8 -L/opt/csw/lib conftest.c -lXaw -lXmu -lXext -lXt -lSM -lICE -lX11 -ltermcap -lsocket -lnsl >&5 "configure", line 8641: warning: implicit function declaration: XawSimpleMenuAddGlobalActions Undefined first referenced symbol in file XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 ld: fatal: Symbol referencing errors. No output written to conftest Why is trying to link with the stock libX11.so.4 at all (our CSW X11 doesn't have a reference to XSolarisIASetProcessInfo). Do we need a CSW libxaw also? XSolarisIASetProcessInfo is contained in the stock libXext, not in the CSW Xext for what it matters (although i don't think that makes a difference, -lXext is listed before -lX11 on the cc invocation line). skayser @ build8st ~/mgar/pkg/xterm/trunk$ nm -p /opt/csw/X11/lib/libXext.so* | grep XSolarisIASetProcessInfo skayser @ build8st ~/mgar/pkg/xterm/trunk$ nm -p /usr/openwin/lib/libXext.so* | grep XSolarisIASetProcessInfo 0000047132 T XSolarisIASetProcessInfo 0000047132 T XSolarisIASetProcessInfo Sebastian From dam at opencsw.org Tue Sep 22 15:58:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 15:58:22 +0200 Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s In-Reply-To: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> References: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> Message-ID: <288EC8C8-176E-4F74-84E2-F2D596AE86AD@opencsw.org> Hi Sebastian, Am 22.09.2009 um 14:02 schrieb Sebastian Kayser: > Mhh, on test8s ./configure fails to find a libXaw libXaw is packaged and installed on test8s. Please try again. Best regards -- Dago From daniel at opencsw.org Tue Sep 22 16:20:04 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Tue, 22 Sep 2009 15:20:04 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB24B1B.6020101@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> Message-ID: <4AB8DD14.4050606@opencsw.org> Daniel Pocock wrote: > Sebastian Kayser wrote: >> Daniel Pocock schrieb: >> > Sebastian Kayser wrote: >> >> Daniel Pocock wrote: >> >>> Thanks for all the assistance and feedback about the CSW packaging >> >> process >> >>> I've finally got the unofficial 3.1.3 code into testing now - >> feedback >> >>> is welcome >> >> your packages have the UNCOMMITED status (see their file names), which >> >> means that you had uncommitted local changes when building the >> package. >> >> UNCOMITTED packages won't be considered for the testing catalog. >> >> >> >> Issue 'svn status' to see which files are still uncomitted, take >> care of >> >> them (commit or branch if necessary), rebuild the packages and replace >> >> the >> >> current ones in /home/testing. >> > That is because I don't want to commit the checksum for >> > ganglia-3.1.3.tar.gz as it is not an official release >> > >> > There are a couple of Makefile changes that are safe to commit though. >> > I'm planning to tag 3.1.3 upstream on Friday, but I would like to get >> > feedback from OpenCSW users before I do that. >> >> You could simply create a branch to work on the upcoming release. >> >> ~/mgar/pkg/ganglia$ svn cp trunk/ branches/ganglia-3.1.3-rc >> > > Thanks for the advice about this - I have done as you suggest, and now > the new packages are in testing again > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers Ganglia 3.1.3 is now out on http://ganglia.info/testing and the version in OpenCSW testing has been updated. It is basically the same as the packages I built last week in OpenCSW testing, with two more minor patches added just before release. Has anyone tried these packages? I would appreciate some feedback before moving them to newpkgs Dago, are you happy to install them on the build farm? If so, please let me know the name of the server where ganglia_web is installed, so I can check the web interface. From dam at opencsw.org Tue Sep 22 16:26:23 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 16:26:23 +0200 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB8DD14.4050606@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> Message-ID: <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> Hi Daniel, Am 22.09.2009 um 16:20 schrieb Daniel Pocock: > Ganglia 3.1.3 is now out on http://ganglia.info/testing and the > version in OpenCSW testing has been updated. > > It is basically the same as the packages I built last week in > OpenCSW testing, with two more minor patches added just before > release. > > Has anyone tried these packages? I would appreciate some feedback > before moving them to newpkgs > > Dago, are you happy to install them on the build farm? If so, > please let me know the name of the server where ganglia_web is > installed, so I can check the web interface. Cool, would you mind writing up some mini-docs on what to install on which machine at so I can install it? Best regards -- Dago From skayser at opencsw.org Tue Sep 22 16:38:04 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 16:38:04 +0200 (CEST) Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s In-Reply-To: <288EC8C8-176E-4F74-84E2-F2D596AE86AD@opencsw.org> References: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> <288EC8C8-176E-4F74-84E2-F2D596AE86AD@opencsw.org> Message-ID: <51002.194.246.122.22.1253630284.squirrel@ssl.skayser.de> Dagobert Michelsen wrote: > Am 22.09.2009 um 14:02 schrieb Sebastian Kayser: >> Mhh, on test8s ./configure fails to find a libXaw > > libXaw is packaged and installed on test8s. Please try again. Thanks. xterm now builds without hickups on test8s. :D Would you mind placing the whole Xlibs stack that you produced today in testing/ so that i can install these pkgs on a test system and see whether they work fine with X applications that were compiled previously. Sebastian From daniel at opencsw.org Tue Sep 22 16:48:25 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Tue, 22 Sep 2009 15:48:25 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> Message-ID: <4AB8E3B9.9050302@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 22.09.2009 um 16:20 schrieb Daniel Pocock: > > Ganglia 3.1.3 is now out on http://ganglia.info/testing and the > > version in OpenCSW testing has been updated. > > > > It is basically the same as the packages I built last week in OpenCSW > > testing, with two more minor patches added just before release. > > > > Has anyone tried these packages? I would appreciate some feedback > > before moving them to newpkgs > > > > Dago, are you happy to install them on the build farm? If so, please > > let me know the name of the server where ganglia_web is installed, so > > I can check the web interface. > > Cool, would you mind writing up some mini-docs on what to install on which > machine at > > so I can install it? It's easier than that: - install ganglia_agent on every machine - install ganglia_web on the machine where you want to see the reports (it requires apache2) - probably a public web server - browse to http:///ganglia/ Everything should work automatically (after you restart apache2 perhaps, although you will see a message about that) From dam at opencsw.org Tue Sep 22 17:43:23 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 17:43:23 +0200 Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s In-Reply-To: <51002.194.246.122.22.1253630284.squirrel@ssl.skayser.de> References: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> <288EC8C8-176E-4F74-84E2-F2D596AE86AD@opencsw.org> <51002.194.246.122.22.1253630284.squirrel@ssl.skayser.de> Message-ID: <174F9942-4741-4EDA-BB7C-E4528909D62A@opencsw.org> Hi Sebastian, Am 22.09.2009 um 16:38 schrieb Sebastian Kayser: > Dagobert Michelsen wrote: >> Am 22.09.2009 um 14:02 schrieb Sebastian Kayser: >>> Mhh, on test8s ./configure fails to find a libXaw >> >> libXaw is packaged and installed on test8s. Please try again. > > Thanks. xterm now builds without hickups on test8s. :D > > Would you mind placing the whole Xlibs stack that you produced today > in > testing/ so that i can install these pkgs on a test system and see > whether > they work fine with X applications that were compiled previously. Here is a sparc-only subset, compiled on build8st, with custom-made catalog for overlay: Best regards -- Dago From dam at opencsw.org Tue Sep 22 17:50:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 17:50:32 +0200 Subject: [csw-maintainers] Fwd: X11 lib consolidation: libXmu on test8s References: <174F9942-4741-4EDA-BB7C-E4528909D62A@opencsw.org> Message-ID: <48E317B4-50CC-4E64-9C54-BC9ABFEC0288@opencsw.org> Hi Phil, Anfang der weitergeleiteten E-Mail: > Am 22.09.2009 um 16:38 schrieb Sebastian Kayser: >> Dagobert Michelsen wrote: >>> Am 22.09.2009 um 14:02 schrieb Sebastian Kayser: >>>> Mhh, on test8s ./configure fails to find a libXaw >>> >>> libXaw is packaged and installed on test8s. Please try again. >> >> Thanks. xterm now builds without hickups on test8s. :D >> >> Would you mind placing the whole Xlibs stack that you produced >> today in >> testing/ so that i can install these pkgs on a test system and see >> whether >> they work fine with X applications that were compiled previously. > > Here is a sparc-only subset, compiled on build8st, with custom-made > catalog > for overlay: > There is also an update of libxpm which you currently maintain. As it now belongs to X11 I have made a new package CSWlibxpm located in /opt/csw/X11 and a stub CSWxpm depending on it with links to the X11 libs. Additionally, it contains the pkgconfig .pc-files which are now mandatory for the depending libraries. Please take a look if this suits your needs. Best regards -- Dago From dam at opencsw.org Tue Sep 22 18:28:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 18:28:51 +0200 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB8E3B9.9050302@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> Message-ID: <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> Hi Daniel, Am 22.09.2009 um 16:48 schrieb Daniel Pocock: > Dagobert Michelsen wrote: >> Hi Daniel, >> >> Am 22.09.2009 um 16:20 schrieb Daniel Pocock: >> > Ganglia 3.1.3 is now out on http://ganglia.info/testing and the >> > version in OpenCSW testing has been updated. >> > >> > It is basically the same as the packages I built last week in >> OpenCSW >> > testing, with two more minor patches added just before release. >> > >> > Has anyone tried these packages? I would appreciate some feedback >> > before moving them to newpkgs >> > >> > Dago, are you happy to install them on the build farm? If so, >> please >> > let me know the name of the server where ganglia_web is >> installed, so >> > I can check the web interface. >> >> Cool, would you mind writing up some mini-docs on what to install >> on which >> machine at >> >> so I can install it? > > It's easier than that: > > - install ganglia_agent on every machine > > - install ganglia_web on the machine where you want to see the > reports (it requires apache2) - probably a public web server > > - browse to http:///ganglia/ > > Everything should work automatically (after you restart apache2 > perhaps, although you will see a message about that) You still have UNCOMMITTED in your package. Please commit all you have and make sure it has CSW instead in it. That way you can release the packages immediately after testing. Best regards -- Dago From daniel at opencsw.org Tue Sep 22 18:33:48 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Tue, 22 Sep 2009 17:33:48 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> Message-ID: <4AB8FC6C.9080701@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 22.09.2009 um 16:48 schrieb Daniel Pocock: >> Dagobert Michelsen wrote: >>> Hi Daniel, >>> >>> Am 22.09.2009 um 16:20 schrieb Daniel Pocock: >>> > Ganglia 3.1.3 is now out on http://ganglia.info/testing and the >>> > version in OpenCSW testing has been updated. >>> > >>> > It is basically the same as the packages I built last week in OpenCSW >>> > testing, with two more minor patches added just before release. >>> > >>> > Has anyone tried these packages? I would appreciate some feedback >>> > before moving them to newpkgs >>> > >>> > Dago, are you happy to install them on the build farm? If so, please >>> > let me know the name of the server where ganglia_web is installed, so >>> > I can check the web interface. >>> >>> Cool, would you mind writing up some mini-docs on what to install on >>> which >>> machine at >>> >>> so I can install it? >> >> It's easier than that: >> >> - install ganglia_agent on every machine >> >> - install ganglia_web on the machine where you want to see the reports >> (it requires apache2) - probably a public web server >> >> - browse to http:///ganglia/ >> >> Everything should work automatically (after you restart apache2 >> perhaps, although you will see a message about that) > > You still have UNCOMMITTED in your package. Please commit all you have > and make sure it has CSW instead in it. That way you can release the > packages immediately after testing. > It is still officially a beta until the Ganglia community endorses it as GA - usually 1-2 weeks after tagging, if no one has found a major fault. I saw a message earlier that said I can't release properly until it passes upstreams `beta' phase. Can we test it anyway, and then I will commit and put it in newpkgs when it is officially GA? From maciej at opencsw.org Tue Sep 22 18:38:04 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 17:38:04 +0100 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <4AB89426.3090903@opencsw.org> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> <4AB89426.3090903@opencsw.org> Message-ID: On Tue, Sep 22, 2009 at 10:08 AM, Sebastian Kayser wrote: > I don't quite like the PROTOTYPE_ prefix from a user perspective when it > comes to variable naming (it exposes internal details), but it feels a > bit cleaner to me right now. > > 1) Generic: possible prototype adjustments are not restricted to > USERGROUP related actions. You might only want to set the suid bit for > example. The values from USERGROUP_* can be passed along (aliases?) for PROTOTYPE_* variables. > 2) Consistent naming: GAR has a suffix way of declaring things right now > (PKGFILES_, CATALOGNAME_, ...), which i think we should be consistent > with when it comes to new features. The reason why I wrote USERGROUP_mytweaks_USER instead of USERGROUP_USER_mytweaks is because the latter suggests that there's "the" user for USERGROUP. Perhaps it's just me. I don't insist, anyway, I just think it's more intuitive, because it follows the logic of getting from the general to the specific: first, I know I'm going to do something with users and groups; second, I know I'm going to have a name for a specific tweak I'm doing; and third, I know what specifics is my tweak going to have. But I don't insist, if others think that suffix is better, I don't have a problem with it. It just has to be well-documented, and GAR stuff usually is well documented. (yey for the GAR Variable Reference page!) Maciej From dam at opencsw.org Tue Sep 22 18:57:21 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 18:57:21 +0200 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB8FC6C.9080701@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> <4AB8FC6C.9080701@opencsw.org> Message-ID: <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> Hi Daniel, Am 22.09.2009 um 18:33 schrieb Daniel Pocock: > It is still officially a beta until the Ganglia community endorses > it as GA - usually 1-2 weeks after tagging, if no one has found a > major fault. I saw a message earlier that said I can't release > properly until it passes upstreams `beta' phase. > > Can we test it anyway, and then I will commit and put it in newpkgs > when it is officially GA? I could if I would install the packages manually. But as we have the commit policy "commit early, commit often" there really is no need to have any package in testing with UNCOMMITTED in it as it only makes things harder. Additionally, if I want to look into your recipe I can't do that right now as you haven't committed everything. Best regards -- Dago From dam at opencsw.org Tue Sep 22 19:03:15 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 19:03:15 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> <4AB89426.3090903@opencsw.org> Message-ID: Hi Mcaiej, Am 22.09.2009 um 18:38 schrieb Maciej (Matchek) Blizinski: >> 2) Consistent naming: GAR has a suffix way of declaring things >> right now >> (PKGFILES_, CATALOGNAME_, ...), which i think we should be consistent >> with when it comes to new features. > > The reason why I wrote USERGROUP_mytweaks_USER instead of > USERGROUP_USER_mytweaks is because the latter suggests that there's > "the" user for USERGROUP. Perhaps it's just me. I don't insist, > anyway, I just think it's more intuitive, because it follows the logic > of getting from the general to the specific: first, I know I'm going > to do something with users and groups; second, I know I'm going to > have a name for a specific tweak I'm doing; and third, I know what > specifics is my tweak going to have. Right, but OTOH we currently have two types of variables with expansions in it: _ for most of them and _----... for modulations. Introducing in the middle makes it clearer in one thing and more irregular in another thing. I would prefer regularity over intuitivity. Best regards -- Dago From maciej at opencsw.org Tue Sep 22 19:55:20 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 18:55:20 +0100 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> <4AB89426.3090903@opencsw.org> Message-ID: On Tue, Sep 22, 2009 at 6:03 PM, Dagobert Michelsen wrote: > Hi Mcaiej, > > Am 22.09.2009 um 18:38 schrieb Maciej (Matchek) Blizinski: >>> >>> 2) Consistent naming: GAR has a suffix way of declaring things right now >>> (PKGFILES_, CATALOGNAME_, ...), which i think we should be consistent >>> with when it comes to new features. >> >> The reason why I wrote USERGROUP_mytweaks_USER instead of >> USERGROUP_USER_mytweaks is because the latter suggests that there's >> "the" user for USERGROUP. Perhaps it's just me. I don't insist, >> anyway, I just think it's more intuitive, because it follows the logic >> of getting from the general to the specific: first, I know I'm going >> to do something with users and groups; second, I know I'm going to >> have a name for a specific tweak I'm doing; and third, I know what >> specifics is my tweak going to have. > > Right, but OTOH we currently have two types of variables with > expansions in it: _ for most of them and > _----... for modulations. > Introducing in the middle makes it clearer in > one thing and more irregular in another thing. I would > prefer regularity over intuitivity. It would fit well with a German stereotype. ;-) Okay, so keeping it regular and subintuitive, we'd have: PROTOTYPE_MODIFIERS = mytweaks PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf PROTOTYPE_PERMS_mytweaks = 0644 PROTOTYPE_CLASS_mytweaks = cswconffile PROTOTYPE_USER_mytweaks = somebody PROTOTYPE_GROUP_mytweaks = somegroup I'm fine with the above. By the way, I'm having this problem: A line in the Makefile SAMPLECONF = $(sysconfdir)/cups/cupsd\.conf\.CSW The problem: The file in the prototype doesn't have the correct class: $ ggrep conf\\.CSW work/build-global/*prototype work/build-global/CSWcupsd.prototype:f none /etc/opt/csw/cups/cupsd.conf.CSW 0644 root bin work/build-global/prototype:f none /etc/opt/csw/cups/cupsd.conf.CSW 0644 root bin How to debug it? Maciej From skayser at opencsw.org Tue Sep 22 20:30:42 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 20:30:42 +0200 Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s In-Reply-To: <174F9942-4741-4EDA-BB7C-E4528909D62A@opencsw.org> References: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> <288EC8C8-176E-4F74-84E2-F2D596AE86AD@opencsw.org> <51002.194.246.122.22.1253630284.squirrel@ssl.skayser.de> <174F9942-4741-4EDA-BB7C-E4528909D62A@opencsw.org> Message-ID: <4AB917D2.7020200@opencsw.org> Dagobert Michelsen wrote on 22.09.2009 17:43: > Am 22.09.2009 um 16:38 schrieb Sebastian Kayser: >> Dagobert Michelsen wrote: >>> Am 22.09.2009 um 14:02 schrieb Sebastian Kayser: >>>> Mhh, on test8s ./configure fails to find a libXaw >>> libXaw is packaged and installed on test8s. Please try again. >> Thanks. xterm now builds without hickups on test8s. :D >> >> Would you mind placing the whole Xlibs stack that you produced today >> in >> testing/ so that i can install these pkgs on a test system and see >> whether >> they work fine with X applications that were compiled previously. > > Here is a sparc-only subset, compiled on build8st, with custom-made > catalog > for overlay: > Thanks, but my dedicated testing box at work is i386, unfortunately. Should have mentioned that earlier :/ Sebastian From maciej at opencsw.org Tue Sep 22 21:26:16 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 20:26:16 +0100 Subject: [csw-maintainers] Shared library search path with $ISALIST in the middle Message-ID: I'm working on packaging MySQL-5.0.x. I'm having a following problem: When making a 64-bit build, during the install phase, the following tree structure is being created: work/install-isa-amd64/opt/csw/mysql5/lib `-- 64 `-- mysql |-- libdbug.a |-- libheap.a |-- libmyisam.a |-- libmyisammrg.a |-- libmysqlclient.a |-- libmysqlclient.la |-- libmysqlclient.so -> libmysqlclient.so.15.0.0 |-- libmysqlclient.so.15 -> libmysqlclient.so.15.0.0 |-- libmysqlclient.so.15.0.0 |-- libmystrings.a |-- libmysys.a `-- libvio.a 2 directories, 12 files After building a package, the following files are in the package prototype: d none /opt/csw/mysql5/lib/amd64/mysql 0755 root bin s none /opt/csw/mysql5/lib/amd64/mysql/libmysqlclient.so=libmysqlclient.so.15.0.0 s none /opt/csw/mysql5/lib/amd64/mysql/libmysqlclient.so.15=libmysqlclient.so.15.0.0 f none /opt/csw/mysql5/lib/amd64/mysql/libmysqlclient.so.15.0.0 0755 root bin When running the 'mysql' binary, I'm getting an error: $ mysql ld.so.1: mysql: fatal: libmysqlclient.so.15: open failed: No such file or directory Killed The reason is that the binary is not looking into the directories containing the shared libraries. The difference is: the existing file: .../amd64/mysql/libmysqlclient.so the program is looking for: .../mysql/amd64/libmysqlclient.so Can set the runtime library path to .../amd64/mysql/libmysqlclient.so? Is the following line the right thing to do? EXTRA_LIB = /opt/csw/mysql5/lib/$$ISALIST/mysql Maciej From maciej at opencsw.org Tue Sep 22 21:50:49 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 20:50:49 +0100 Subject: [csw-maintainers] Shared library search path with $ISALIST in the middle In-Reply-To: References: Message-ID: On Tue, Sep 22, 2009 at 8:26 PM, Maciej (Matchek) Blizinski wrote: > Can set the runtime library path to .../amd64/mysql/libmysqlclient.so? > Is the following line the right thing to do? > > EXTRA_LIB = /opt/csw/mysql5/lib/$$ISALIST/mysql Okay, I figured that out. The answer is: yes. :-) Maciej From dam at opencsw.org Tue Sep 22 22:10:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 22:10:19 +0200 Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s In-Reply-To: <4AB917D2.7020200@opencsw.org> References: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> <288EC8C8-176E-4F74-84E2-F2D596AE86AD@opencsw.org> <51002.194.246.122.22.1253630284.squirrel@ssl.skayser.de> <174F9942-4741-4EDA-BB7C-E4528909D62A@opencsw.org> <4AB917D2.7020200@opencsw.org> Message-ID: <7218BE1B-147E-4F31-A5F6-05F1085B3A3B@opencsw.org> Hi Sebastian, Am 22.09.2009 um 20:30 schrieb Sebastian Kayser: > Dagobert Michelsen wrote on 22.09.2009 17:43: >> Am 22.09.2009 um 16:38 schrieb Sebastian Kayser: >>> Dagobert Michelsen wrote: >>>> Am 22.09.2009 um 14:02 schrieb Sebastian Kayser: >>>>> Mhh, on test8s ./configure fails to find a libXaw >>>> libXaw is packaged and installed on test8s. Please try again. >>> Thanks. xterm now builds without hickups on test8s. :D >>> >>> Would you mind placing the whole Xlibs stack that you produced today >>> in >>> testing/ so that i can install these pkgs on a test system and see >>> whether >>> they work fine with X applications that were compiled previously. >> >> Here is a sparc-only subset, compiled on build8st, with custom-made >> catalog >> for overlay: >> > > Thanks, but my dedicated testing box at work is i386, unfortunately. > Should have mentioned that earlier :/ I can't package that up as there currently is no test10x. Sorry. I'll package and release one-after-another then. Best regards -- Dago From dam at opencsw.org Tue Sep 22 22:20:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 22:20:55 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> <4AB89426.3090903@opencsw.org> Message-ID: <80A6B044-67BE-4213-AD52-F20F88B9C02D@opencsw.org> Hi Maciej, Am 22.09.2009 um 19:55 schrieb Maciej (Matchek) Blizinski: > On Tue, Sep 22, 2009 at 6:03 PM, Dagobert Michelsen > wrote: >> Am 22.09.2009 um 18:38 schrieb Maciej (Matchek) Blizinski: >>>> 2) Consistent naming: GAR has a suffix way of declaring things >>>> right now >>>> (PKGFILES_, CATALOGNAME_, ...), which i think we should be >>>> consistent >>>> with when it comes to new features. >>> >>> The reason why I wrote USERGROUP_mytweaks_USER instead of >>> USERGROUP_USER_mytweaks is because the latter suggests that there's >>> "the" user for USERGROUP. Perhaps it's just me. I don't insist, >>> anyway, I just think it's more intuitive, because it follows the >>> logic >>> of getting from the general to the specific: first, I know I'm going >>> to do something with users and groups; second, I know I'm going to >>> have a name for a specific tweak I'm doing; and third, I know what >>> specifics is my tweak going to have. >> >> Right, but OTOH we currently have two types of variables with >> expansions in it: _ for most of them and >> _----... for modulations. >> Introducing in the middle makes it clearer in >> one thing and more irregular in another thing. I would >> prefer regularity over intuitivity. > > It would fit well with a German stereotype. ;-) I TEK DIS AS KOMPLIMENT, YES :-D > Okay, so keeping it regular and subintuitive, we'd have: > > PROTOTYPE_MODIFIERS = mytweaks > PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf > PROTOTYPE_PERMS_mytweaks = 0644 > PROTOTYPE_CLASS_mytweaks = cswconffile > PROTOTYPE_USER_mytweaks = somebody > PROTOTYPE_GROUP_mytweaks = somegroup and possibly PROTOTYPE_FTYPE_mytweaks = e I guess we won't have many devices, so no need to bother. > I'm fine with the above. > > By the way, I'm having this problem: > > A line in the Makefile > SAMPLECONF = $(sysconfdir)/cups/cupsd\.conf\.CSW > > The problem: The file in the prototype doesn't have the correct class: > $ ggrep conf\\.CSW work/build-global/*prototype > work/build-global/CSWcupsd.prototype:f none > /etc/opt/csw/cups/cupsd.conf.CSW 0644 root bin > work/build-global/prototype:f none /etc/opt/csw/cups/cupsd.conf.CSW > 0644 root bin > > How to debug it? Try DEBUG_PACKAGING=1 gmake repackage and see what is executed during prototype filtering. Best regards -- Dago From dam at opencsw.org Tue Sep 22 22:21:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 22:21:49 +0200 Subject: [csw-maintainers] Shared library search path with $ISALIST in the middle In-Reply-To: References: Message-ID: <69FF07E5-B559-4702-9FCD-75DFF992ABA9@opencsw.org> Hi Maciej, Am 22.09.2009 um 21:50 schrieb Maciej (Matchek) Blizinski: > On Tue, Sep 22, 2009 at 8:26 PM, Maciej (Matchek) Blizinski > wrote: >> Can set the runtime library path to .../amd64/mysql/ >> libmysqlclient.so? >> Is the following line the right thing to do? >> >> EXTRA_LIB = /opt/csw/mysql5/lib/$$ISALIST/mysql > > Okay, I figured that out. The answer is: yes. :-) Yes. That is exactly what EXTRA_LIB is for :-) Best regards -- Dago From william at wbonnet.net Wed Sep 23 00:10:40 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 23 Sep 2009 00:10:40 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates Message-ID: <4AB94B60.7010704@wbonnet.net> Hi The following packages have been updated or added to testing New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-i386-CSW.pkg.gz New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-sparc-CSW.pkg.gz New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz Feedbacks are welcome cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From phil at bolthole.com Wed Sep 23 00:27:01 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 22 Sep 2009 15:27:01 -0700 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4AB94B60.7010704@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> Message-ID: Dago and I were just exchanging emails. We came to the agreement, that packages containing "Xorg/X11 prototypes", should get standardized by naming them x[software]proto rather than just [software]proto the idea being, that way they'll sort nicer,and be more obviously identifyable. On Tue, Sep 22, 2009 at 3:10 PM, William Bonnet wrote: > Hi > > The following packages have been updated or added to testing > > New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz > New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz > Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz > Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz > New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-i386-CSW.pkg.gz > New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-sparc-CSW.pkg.gz > New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz > New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz > Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz > Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz > From william at wbonnet.net Wed Sep 23 08:00:26 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 23 Sep 2009 08:00:26 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> Message-ID: <4AB9B97A.800@wbonnet.net> Hi > the idea being, that way they'll sort nicer,and be more obviously identifyable. > I was waiting for your confirmation :) I'll rename the packages tonight before cheers W. > > > On Tue, Sep 22, 2009 at 3:10 PM, William Bonnet wrote: > >> Hi >> >> The following packages have been updated or added to testing >> >> New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-i386-CSW.pkg.gz >> New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-sparc-CSW.pkg.gz >> New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> >> > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > > > -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From dam at opencsw.org Wed Sep 23 08:17:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 23 Sep 2009 08:17:31 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> Message-ID: <6CC4D56C-2812-4B65-87EE-45D7CE36A802@opencsw.org> Hi William, Am 23.09.2009 um 00:27 schrieb Philip Brown: > Dago and I were just exchanging emails. > > We came to the agreement, that packages containing "Xorg/X11 > prototypes", should get standardized by naming them > > x[software]proto > > rather than just > > [software]proto > > > the idea being, that way they'll sort nicer,and be more obviously > identifyable. > > > > On Tue, Sep 22, 2009 at 3:10 PM, William Bonnet > wrote: >> Hi >> >> The following packages have been updated or added to testing >> >> New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-i386-CSW.pkg.gz >> New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-sparc-CSW.pkg.gz >> New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz Yes, it would be more consistent to have a mapping like this to make clear that the packages are x-related: Am 22.09.2009 um 23:45 schrieb Philip Brown: > On Tue, Sep 22, 2009 at 1:09 PM, Dagobert Michelsen > wrote: >> >> That means >> >> glproto -> xglproto >> inputproto -> xinputproto >> kbproto -> xkbproto >> recordproto -> xrecordproto >> renderproto -> xrenderproto >> videoproto -> xvideoproto >> xcb-proto -> SAME >> xextproto -> SAME >> xproto -> SAME >> >> OK? > > Yeah. > > Please remind me when the renames come up. Best regards -- Dago From dam at opencsw.org Wed Sep 23 08:30:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 23 Sep 2009 08:30:02 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4AB9B97A.800@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> Message-ID: Hi William, Am 23.09.2009 um 08:00 schrieb William Bonnet: >> the idea being, that way they'll sort nicer,and be more obviously >> identifyable. >> > > I was waiting for your confirmation :) > > I'll rename the packages tonight before >> On Tue, Sep 22, 2009 at 3:10 PM, William Bonnet >> wrote: >>> The following packages have been updated or added to testing >>> >>> New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >>> New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >>> Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >>> Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >>> New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-i386-CSW.pkg.gz >>> New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-sparc-CSW.pkg.gz >>> New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >>> New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >>> Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >>> Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz Very nice. Please keep in mind to also update the requirements of the other packages to accomodate for the changed name. It may be best to rename all at once and release the whole stack with updated dependencies in one large block to avoid re-releases of the same package again and again if it is dependent on multiple protos. Best regards -- Dago From skayser at opencsw.org Wed Sep 23 10:37:28 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 23 Sep 2009 10:37:28 +0200 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> Message-ID: <4AB9DE48.8060006@opencsw.org> Philip Brown wrote on 24.08.2009 21:01: > On Mon, Aug 24, 2009 at 12:27 AM, Maciej (Matchek) Blizinski > > wrote: > > +1 > > pyantlrrt --> py_antlrrt > pyyaml --> py_yaml > > How do we go about the change? Modify catalogname without touching > pkgname? Will the usual pkg-get/pkgutil update do the right thing? > > dependancies are based on CSWname, not software name, so it should "do > the right thing". The places where it will break, are where admins may > have saved procedures, that do things like: > > machine1$ pkg-get -l >save-list > #time passes... > machine2$ pkg-get -i `cat save-list` > > Not to mention, changing softwarename is kinda a pain for me to deal > with. But if there are "only a few", then all right. > > WITH THE EXCEPTION that, as someone noted, things with actual recognized > name of "pyfoo", should REMAIN "pyfoo", not be artificially split to be > "py_foo" in that case. I was just about to file the bugs against packages which don't have the py_ prefix. Just wanted to make sure we have reached a consensus here so that i file the bugs against the right set of packages: - python programs with a recognized name can/should be left as is - python libraries will be prefixed with py_ Resuming the pyyaml example: pyyaml is a library (python modules only), thus the software name would be py_yaml. This is similar to Debian's policy [1], just that they prefix module packages with "python-". In their case, pyyaml is packaged as python-yaml [2]. Sebastian [1]http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names [2]http://packages.debian.org/lenny/python-yaml From maciej at opencsw.org Wed Sep 23 10:38:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 09:38:46 +0100 Subject: [csw-maintainers] SAMPLECONF = $(sysconfdir)/foo\.conf issues Message-ID: On Tue, Sep 22, 2009 at 9:20 PM, Dagobert Michelsen wrote: >> By the way, I'm having this problem: >> >> A line in the Makefile >> SAMPLECONF = $(sysconfdir)/cups/cupsd\.conf\.CSW >> >> The problem: The file in the prototype doesn't have the correct class: >> $ ggrep conf\\.CSW work/build-global/*prototype >> work/build-global/CSWcupsd.prototype:f none >> /etc/opt/csw/cups/cupsd.conf.CSW 0644 root bin >> work/build-global/prototype:f none /etc/opt/csw/cups/cupsd.conf.CSW >> 0644 root bin >> >> How to debug it? > > Try > DEBUG_PACKAGING=1 gmake repackage > and see what is executed during prototype filtering. I tried a few combinations of "." and "\."; I then took a look at the output. 1. SAMPLECONF = $(sysconfdir)/cupsd\.conf\.CSW | perl -ane ' $F[1] = "cswcpsampleconf" if ( $F[2] =~ m(^/etc/opt/csw/cupsd\.conf\\.CSW$) ); Doesn't work. 2. SAMPLECONF = $(sysconfdir)/cupsd.conf.CSW | perl -ane ' $F[1] = "cswcpsampleconf" if ( $F[2] =~ m(^/etc/opt/csw/cupsd.conf\.CSW$) ); Does work (the class is being set). It doesn't seem quite right. If the value of SAMPLECONF is a regex, there should be no later backslash additions. If it's not a regex, backslashes should be added to all the dots (or other special characters). Maciej From maciej at opencsw.org Wed Sep 23 11:23:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 10:23:01 +0100 Subject: [csw-maintainers] The source code of www.opencsw.org In-Reply-To: References: <20090723220149.GB8541@bolthole.com> <4A6979F4.5050904@opencsw.org> <20090724160343.GC91227@bolthole.com> <4A6B4DFE.1050307@opencsw.org> <20090725203035.GA24170@bolthole.com> <4A6C2341.8060600@opencsw.org> <20090726154345.GB28096@bolthole.com> Message-ID: Re: http://www.opencsw.org/mantis/view.php?id=3459#c6709 The irforceready mirrors from our mirrors subpage currently point at Blastwave mirrors. I'm not going to propose a change*, because the administrative overhead is going to by far surpass the amount of work needed to fix the issue, so I'm only mentioning it here. Maciej * See how careful I am not to say "send a patch"? From dam at opencsw.org Wed Sep 23 12:26:28 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 12:26:28 +0200 (CEST) Subject: [csw-maintainers] SAMPLECONF = $(sysconfdir)/foo\.conf issues In-Reply-To: References: Message-ID: Hi Maciej, > I tried a few combinations of "." and "\."; I then took a look at the > output. > > 1. > SAMPLECONF = $(sysconfdir)/cupsd\.conf\.CSW > | perl -ane ' $F[1] = "cswcpsampleconf" if ( $F[2] =~ > m(^/etc/opt/csw/cupsd\.conf\\.CSW$) ); > > Doesn't work. > > 2. > SAMPLECONF = $(sysconfdir)/cupsd.conf.CSW > | perl -ane ' $F[1] = "cswcpsampleconf" if ( $F[2] =~ > m(^/etc/opt/csw/cupsd.conf\.CSW$) ); > > Does work (the class is being set). > > It doesn't seem quite right. If the value of SAMPLECONF is a regex, > there should be no later backslash additions. If it's not a regex, > backslashes should be added to all the dots (or other special > characters). This was a bug. It should be regular expressions, so 1. is correct. The bug was introduced was I autodetected if the file has a .CSW-suffix or not. It is fixed now in r6425, please verify. Thanks for the report! -- Dago From daniel at opencsw.org Wed Sep 23 12:54:28 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 23 Sep 2009 11:54:28 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> <4AB8FC6C.9080701@opencsw.org> <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> Message-ID: <4AB9FE64.1040209@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 22.09.2009 um 18:33 schrieb Daniel Pocock: >> It is still officially a beta until the Ganglia community endorses it >> as GA - usually 1-2 weeks after tagging, if no one has found a major >> fault. I saw a message earlier that said I can't release properly >> until it passes upstreams `beta' phase. >> >> Can we test it anyway, and then I will commit and put it in newpkgs >> when it is officially GA? > > I could if I would install the packages manually. But as we have the > commit policy "commit early, commit often" there really is no need to > have any package in testing with UNCOMMITTED in it as it only makes > things harder. Additionally, if I want to look into your recipe I can't > do that right now as you haven't committed everything. > Ok, I have now committed them on a branch and put them in testing again - please let me know which host you put the web package on so I can check it From daniel at opencsw.org Wed Sep 23 13:06:02 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 23 Sep 2009 12:06:02 +0100 Subject: [csw-maintainers] Using a package from current on stable Message-ID: <4ABA011A.8070809@opencsw.org> The Ganglia package I've been working with works on a wide range of architectures. I thought I would try to install the package on a Solaris 8 system with OpenCSW stable instead of current Two issues arise: - cswclassutils is missing on stable - expat.so.0 on stable, expat.so.1 expected for current Therefore, I suspect I need to - copy some additional things, e.g. cswclassutils, to the system where I want Ganglia - rebuild my package for stable's library versions - how do I tell gar to do that? Given that my package is a new package and doesn't impact any other packages, are there any other steps I need to take to make it suitable for an upcoming stable release? Will the use of cswclassutils prevent me from having the package in stable? From maciej at opencsw.org Wed Sep 23 13:17:40 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 12:17:40 +0100 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: <1251678005-sup-226@ntdws12.chass.utoronto.ca> References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <9D015FAC-931C-4DD3-A4AB-CC1AB214E9A9@opencsw.org> <7F956EB7-8E18-4052-B985-D360956F8626@opencsw.org> <1251391060-sup-388@ntdws12.chass.utoronto.ca> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> Message-ID: The packages have been built and they've been sitting in testing/ for a while now. I'd like to have them released, but there's a problem with dependent applications. Shared libraries in the updated wxwidgets packages have different file names than the version currently present on the mirrors. http://www.opencsw.org/search/wxwidgets_gtk2 contains *.so.0.2.0 The newly built package contains *.so.0.6.0. It breaks dependent applications: xchm, rapidsvn, kicad, boincmanager. What's the strategy in such a case? Should I notify the maintainers of the dependent packages and release the updated packages simultaneously? It's a nice idea, but they won't be able to build updated packages until new wxwidgets is released (only released packages are installed on build{8,9,10}{s,x}). Maciej From dam at opencsw.org Wed Sep 23 13:22:12 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 13:22:12 +0200 (CEST) Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB9FE64.1040209@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> <4AB8FC6C.9080701@opencsw.org> <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> <4AB9FE64.1040209@opencsw.org> Message-ID: <401706fb05cc9ff2d546e8853671259e.squirrel@mail.opencsw.org> Hi Daniel, > Dagobert Michelsen wrote: >> Am 22.09.2009 um 18:33 schrieb Daniel Pocock: >>> It is still officially a beta until the Ganglia community endorses it >>> as GA - usually 1-2 weeks after tagging, if no one has found a major >>> fault. I saw a message earlier that said I can't release properly >>> until it passes upstreams `beta' phase. >>> >>> Can we test it anyway, and then I will commit and put it in newpkgs >>> when it is officially GA? >> >> I could if I would install the packages manually. But as we have the >> commit policy "commit early, commit often" there really is no need to >> have any package in testing with UNCOMMITTED in it as it only makes >> things harder. Additionally, if I want to look into your recipe I can't >> do that right now as you haven't committed everything. > > Ok, I have now committed them on a branch and put them in testing again > - please let me know which host you put the web package on so I can check > it Great. However, I have some trouble activating it due to the vhost-configuration of buildfarm.opencsw.org. I'll have a deeper look later on... Best regards -- Dago From dam at opencsw.org Wed Sep 23 13:25:16 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 13:25:16 +0200 (CEST) Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <9D015FAC-931C-4DD3-A4AB-CC1AB214E9A9@opencsw.org> <7F956EB7-8E18-4052-B985-D360956F8626@opencsw.org> <1251391060-sup-388@ntdws12.chass.utoronto.ca> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> Message-ID: Hi Maciej, > The packages have been built and they've been sitting in testing/ for > a while now. I'd like to have them released, but there's a problem > with dependent applications. Shared libraries in the updated wxwidgets > packages have different file names than the version currently present > on the mirrors. > > http://www.opencsw.org/search/wxwidgets_gtk2 contains *.so.0.2.0 > The newly built package contains *.so.0.6.0. > > It breaks dependent applications: xchm, rapidsvn, kicad, boincmanager. > > What's the strategy in such a case? Should I notify the maintainers of > the dependent packages and release the updated packages > simultaneously? It's a nice idea, but they won't be able to build > updated packages until new wxwidgets is released (only released > packages are installed on build{8,9,10}{s,x}). You can either put the original legacy libraries in there "manually" during post-install (see curl for an example) or use version modulations to also build the old version and put only the libs in the package (see expat/flac/neon/readline for examples). Best regards -- Dago From james at opencsw.org Wed Sep 23 13:26:12 2009 From: james at opencsw.org (James Lee) Date: Wed, 23 Sep 2009 11:26:12 GMT Subject: [csw-maintainers] Using a package from current on stable In-Reply-To: <4ABA011A.8070809@opencsw.org> References: <4ABA011A.8070809@opencsw.org> Message-ID: <20090923.11261200.3107154672@gyor.oxdrove.co.uk> On 23/09/09, 12:06:02, Daniel Pocock wrote regarding [csw-maintainers] Using a package from current on stable: > Given that my package is a new package and doesn't impact any other > packages, are there any other steps I need to take to make it suitable > for an upcoming stable release? Will the use of cswclassutils prevent > me from having the package in stable? No. The supporting packages would also need to be stable but in this case that would happen. Stable is produced as a snapshot, mainly because it's too hard to do anything else, hence the supporting cast are also promoted. It is possible to prune unsuitable branches but where the interdependence is high the whole snapshot has to be ready (please will someone fix the BDB mess...). If your package is new it would be pruned from the stable snapshot anyway. It needs a "burn in" period in unstable. Interdependence and affidavits can affect the grace period. James. From daniel at opencsw.org Wed Sep 23 13:31:03 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 23 Sep 2009 12:31:03 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <401706fb05cc9ff2d546e8853671259e.squirrel@mail.opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> <4AB8FC6C.9080701@opencsw.org> <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> <4AB9FE64.1040209@opencsw.org> <401706fb05cc9ff2d546e8853671259e.squirrel@mail.opencsw.org> Message-ID: <4ABA06F7.404@opencsw.org> dam at opencsw.org wrote: > Hi Daniel, > >> Dagobert Michelsen wrote: >>> Am 22.09.2009 um 18:33 schrieb Daniel Pocock: >>>> It is still officially a beta until the Ganglia community endorses it >>>> as GA - usually 1-2 weeks after tagging, if no one has found a major >>>> fault. I saw a message earlier that said I can't release properly >>>> until it passes upstreams `beta' phase. >>>> >>>> Can we test it anyway, and then I will commit and put it in newpkgs >>>> when it is officially GA? >>> I could if I would install the packages manually. But as we have the >>> commit policy "commit early, commit often" there really is no need to >>> have any package in testing with UNCOMMITTED in it as it only makes >>> things harder. Additionally, if I want to look into your recipe I can't >>> do that right now as you haven't committed everything. >> Ok, I have now committed them on a branch and put them in testing again >> - please let me know which host you put the web package on so I can check >> it > > Great. However, I have some trouble activating it due to the > vhost-configuration of buildfarm.opencsw.org. I'll have a deeper look > later on... > Even without running the web interface, you can still install the ganglia_agent package on all the machines you want to watch, and test it with this command: nc localhost 8649 | grep ^.[CH] The output should be a list of those hosts sending metrics on the same multicast group as the agent on localhost. From dam at opencsw.org Wed Sep 23 13:31:07 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 13:31:07 +0200 (CEST) Subject: [csw-maintainers] Using a package from current on stable In-Reply-To: <4ABA011A.8070809@opencsw.org> References: <4ABA011A.8070809@opencsw.org> Message-ID: Hi Daniel, > The Ganglia package I've been working with works on a wide range of > architectures. I thought I would try to install the package on a > Solaris 8 system with OpenCSW stable instead of current FYI: Adding newer packages to stable is not supported and newer packages will not be added to stable. A stable release is made from current during a release-freeze with thourough package inspection. An update of stable is pending and there is no date for an update. James, out stable release manager, made some progress towards a new stable, but due to time constraints there is no timeframe. > Two issues arise: > - cswclassutils is missing on stable > - expat.so.0 on stable, expat.so.1 expected for current > > Therefore, I suspect I need to > > - copy some additional things, e.g. cswclassutils, to the system where I > want Ganglia If you want to poach your stable installation you can do that. > - rebuild my package for stable's library versions - how do I tell gar > to do that? You don't, as new packages are always build against current. > Given that my package is a new package and doesn't impact any other > packages, are there any other steps I need to take to make it suitable > for an upcoming stable release? Will the use of cswclassutils prevent > me from having the package in stable? If a new stable release is made and your package has been released to current at that time and has no open critical bugs it will go automatically into stable. The delay of a new stable release is painful, but we don't have that many people having the infrastrastructure, time and knowledge to do it. Best regards -- Dago From maciej at opencsw.org Wed Sep 23 13:38:15 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 12:38:15 +0100 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <7F956EB7-8E18-4052-B985-D360956F8626@opencsw.org> <1251391060-sup-388@ntdws12.chass.utoronto.ca> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Sep 23, 2009 at 12:25 PM, wrote: > You can either put the original legacy libraries in there "manually" > during post-install (see curl for an example) or use version modulations > to also build the old version and put only the libs in the package > (see expat/flac/neon/readline for examples). I see, version modulations. Is it a one-way process only? I mean, this way the list of package versions is going to be growing indefinitely, unless there's a process in place to phase out the old versions. One more question: If two versions of a library are installed on one system, which one is being used during linking? Maciej From dam at opencsw.org Wed Sep 23 13:40:02 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 13:40:02 +0200 (CEST) Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4ABA06F7.404@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> <4AB8FC6C.9080701@opencsw.org> <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> <4AB9FE64.1040209@opencsw.org> <401706fb05cc9ff2d546e8853671259e.squirrel@mail.opencsw.org> <4ABA06F7.404@opencsw.org> Message-ID: <6980adcb9c4d857182877ed5d04a5617.squirrel@mail.opencsw.org> Hi Daniel, > Even without running the web interface, you can still install the > ganglia_agent package on all the machines you want to watch, and test it > with this command: > > nc localhost 8649 | grep ^.[CH] > > The output should be a list of those hosts sending metrics on the same > multicast group as the agent on localhost. At least on build8st it is not working: build8st# sh -x /etc/init.d/cswgmond start GANGLIA_BASEDIR=/opt/csw GMOND=/opt/csw/sbin/gmond GMOND_CONF=/etc/opt/csw/ganglia/gmond.conf + test -f /etc/default/gmond + [ ! -d /opt/csw ] + /opt/csw/sbin/gmond -c /etc/opt/csw/ganglia/gmond.conf ioctl error: No such device or address 19378: time() = 1253705957 19378: ioctl(3, KSTAT_IOC_CHAIN_ID, 0x00000000) = 46533 19378: so_socket(2, 1, 0, "", 1) = 4 19378: ioctl(4, 0xC0086914, 0xFFBFF9A8) = 0 19378: ioctl(4, 0xC0086914, 0xFFBFF9A8) = 0 19378: ioctl(4, 0xC0206911, 0xFFBFF974) Err#6 ENXIO ioctl error: No such device or address 19378: write(2, " i o c t l e r r o r :".., 39) = 39 19378: munmap(0xFECB0000, 24302) = 0 I have not configured anything apart from installing the package. Best regards -- Dago From dam at opencsw.org Wed Sep 23 13:43:17 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 13:43:17 +0200 (CEST) Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <7F956EB7-8E18-4052-B985-D360956F8626@opencsw.org> <1251391060-sup-388@ntdws12.chass.utoronto.ca> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> Message-ID: Hi Maciej, > On Wed, Sep 23, 2009 at 12:25 PM, wrote: >> You can either put the original legacy libraries in there "manually" >> during post-install (see curl for an example) or use version modulations >> to also build the old version and put only the libs in the package >> (see expat/flac/neon/readline for examples). > > I see, version modulations. Is it a one-way process only? I mean, this > way the list of package versions is going to be growing indefinitely, > unless there's a process in place to phase out the old versions. No. After the updated package has been released you file the bugs to the packages depending on the old libs :-) After the last one has been updated you remove them from your package. > One more question: If two versions of a library are installed on one > system, which one is being used during linking? Usually the latest as it is detected during autoconf/libtool/pkgconfig etc. I never had a problem with adding old libs for new compiles. Best regards -- Dago From daniel at opencsw.org Wed Sep 23 13:44:13 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 23 Sep 2009 12:44:13 +0100 Subject: [csw-maintainers] Using a package from current on stable In-Reply-To: References: <4ABA011A.8070809@opencsw.org> Message-ID: <4ABA0A0D.1040603@opencsw.org> dam at opencsw.org wrote: > Hi Daniel, > >> The Ganglia package I've been working with works on a wide range of >> architectures. I thought I would try to install the package on a >> Solaris 8 system with OpenCSW stable instead of current > > FYI: Adding newer packages to stable is not supported and newer packages > will not be added to stable. A stable release is made from current during > a release-freeze with thourough package inspection. An update of stable is > pending and there is no date for an update. > > James, out stable release manager, made some progress towards a new > stable, but due to time constraints there is no timeframe. > >> Two issues arise: >> - cswclassutils is missing on stable >> - expat.so.0 on stable, expat.so.1 expected for current >> >> Therefore, I suspect I need to >> >> - copy some additional things, e.g. cswclassutils, to the system where I >> want Ganglia > > If you want to poach your stable installation you can do that. > >> - rebuild my package for stable's library versions - how do I tell gar >> to do that? > > You don't, as new packages are always build against current. > >> Given that my package is a new package and doesn't impact any other >> packages, are there any other steps I need to take to make it suitable >> for an upcoming stable release? Will the use of cswclassutils prevent >> me from having the package in stable? > > If a new stable release is made and your package has been released to current > at that time and has no open critical bugs it will go automatically into > stable. > > The delay of a new stable release is painful, but we don't have that many > people having the infrastrastructure, time and knowledge to do it. > I understand that OpenCSW can't endorse a package and put it in stable without following the correct process - otherwise, there would just be anarchy However, if someone wants to distribute a package through a third party download site (e.g. the upstream download page on SF), and they want their package to just drop in to stable, is that permitted? Is there a convenient way to build such a package with gar on the build farm? From james at opencsw.org Wed Sep 23 13:44:16 2009 From: james at opencsw.org (James Lee) Date: Wed, 23 Sep 2009 11:44:16 GMT Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <7F956EB7-8E18-4052-B985-D360956F8626@opencsw.org> <1251391060-sup-388@ntdws12.chass.utoronto.ca> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> Message-ID: <20090923.11441600.3790365392@gyor.oxdrove.co.uk> On 23/09/09, 12:38:15, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] Anyone wants to update wxWidgets?: > One more question: If two versions of a library are installed on one > system, which one is being used during linking? The one pointed to by (or that is) .so /opt/csw/lib/libjpeg.so.62.0.0 /opt/csw/lib/libjpeg.so.62=libjpeg.so.62.0.0 /opt/csw/lib/libjpeg.so.7.0.0 /opt/csw/lib/libjpeg.so.7=libjpeg.so.7.0.0 /opt/csw/lib/libjpeg.so=libjpeg.so.7.0.0 at link libjpeg.so uses .so.7 not .62 SONAME is used at run time. James. From daniel at opencsw.org Wed Sep 23 13:49:56 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 23 Sep 2009 12:49:56 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <6980adcb9c4d857182877ed5d04a5617.squirrel@mail.opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> <4AB8FC6C.9080701@opencsw.org> <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> <4AB9FE64.1040209@opencsw.org> <401706fb05cc9ff2d546e8853671259e.squirrel@mail.opencsw.org> <4ABA06F7.404@opencsw.org> <6980adcb9c4d857182877ed5d04a5617.squirrel@mail.opencsw.org> Message-ID: <4ABA0B64.40202@opencsw.org> dam at opencsw.org wrote: > Hi Daniel, > >> Even without running the web interface, you can still install the >> ganglia_agent package on all the machines you want to watch, and test it >> with this command: >> >> nc localhost 8649 | grep ^.[CH] >> >> The output should be a list of those hosts sending metrics on the same >> multicast group as the agent on localhost. > > At least on build8st it is not working: > > build8st# sh -x /etc/init.d/cswgmond start > GANGLIA_BASEDIR=/opt/csw > GMOND=/opt/csw/sbin/gmond > GMOND_CONF=/etc/opt/csw/ganglia/gmond.conf > + test -f /etc/default/gmond > + [ ! -d /opt/csw ] > + /opt/csw/sbin/gmond -c /etc/opt/csw/ganglia/gmond.conf > ioctl error: No such device or address > > 19378: time() = 1253705957 > 19378: ioctl(3, KSTAT_IOC_CHAIN_ID, 0x00000000) = 46533 > 19378: so_socket(2, 1, 0, "", 1) = 4 > 19378: ioctl(4, 0xC0086914, 0xFFBFF9A8) = 0 > 19378: ioctl(4, 0xC0086914, 0xFFBFF9A8) = 0 > 19378: ioctl(4, 0xC0206911, 0xFFBFF974) Err#6 ENXIO > ioctl error: No such device or address > 19378: write(2, " i o c t l e r r o r :".., 39) = 39 > 19378: munmap(0xFECB0000, 24302) = 0 > > > I have not configured anything apart from installing the package. > Does the machine have a default route, or a route for 224.0.0.0/4? I've seen reports of problems on such machines. Can you try route add -host 239.2.11.71 dev ??? I can't ssh to build8st - it prompts me for a password, my key is not accepted - can you help me get on the machine? If that route command fixes it, do you think this is something that should be changed from preinstall, or just warn the user and let them fix it? From dam at opencsw.org Wed Sep 23 13:52:53 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 13:52:53 +0200 (CEST) Subject: [csw-maintainers] Using a package from current on stable In-Reply-To: <4ABA0A0D.1040603@opencsw.org> References: <4ABA011A.8070809@opencsw.org> <4ABA0A0D.1040603@opencsw.org> Message-ID: <8b097644ac93777fb96e2d225cf86c0a.squirrel@mail.opencsw.org> Hi Daniel, > However, if someone wants to distribute a package through a third party > download site (e.g. the upstream download page on SF), and they want > their package to just drop in to stable, is that permitted? Is there a > convenient way to build such a package with gar on the build farm? Difficult. The package will not be added to stable, but will become a part of stable in the next release. If you want to offer a binary package I would offer it for current. Because there is nothing added directly to stable there is no point in building a package against stable. It would require having at least Solaris 8 Sparc, Solaris 8 x86 and Solaris 10 x86 on stable/, which we don't have on the farm. But if you insist you can make your own farm and use your GAR build description to do it, but I wouldn't that consider a good idea. The best thing I can propose if you want your package in stable is test it good, release it to current and help in the next release of stable. That way everyone can gain from the work put into it. Best regards -- Dago From william at wbonnet.net Wed Sep 23 12:43:53 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 23 Sep 2009 12:43:53 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> Message-ID: <4AB9FBE9.8000908@wbonnet.net> Hi After having some talk with Sebastian, i have the folowwing proposition. Since we are renaming some of the X11 packages to add a prefix, and about to do some mass change. What about adding a more explicit prefix ? For instance fooproto could be renamed to : a/ xfooxproto b/ x11-fooproto c/ x11proto-foo d/ x11proto-foo-devel Current proposition is a. My choice goes to d. I would like to also add the -devel suffix since it is a true devel package cheers W. From william at wbonnet.net Wed Sep 23 13:07:02 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 23 Sep 2009 13:07:02 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4AB9FBE9.8000908@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4AB9FBE9.8000908@wbonnet.net> Message-ID: <4ABA0156.2000303@wbonnet.net> Hi I resend it since it seems it was not correctly transmitted cheers W. > After having some talk with Sebastian, i have the folowwing > proposition. Since we are renaming some of the X11 packages to add a > prefix, and about to do some mass change. What about adding a more > explicit prefix ? > > For instance fooproto could be renamed to : > > a/ xfooxproto > b/ x11-fooproto > c/ x11proto-foo > d/ x11proto-foo-devel > > Current proposition is a. My choice goes to d. I would like to also > add the -devel suffix since it is a true devel package > > cheers > W. > > From dam at opencsw.org Wed Sep 23 14:07:07 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 14:07:07 +0200 (CEST) Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4AB9FBE9.8000908@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4AB9FBE9.8000908@wbonnet.net> Message-ID: <5a783a504774d077b080a509285dce93.squirrel@mail.opencsw.org> Hi William, > After having some talk with Sebastian, i have the folowwing proposition. > Since we are renaming some of the X11 packages to add a prefix, and > about to do some mass change. What about adding a more explicit prefix ? > > For instance fooproto could be renamed to : > > a/ xfooxproto > b/ x11-fooproto > c/ x11proto-foo > d/ x11proto-foo-devel > > Current proposition is a. My choice goes to d. I would like to also add > the -devel suffix since it is a true devel package Are these catalog- or package-names? catalogname usually contain _ instead of -, and the current standard uses CSWfoodevel instead of CSWfoo-devel. That would mean a/ xfooxproto CSWxfooxproto b/ x11_fooproto CSWx11fooproto c/ x11proto_foo CSWx11protofoo d/ x11proto_foo_devel CSWx11protofoodevel Best regards -- Dago From james at opencsw.org Wed Sep 23 15:12:49 2009 From: james at opencsw.org (James Lee) Date: Wed, 23 Sep 2009 13:12:49 GMT Subject: [csw-maintainers] Using a package from current on stable In-Reply-To: <4ABA0A0D.1040603@opencsw.org> References: <4ABA011A.8070809@opencsw.org> <4ABA0A0D.1040603@opencsw.org> Message-ID: <20090923.13124900.4175345103@gyor.oxdrove.co.uk> On 23/09/09, 12:44:13, Daniel Pocock wrote regarding Re: [csw-maintainers] Using a package from current on stable: > However, if someone wants to distribute a package through a third party > download site (e.g. the upstream download page on SF), and they want > their package to just drop in to stable, is that permitted? Who's going to stop it? We are not underworked copyright lawyers. The OCSW official line is going to be that you distribute the package as an official CSW package. A problem is OCSW don't know to support your package so, e.g., if it needs a particular library (expat.so.0 vs expat.so.1) you leave yourself exposed to that library being dropped. To avoid branding issues and potential file clashes you can use /opt/$YOURNAME and use /opt/csw RPATHs. > Is there a > convenient way to build such a package with gar on the build farm? No. Build against stable. Either set up a stable build environment or force it with the paths, that is use $ELSEWHERE/$STABLE/opt/csw and set PATH, -I, -L appropriately. James. From maciej at opencsw.org Wed Sep 23 15:52:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 14:52:39 +0100 Subject: [csw-maintainers] Upgrading shared libraries Message-ID: I'm splitting this thread, to talk a bit more about library updates. On Wed, Sep 23, 2009 at 12:43 PM, wrote: > Hi Maciej, > >> On Wed, Sep 23, 2009 at 12:25 PM, ? wrote: >>> You can either put the original legacy libraries in there "manually" >>> during post-install (see curl for an example) or use version modulations >>> to also build the old version and put only the libs in the package >>> (see expat/flac/neon/readline for examples). >> >> I see, version modulations. Is it a one-way process only? I mean, this >> way the list of package versions is going to be growing indefinitely, >> unless there's a process in place to phase out the old versions. > > No. After the updated package has been released you file the bugs > to the packages depending on the old libs :-) After the last one has > been updated you remove them from your package. I'll drill the topic some more. What if a dependent package becomes orphaned? Suppose there's CSWlibfoo, which has been updated, but package CSWbar depends on it, the maintainer vanished inside a black hole and nobody is willing to pick the package up. Are there any deadlines? Does the importance of CSWbar matter? Ideally, I'd like it to be there a page which describes how to deal with library updates, along with the process of phasing out old library versions. Can one of the elders write it? If not, I'm going to do it myself, and Trygve is going to start telling me why what I wrote is wrong... ;-) Maciej From daniel at opencsw.org Wed Sep 23 16:34:53 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 23 Sep 2009 15:34:53 +0100 Subject: [csw-maintainers] etc issues Message-ID: <4ABA320D.108@opencsw.org> I'm putting my config under /etc/opt/csw/ganglia, as suggested in an earlier email from Dago However, I notice that gar configures my application to use /opt/csw/etc Is some extra effort required to override this? My Makefile is here: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/ganglia/branches/ganglia-3.1.3-rc/ and this is what I found in the build dir: bash-2.03$ ls -l work/build-isa-sparcv8/ganglia-3.1.3/config.log -rw-r--r-- 1 daniel csw 119978 Sep 23 12:28 work/build-isa-sparcv8/ganglia-3.1.3/config.log bash-2.03$ bash-2.03$ grep sysconfdir work/build-isa-sparcv8/ganglia-3.1.3/config.log $ ./configure --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share --sysconfdir=/opt/csw/etc --sharedstatedir=/opt/csw/share --localstatedir=/opt/csw/var --libdir=/opt/csw/lib --infodir=/opt/csw/share/info --includedir=/opt/csw/include --mandir=/opt/csw/share/man --with-gmetad --disable-nls --with-libapr=/opt/csw/apache2/bin/apr-1-config --with-status --disable-python sysconfdir='/opt/csw/etc' From bwalton at opencsw.org Wed Sep 23 16:40:47 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Sep 2009 10:40:47 -0400 Subject: [csw-maintainers] etc issues In-Reply-To: <4ABA320D.108@opencsw.org> References: <4ABA320D.108@opencsw.org> Message-ID: <1253716785-sup-3583@ntdws12.chass.utoronto.ca> Excerpts from Daniel Pocock's message of Wed Sep 23 10:34:53 -0400 2009: > I'm putting my config under /etc/opt/csw/ganglia, as suggested in an > earlier email from Dago > > However, I notice that gar configures my application to use > /opt/csw/etc For now, you need to set 'sysconfdir = /etc/opt/csw' manually in your makefile to override the gar default. I'm planning to update this but haven't had the time to update the default and alter all makefiles to prevent surprises for maintainers yet. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Wed Sep 23 16:42:43 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 15:42:43 +0100 Subject: [csw-maintainers] etc issues In-Reply-To: <1253716785-sup-3583@ntdws12.chass.utoronto.ca> References: <4ABA320D.108@opencsw.org> <1253716785-sup-3583@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Sep 23, 2009 at 3:40 PM, Ben Walton wrote: > Excerpts from Daniel Pocock's message of Wed Sep 23 10:34:53 -0400 2009: > >> I'm putting my config under /etc/opt/csw/ganglia, as suggested in an >> earlier email from Dago >> >> However, I notice that gar configures my application to use >> /opt/csw/etc > > For now, you need to set 'sysconfdir = /etc/opt/csw' manually in your > makefile to override the gar default. ?I'm planning to update this but > haven't had the time to update the default and alter all makefiles to > prevent surprises for maintainers yet. Yes, what Ben said. Two directories need to be altered. On Wed, Sep 23, 2009 at 3:34 PM, Daniel Pocock wrote: > --sysconfdir=/opt/csw/etc > --localstatedir=/opt/csw/var Add these two lines to the Makefile: sysconfdir = /etc/opt/csw localstatedir = /var/opt/csw Maciej From phil at bolthole.com Wed Sep 23 18:13:51 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 09:13:51 -0700 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4AB9FBE9.8000908@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4AB9FBE9.8000908@wbonnet.net> Message-ID: On Wed, Sep 23, 2009 at 3:43 AM, William Bonnet wrote: > Hi > > > After having some talk with Sebastian, i have the folowwing proposition. > Since we are renaming some of the X11 packages to add a prefix, and about to > do some mass change. What about adding a more explicit prefix ? > > For instance fooproto could be renamed to : > > a/ xfooxproto > b/ x11-fooproto > c/ x11proto-foo > d/ x11proto-foo-devel > > Current proposition is a. My choice goes to d. I would like to also add the > -devel suffix since it is a true devel package d isnt a bad choice... the one issue being that it would look a little silly for stuff that already has "x" in it. x11proto_xext_devel vs x11proto_input_devel people will probably gripe about "well how come Xexp, but no Xinput...?" From phil at bolthole.com Wed Sep 23 18:19:08 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 09:19:08 -0700 Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: Message-ID: On Wed, Sep 23, 2009 at 6:52 AM, Maciej (Matchek) Blizinski wrote: > I'm splitting this thread, to talk a bit more about library updates. > > On Wed, Sep 23, 2009 at 12:43 PM, ? wrote: >> Hi Maciej, >> >> >>> I see, version modulations. Is it a one-way process only? I mean, this >>> way the list of package versions is going to be growing indefinitely, >>> unless there's a process in place to phase out the old versions. >> >> No. After the updated package has been released you file the bugs >> to the packages depending on the old libs :-) After the last one has >> been updated you remove them from your package. > > I'll drill the topic some more. What if a dependent package becomes > orphaned? Suppose there's CSWlibfoo, which has been updated, but > package CSWbar depends on it, the maintainer vanished inside a black > hole and nobody is willing to pick the package up. Are there any > deadlines? I dont see how this "changes" anything. every package that is "current"ly being distributed, needs to actually WORK. for so long as CSWbar is present, CSWlibfoo must ensure that it does not break, by supplying the older library that CSWbar requires. > Ideally, I'd like it to be there a page which describes how to deal > with library updates, I believe there already is such a page, and it mentions what dago says: Provide the older versions of the shared libs for so long as other packages we distribute, require them. From william at wbonnet.net Wed Sep 23 18:19:40 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 23 Sep 2009 18:19:40 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4AB9FBE9.8000908@wbonnet.net> Message-ID: <4ABA4A9C.4090704@wbonnet.net> Hi > d isnt a bad choice... the one issue being that it would look a little > silly for stuff that already has "x" in it. > > x11proto_xext_devel > > vs > > x11proto_input_devel > > people will probably gripe about "well how come Xexp, but no Xinput...?" > I agree but this is how the upstream project choosed to name its package... BTW you cannot be sure that in the futur someone will not add an ext package. In this case how would you name it if xext already exist and you kept its name instead of naming it xxext ? ;) This should not happen... but it may... so it will :) I do prefer to always keep original upstream name if possible. cheers W. From maciej at opencsw.org Wed Sep 23 19:05:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 18:05:01 +0100 Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: Message-ID: On Wed, Sep 23, 2009 at 5:19 PM, Philip Brown wrote: > On Wed, Sep 23, 2009 at 6:52 AM, Maciej (Matchek) Blizinski > wrote: >> I'm splitting this thread, to talk a bit more about library updates. >> >> On Wed, Sep 23, 2009 at 12:43 PM, ? wrote: >>> Hi Maciej, >>> >>> >>>> I see, version modulations. Is it a one-way process only? I mean, this >>>> way the list of package versions is going to be growing indefinitely, >>>> unless there's a process in place to phase out the old versions. >>> >>> No. After the updated package has been released you file the bugs >>> to the packages depending on the old libs :-) After the last one has >>> been updated you remove them from your package. >> >> I'll drill the topic some more. What if a dependent package becomes >> orphaned? Suppose there's CSWlibfoo, which has been updated, but >> package CSWbar depends on it, the maintainer vanished inside a black >> hole and nobody is willing to pick the package up. Are there any >> deadlines? > > > I dont see how this "changes" anything. > > every package that is "current"ly being distributed, needs to actually WORK. > for so long as CSWbar is present, CSWlibfoo must ensure that it does > not break, by supplying the older library that CSWbar requires. That's clear. What I had in mind is: how do we prevent our libraries from growing indefinitely in size due to stale dependent packages? >> Ideally, I'd like it to be there a page which describes how to deal >> with library updates, > > I believe there already is such a page, and it mentions what dago > says: Provide the older versions of the shared libs for so long as > other packages we distribute, require them. I think it would be the one with the following URL: http://www.opencsw.org/standards/libraries It's a narrative describing it from a high level. It's a good start, but not really what I had in mind. I was thinking of having it documented: - what are the possible strategies (Dago mentioned two of them) - how to achieve that in GAR - what is the process of phasing out old library versions - what are the deadlines for phasing out old libraries (say, there's a bug to update a package, but doesn't get fixed for X amount of time. What's happening with the dependent package, does it need a new maintainer, or does it get killed?) Maciej From phil at bolthole.com Wed Sep 23 19:23:25 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 10:23:25 -0700 Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: Message-ID: On Wed, Sep 23, 2009 at 10:05 AM, Maciej (Matchek) Blizinski wrote: > >> every package that is "current"ly being distributed, needs to actually WORK. >> for so long as CSWbar is present, CSWlibfoo must ensure that it does >> not break, by supplying the older library that CSWbar requires. > > That's clear. What I had in mind is: how do we prevent our libraries > from growing indefinitely in size due to stale dependent packages? It's worked pretty well for 6 years now. All the questions you are asking, are dealt with on a case-by-base basis. There really isnt a need to spell out every single possible contingency. [and there's a need to NOT spell it out.. documents that are too long, get ignored.] Bottom line is, progress happens by people willing to do work. not by documenting things to the Nth degree. From phil at bolthole.com Wed Sep 23 19:25:58 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 10:25:58 -0700 Subject: [csw-maintainers] The source code of www.opencsw.org In-Reply-To: References: <20090723220149.GB8541@bolthole.com> <20090724160343.GC91227@bolthole.com> <4A6B4DFE.1050307@opencsw.org> <20090725203035.GA24170@bolthole.com> <4A6C2341.8060600@opencsw.org> <20090726154345.GB28096@bolthole.com> Message-ID: On Wed, Sep 23, 2009 at 2:23 AM, Maciej (Matchek) Blizinski wrote: > Re: http://www.opencsw.org/mantis/view.php?id=3459#c6709 > > The irforceready mirrors from our mirrors subpage currently point at > Blastwave mirrors. I'm not going to propose a change*, because the > administrative overhead is going to by far surpass the amount of work > needed to fix the issue, so I'm only mentioning it here. > > Maciej > > * See how careful I am not to say "send a patch"? Odd way of putting things. BTW, there's a difference between "sugest a change", and "send a patch". Thanks for pointing out the stray site. I have "changed" things. (that wasnt too hard now, was it? :-) From phil at bolthole.com Wed Sep 23 22:35:22 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 13:35:22 -0700 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <4AB9DE48.8060006@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> Message-ID: On Wed, Sep 23, 2009 at 1:37 AM, Sebastian Kayser wrote: > > I was just about to file the bugs against packages which don't have the > py_ prefix. Just wanted to make sure we have reached a consensus here so > that i file the bugs against the right set of packages: > > - python programs with a recognized name can/should be left as is > - python libraries will be prefixed with py_ > > Resuming the pyyaml example: pyyaml is a library (python modules only), > thus the software name would be py_yaml. This is similar to Debian's > policy [1], just that they prefix module packages with "python-". In > their case, pyyaml is packaged as python-yaml [2]. > except that "pyyaml" is in the "recognized name so should be left as is" category :-) it is "recognized" both in the sense that we have an existing package, AND, even MORE importantly, there is the actual specific name of the software. hosted from "pyyaml.org" From phil at bolthole.com Wed Sep 23 22:37:09 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 13:37:09 -0700 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: On Mon, Sep 21, 2009 at 4:08 PM, Gary Law wrote: > > I beg to differ. The increased complexity of two places outweighs any > possible benefits. Everything in /etc/opt/csw please. Gary for the progams that YOU maintain, that is fine. > -- > Gary Law > glaw at blastwave.org Uhuh. interesting. From phil at bolthole.com Wed Sep 23 22:43:08 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 13:43:08 -0700 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> Message-ID: On Wed, Sep 23, 2009 at 1:35 PM, Philip Brown wrote: > On Wed, Sep 23, 2009 at 1:37 AM, Sebastian Kayser wrote: >> >> Resuming the pyyaml example: pyyaml is a library (python modules only), >> thus the software name would be py_yaml. This is similar to Debian's >> policy [1], just that they prefix module packages with "python-". In >> their case, pyyaml is packaged as python-yaml [2]. As an interesting contrast,both Gentoo and Ubuntu seem to package it as "pyyaml" :-) Eerm.. and debian does too? or at least.. it has a "source package" named "pyyaml".. but a "binary package" named "python-yaml" ?!!! http://packages.debian.org/source/lenny/pyyaml that's just insane. Stop the insanity please :-) pyyaml is a well-known exception to the usual py_ convention From skayser at opencsw.org Thu Sep 24 00:51:00 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 24 Sep 2009 00:51:00 +0200 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> Message-ID: <4ABAA654.1000706@opencsw.org> Philip Brown wrote on 23.09.2009 22:43: > On Wed, Sep 23, 2009 at 1:35 PM, Philip Brown wrote: >> On Wed, Sep 23, 2009 at 1:37 AM, Sebastian Kayser wrote: >>> Resuming the pyyaml example: pyyaml is a library (python modules only), >>> thus the software name would be py_yaml. This is similar to Debian's >>> policy [1], just that they prefix module packages with "python-". In >>> their case, pyyaml is packaged as python-yaml [2]. > > As an interesting contrast,both Gentoo and Ubuntu seem to package it > as "pyyaml" :-) > > Eerm.. and debian does too? > > or at least.. it has a "source package" named "pyyaml".. but a "binary > package" named "python-yaml" ?!!! > http://packages.debian.org/source/lenny/pyyaml The source package name corresponds to the upstream name. The binary package name is where (i imagine) the distribution tries to create a consistent user experience. Plus, one source package can result in multiple binary packages, but that's another topic. You are right, Gentoo simply passes the upstream name pyyaml [1]. Ubuntu (like Debian) renames it to python-yaml [2] though. > pyyaml is a well-known exception to the usual py_ convention If we follow that road we leave it up to every maintainer to decide what is "well-known". Plus there might be as many "well-known" (pygtk, pysqlite, pyxml, etc. [3,4,5]) module packages as non-"well-known" packages, which gets us half py* and half py_* packages. Not to mention, packages like SOAPy/SOAPpy where you wouldn't even have the common py prefix. I should have detailed Debian's python policy WRT module packages a bit more, because it leaves pleasant little room for interpretation. A module package name is constructed according to py_ Here, is absolutely non-ambiguous; one refers to this name when importing a python module. Would a general policy like this (also applied to pyyaml, modulename: yaml) hurt? I don't think so. Sebastian [1] http://gentoo-portage.com/dev-python/pyyaml [2] http://packages.ubuntu.com/karmic/python-yaml [3] http://www.pygtk.org/ [4] http://oss.itsystementwicklung.de/trac/pysqlite/ [5] http://sourceforge.net/projects/pyxml/ From bwalton at opencsw.org Thu Sep 24 03:50:39 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Sep 2009 21:50:39 -0400 Subject: [csw-maintainers] gar_devel Message-ID: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> So I was having a look at www-mockup tonight and I followed the link to preparing a working build environment. That page lists the packages required by GAR to get up and running. I thought 'why not make this easier'... I put together a dummy package called gar_devel (CSWgardevel) that simply depends on all of the listed packages. It's in testing/ now. If it's useful, I'll release it and the reference page can be updated. Otherwise, I'll squash it and forget about the 5 wasted minutes. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Thu Sep 24 09:41:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 24 Sep 2009 09:41:19 +0200 Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: Message-ID: <86E3FB84-4E6D-48DC-9F5B-DAFED4EE7F3E@opencsw.org> Hi Maciej, Am 23.09.2009 um 19:23 schrieb Philip Brown: > On Wed, Sep 23, 2009 at 10:05 AM, Maciej (Matchek) Blizinski > wrote: >> >>> every package that is "current"ly being distributed, needs to >>> actually WORK. >>> for so long as CSWbar is present, CSWlibfoo must ensure that it does >>> not break, by supplying the older library that CSWbar requires. >> >> That's clear. What I had in mind is: how do we prevent our libraries >> from growing indefinitely in size due to stale dependent packages? If an orphaned package depends on a legacy lib you have to keep it. Or update the orphaned package yourself or find somebody. Best regards -- Dago From maciej at opencsw.org Thu Sep 24 11:49:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 24 Sep 2009 10:49:54 +0100 Subject: [csw-maintainers] gar_devel In-Reply-To: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> References: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Sep 24, 2009 at 2:50 AM, Ben Walton wrote: > > So I was having a look at www-mockup tonight and I followed the link > to preparing a working build environment. ?That page lists the > packages required by GAR to get up and running. ?I thought 'why not > make this easier'... > > I put together a dummy package called gar_devel (CSWgardevel) that > simply depends on all of the listed packages. ?It's in testing/ now. > > If it's useful, I'll release it and the reference page can be > updated. ?Otherwise, I'll squash it and forget about the 5 wasted > minutes. I like the idea. Especially, when a somebody is taking first steps at building packages. Less hoops is better! Maciej From maciej at opencsw.org Thu Sep 24 13:37:22 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 24 Sep 2009 12:37:22 +0100 Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: <86E3FB84-4E6D-48DC-9F5B-DAFED4EE7F3E@opencsw.org> References: <86E3FB84-4E6D-48DC-9F5B-DAFED4EE7F3E@opencsw.org> Message-ID: On Thu, Sep 24, 2009 at 8:41 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 23.09.2009 um 19:23 schrieb Philip Brown: >> >> On Wed, Sep 23, 2009 at 10:05 AM, Maciej (Matchek) Blizinski >> wrote: >>> >>>> every package that is "current"ly being distributed, needs to actually >>>> WORK. >>>> for so long as CSWbar is present, CSWlibfoo must ensure that it does >>>> not break, by supplying the older library that CSWbar requires. >>> >>> That's clear. What I had in mind is: how do we prevent our libraries >>> from growing indefinitely in size due to stale dependent packages? > > If an orphaned package depends on a legacy lib you have to keep it. > Or update the orphaned package yourself or find somebody. I see. Too bad, that's a complication I had hoped was possible to avoid. I revisited the modulation presentation from Oslo, it looks like I need to learn more on how to do create multi-version library packages. I'll try to find time this weekend to see if I get this to work. I'm thinking of creating a mgar/pkg/examples directory and putting there a few minimal examples, similar to minimalsmf. Maciej From dam at opencsw.org Thu Sep 24 13:52:37 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Thu, 24 Sep 2009 13:52:37 +0200 (CEST) Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: <86E3FB84-4E6D-48DC-9F5B-DAFED4EE7F3E@opencsw.org> Message-ID: Hi Maciej, > I revisited the modulation presentation from Oslo, it looks like I > need to learn more on how to do create multi-version library packages. > I'll try to find time this weekend to see if I get this to work. I'm > thinking of creating a mgar/pkg/examples directory and putting there a > few minimal examples, similar to minimalsmf. Sure. You can also do cd mgar/pkg grep EXTRA_MODULATORS */trunk/Makefile | grep GARVERSION for examples, some easy ones, some advanced. Feel free to link on them if you are writing up docs as real-world examples. And of course ask any time if you have troubles with modulations :-) Best regards -- Dago From maciej at opencsw.org Thu Sep 24 18:33:43 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 24 Sep 2009 17:33:43 +0100 Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: <86E3FB84-4E6D-48DC-9F5B-DAFED4EE7F3E@opencsw.org> Message-ID: On Thu, Sep 24, 2009 at 12:52 PM, wrote: > Hi Maciej, > >> I revisited the modulation presentation from Oslo, it looks like I >> need to learn more on how to do create multi-version library packages. >> I'll try to find time this weekend to see if I get this to work. I'm >> thinking of creating a mgar/pkg/examples directory and putting there a >> few minimal examples, similar to minimalsmf. > > Sure. You can also do > ?cd mgar/pkg > ?grep EXTRA_MODULATORS */trunk/Makefile | grep GARVERSION > for examples, some easy ones, some advanced. Feel free to link on them > if you are writing up docs as real-world examples. And of course ask > any time if you have troubles with modulations :-) You can always count on me coming up with troubles! ;-) (I'm serious, I'm doing in such a way that I am going to get errors, I'm interested in the kinds of errors I'm going to get and what the fixes are going to be.) Here's a short version-modulated package example: http://dpaste.com/97707/ It's telling me this: gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/examples/modulations/trunk' [merge-license] complete for modulatedpkg. [merge] complete for modulatedpkg. pkgproto: ERROR: unable to stat Failed to generate prototype at /home/maciej/src/opencsw/pkg/examples/modulations/trunk/gar/bin/cswproto line 129. gmake: *** [work/build-global/prototype] Error 1 What is it missing? The destination directories surely get created: maciej at build10s [build10s]:~/src/opencsw/pkg/examples/modulations/trunk > tree work/install-isa-sparcv8-garversion-* work/install-isa-sparcv8-garversion-1.0 `-- opt `-- csw `-- share `-- example-1.0.txt work/install-isa-sparcv8-garversion-1.1 `-- opt `-- csw `-- share `-- example-1.1.txt work/install-isa-sparcv8-garversion-2.0 `-- opt `-- csw `-- share `-- example-2.0.txt 9 directories, 3 files Is it because of the missing merge targets? Maciej From dam at opencsw.org Thu Sep 24 18:53:38 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Thu, 24 Sep 2009 18:53:38 +0200 (CEST) Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: <86E3FB84-4E6D-48DC-9F5B-DAFED4EE7F3E@opencsw.org> Message-ID: <6ed6bc150f2ccd2345d02d5dac826789.squirrel@mail.opencsw.org> Hi Maciej, > On Thu, Sep 24, 2009 at 12:52 PM, wrote: >> Hi Maciej, >> >>> I revisited the modulation presentation from Oslo, it looks like I >>> need to learn more on how to do create multi-version library packages. >>> I'll try to find time this weekend to see if I get this to work. I'm >>> thinking of creating a mgar/pkg/examples directory and putting there a >>> few minimal examples, similar to minimalsmf. >> >> Sure. You can also do >> ??cd mgar/pkg >> ??grep EXTRA_MODULATORS */trunk/Makefile | grep GARVERSION >> for examples, some easy ones, some advanced. Feel free to link on them >> if you are writing up docs as real-world examples. And of course ask >> any time if you have troubles with modulations :-) > > You can always count on me coming up with troubles! ;-) > > (I'm serious, I'm doing in such a way that I am going to get errors, > I'm interested in the kinds of errors I'm going to get and what the > fixes are going to be.) > > Here's a short version-modulated package example: > > http://dpaste.com/97707/ > > It's telling me this: > > gmake[1]: Leaving directory > `/home/maciej/src/opencsw/pkg/examples/modulations/trunk' > [merge-license] complete for modulatedpkg. > [merge] complete for modulatedpkg. > pkgproto: ERROR: unable to stat > > Failed to generate prototype at > /home/maciej/src/opencsw/pkg/examples/modulations/trunk/gar/bin/cswproto > line 129. > gmake: *** [work/build-global/prototype] Error 1 > > What is it missing? The destination directories surely get created: > > maciej at build10s > [build10s]:~/src/opencsw/pkg/examples/modulations/trunk > tree > work/install-isa-sparcv8-garversion-* > work/install-isa-sparcv8-garversion-1.0 > `-- opt > `-- csw > `-- share > `-- example-1.0.txt > work/install-isa-sparcv8-garversion-1.1 > `-- opt > `-- csw > `-- share > `-- example-1.1.txt > work/install-isa-sparcv8-garversion-2.0 > `-- opt > `-- csw > `-- share > `-- example-2.0.txt > > 9 directories, 3 files > > Is it because of the missing merge targets? Yes. If you are using EXTRA_MODULATORS you must have custom merge rules. I may add version modulations as default some time. Just see any of the examples. Best regards -- Dago From phil at bolthole.com Thu Sep 24 18:57:14 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Sep 2009 09:57:14 -0700 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <4ABAA654.1000706@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> Message-ID: On Wed, Sep 23, 2009 at 3:51 PM, Sebastian Kayser wrote: >.... > You are right, Gentoo simply passes the upstream name pyyaml [1]. Ubuntu > (like Debian) renames it to python-yaml [2] though. > >> pyyaml is a well-known exception to the usual py_ convention > > If we follow that road we leave it up to every maintainer to decide what > is "well-known". Plus there might be as many "well-known" (pygtk, > pysqlite, pyxml, etc. [3,4,5]) module packages as non-"well-known" > packages, which gets us half py* and half py_* packages. well I think that "half" is an exaggeration. Or if it is, it's only because we are falling behind in the number of python modules we have packaged, compared to what is out there! > Not to mention, > packages like SOAPy/SOAPpy where you wouldn't even have the common py > prefix. Hmm. that one is a bit hairy. (But then, SOAP stuff has always been disgusting anyway ;-) You do bring up good points though. This might be an issue to bring up for a general vote. From phil at bolthole.com Thu Sep 24 18:59:00 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Sep 2009 09:59:00 -0700 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <4ABAA654.1000706@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> Message-ID: On Wed, Sep 23, 2009 at 3:51 PM, Sebastian Kayser wrote: > > ?py_ > > Here, is absolutely non-ambiguous; one refers to this name > when importing a python module. Would a general policy like this (also > applied to pyyaml, modulename: yaml) hurt? I don't think so. > PS: I forgot to mention my thoughts, that for PURE "modules" only, this makes a good idea of sense to me. But what about python "applications"? or what about things that are part module, and part application? From skayser at opencsw.org Thu Sep 24 19:02:23 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 24 Sep 2009 19:02:23 +0200 (CEST) Subject: [csw-maintainers] OpenCSW Winter Camp 2009, when/where? Feedback needed. Message-ID: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> Hi guys, before we head to Toronto next year in summer :D, i would like to kick off this year's winter camp preparations for Munich. Two votes need your input. - Which weekend can you participate? http://doodle.com/p3rvwqkx542cu4rx - Which venue would you prefer (city/nature)? http://doodle.com/xwnhvxp274i8b3iv Please participate so that we can proceed with the plannings. If you have any questions or feedback, please let me know. Similar to the past camps, i have created a wiki page on http://wiki.opencsw.org/wintercamp-2009 which we can use for planning purposes and for gathering ideas. Thanks Sebastian From phil at bolthole.com Thu Sep 24 22:36:20 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Sep 2009 13:36:20 -0700 Subject: [csw-maintainers] gar_devel In-Reply-To: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> References: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Sep 23, 2009 at 6:50 PM, Ben Walton wrote: > > So I was having a look at www-mockup tonight and I followed the link > to preparing a working build environment. ?That page lists the > packages required by GAR to get up and running. ?I thought 'why not > make this easier'... > > I put together a dummy package called gar_devel (CSWgardevel) that > simply depends on all of the listed packages. ?It's in testing/ now. > > If it's useful, I'll release it and the reference page can be > updated. ?Otherwise, I'll squash it and forget about the 5 wasted > minutes. > Could you describe more precisely what you mean by "get up and running" please? From william at wbonnet.net Thu Sep 24 22:36:32 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 24 Sep 2009 22:36:32 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4AB9B97A.800@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> Message-ID: <4ABBD850.40603@wbonnet.net> Hi There was no more replies, so may be when can finalize the choice. Do we keep the x prefix, or are we moving to something more detailled. I would like us to make a decision before too much work has been done. And i know that Dago already did some renaming before i asked the question. Proposition are listed in this poll : http://doodle.com/huc5w789f4gmft79 cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From bwalton at opencsw.org Thu Sep 24 22:39:53 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 24 Sep 2009 16:39:53 -0400 Subject: [csw-maintainers] gar_devel In-Reply-To: References: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> Message-ID: <1253824699-sup-7197@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Sep 24 16:36:20 -0400 2009: > Could you describe more precisely what you mean by "get up and > running" please? Suck in all the packages required by GAR. Instead of: pkgutil -i CSWautoconf CSWgtar CSWgmake CSW... ... it would become: pkgutil -i CSWgardevel Easier to type and can be updated to reflect any future changes to GAR requirements. It doesn't bring a GAR package itself, but it makes getting started easier. It's a 'lazy web' kind of thing. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Thu Sep 24 22:51:48 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Sep 2009 13:51:48 -0700 Subject: [csw-maintainers] gar_devel In-Reply-To: <1253824699-sup-7197@ntdws12.chass.utoronto.ca> References: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> <1253824699-sup-7197@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Sep 24, 2009 at 1:39 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Sep 24 16:36:20 -0400 2009: > >> Could you describe more precisely what you mean by "get up and >> running" please? > > Suck in all the packages required by GAR. sorry for being dense.. but what definition of "by GAR" do you mean? - to USE gar, to build something from a gar spec, that the user happens to have already laying around? - to use **CSW gar**, to specifically check something out from *our* subversion tree, and build it? - to possibly modify [csw gar] codebase or something, but not neccessarily to DO any work "using gar"? (that's what the name "gardevel" implies. to ME, at least) > Easier to type and can be updated to reflect any future changes to GAR > requirements. ?It doesn't bring a GAR package itself, but it makes > getting started easier. ?It's a 'lazy web' kind of thing. Why not "make a gar package" straight up, instead of going halfway? We badly need it. and Dago is too busy to do it :) A suggestion: I personally think a package layout that makes sense for that would be: 1. CSWgar - a package of "the gar build system/utilities", independant of anything else 2. CSWcswgar - a layer on top of CSWgar, that adds in all the OpenCSW specific stuff, to generic GAR, plus adds in a subversion dependancy, etc. From dam at opencsw.org Thu Sep 24 23:06:06 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 24 Sep 2009 23:06:06 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4ABBD850.40603@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: <59946DCE-F172-4832-82A1-3D7D34D3942E@opencsw.org> Hi, Am 24.09.2009 um 22:36 schrieb William Bonnet: > There was no more replies, so may be when can finalize the choice. > Do we keep the x prefix, or are we moving to something more > detailled. I would like us to make a decision before too much work > has been done. And i know that Dago already did some renaming before > i asked the question. > > Proposition are listed in this poll : > > http://doodle.com/huc5w789f4gmft79 Are you really thinking the proposed naming is good? The original names are fontsproto glproto inputproto kbproto recordproto renderproto videoproto xcb-proto xextproto xproto Having x11proto_fonts_devel is so much different from the original name fontsproto that I wouldn't know what to install. Best regards -- Dago From dam at opencsw.org Thu Sep 24 23:10:36 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 24 Sep 2009 23:10:36 +0200 Subject: [csw-maintainers] gar_devel In-Reply-To: References: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> <1253824699-sup-7197@ntdws12.chass.utoronto.ca> Message-ID: Hi Phil, Am 24.09.2009 um 22:51 schrieb Philip Brown: > On Thu, Sep 24, 2009 at 1:39 PM, Ben Walton > wrote: >> Excerpts from Philip Brown's message of Thu Sep 24 16:36:20 -0400 >> 2009: >> >>> Could you describe more precisely what you mean by "get up and >>> running" please? >> >> Suck in all the packages required by GAR. > > sorry for being dense.. but what definition of "by GAR" do you mean? The base packages from CSW needed to build packages with GAR. >> Easier to type and can be updated to reflect any future changes to >> GAR >> requirements. It doesn't bring a GAR package itself, but it makes >> getting started easier. It's a 'lazy web' kind of thing. > > Why not "make a gar package" straight up, instead of going halfway? > We badly need it. and Dago is too busy to do it :) Partly, yes. But we already have it in mgar/pkg/gar. However, this would only be useful if every commit to GAR would trigger a rebuild (buildbot?) And source packages. > A suggestion: I personally think a package layout that makes sense for > that would be: > > 1. CSWgar - a package of "the gar build system/utilities", > independant of anything else > 2. CSWcswgar - a layer on top of CSWgar, that adds in all the OpenCSW > specific stuff, to generic GAR, plus adds in a subversion dependancy, > etc. I disagree here. Either you choose source packages with a packaged GAR or "developer mode" with Bens base and GAR and build descriptions from the repository. Mixed mode calls for trouble. Best regards -- Dago From william at wbonnet.net Thu Sep 24 23:18:36 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 24 Sep 2009 23:18:36 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <59946DCE-F172-4832-82A1-3D7D34D3942E@opencsw.org> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> <59946DCE-F172-4832-82A1-3D7D34D3942E@opencsw.org> Message-ID: <4ABBE22C.1060802@wbonnet.net> Hi > Having x11proto_fonts_devel is so much different from the original > name fontsproto that I wouldn't know what to install. This naming is based on the debian way of naming. I agree that may be confusing if you compare to the original name. But this make sense to me to add the _devel suffix since it is a real devel package. If you look to its content, same kind of content for other libs are devel packages. x11_fontsproto_devel is maybe closer to the original. BTW, you will certainly never have to install it by yourself since it is mostly a depend file (i personnaly never installed this one on a linux box). Using this scheme or another, is not the major issue for me. I would only like we all agree on the same naming, and be sure to have a conclusion (i asked another question after the discussion between you and Phil...). I'm asking this to be sure there is no more pending question about this before more work is done. cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From phil at bolthole.com Thu Sep 24 23:25:56 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Sep 2009 14:25:56 -0700 Subject: [csw-maintainers] gar_devel In-Reply-To: References: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> <1253824699-sup-7197@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Sep 24, 2009 at 2:10 PM, Dagobert Michelsen wrote: > >> >> Why not "make a gar package" straight up, instead of going halfway? >> We badly need it. and Dago is too busy to do it :) > > Partly, yes. But we already have it in mgar/pkg/gar. However, this would > only be useful if every commit to GAR would trigger a rebuild (buildbot?) > And source packages. I wouldnt say "only be useful". It is still useful. Consider that most projects dont do "releases" every time someone changes something in subversion. Creating a new package, would be equivalent to "doing a release". > >> A suggestion: I personally think a package layout that makes sense for >> that would be: >> >> 1. CSWgar ?- a package of "the gar build system/utilities", >> independant of anything else >> 2. CSWcswgar - a layer on top of CSWgar, that adds in all the OpenCSW >> specific stuff, to generic GAR, plus adds in a subversion dependancy, >> etc. > > I disagree here. Either you choose source packages with a packaged > GAR or "developer mode" with Bens base and GAR and build descriptions > from the repository. Mixed mode calls for trouble. You seem to be discounting the notion of "get GAR accepted as a good build system in its own right". If you dont provide a "separate", generic package of GAR, that will never happen. It should not be much more effort, so why not do it? It would probably keep GAR design cleaner that way too. Consider Apache, and Ant. (not that I LIKE ant... but its the general principle of separation that I respect there :-) From skayser at opencsw.org Thu Sep 24 23:38:12 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 24 Sep 2009 23:38:12 +0200 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> Message-ID: <4ABBE6C4.3040600@opencsw.org> Philip Brown wrote on 24.09.2009 18:59: > On Wed, Sep 23, 2009 at 3:51 PM, Sebastian Kayser wrote: >> py_ >> >> Here, is absolutely non-ambiguous; one refers to this name >> when importing a python module. Would a general policy like this (also >> applied to pyyaml, modulename: yaml) hurt? I don't think so. > > PS: I forgot to mention my thoughts, that for PURE "modules" only, > this makes a good idea of sense to me. > But what about python "applications"? or what about things that are > part module, and part application? I just went through our packages to get a feeling of what we have. In the "part module, part application" or "python application" section, i would see people being interested in the application, not in the modules. The contained modules most likely only support the application after all. Examples: - mercurial - buildbot - trac - fetchmailconf - gitosis - ... Makes sense to keep the upstream name here. There are some corner cases like "twisted" [1] or "pil" [2], where i wouldn't know offhand what to do best (they are mainly libs, but also have some stuff in /opt/csw/bin). So how about 1) If it's a pure module, py_. 2) If it's main use is as application, . 3) In case of doubt, cross-check with other distributions?. With step 1) un-ambiguously catching alot and step 2) then being an easy call mostly, we will have covered the majority of packages. The few remaining ones might as well be decided on a case-by-case basis. Sebastian [1] http://www.opencsw.org/packages/twisted [2] http://www.opencsw.org/packages/pil From william at wbonnet.net Thu Sep 24 23:40:20 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 24 Sep 2009 23:40:20 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4ABBE22C.1060802@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> <59946DCE-F172-4832-82A1-3D7D34D3942E@opencsw.org> <4ABBE22C.1060802@wbonnet.net> Message-ID: <4ABBE744.2040102@wbonnet.net> Hi all I've added a few more proto packages in testing. Please notice that the renaming is not yet done ! These packages are built "ok" but have to be renamed, they are here only to be able to build some libs... I'll rename all these this week end then submit the proto to current. cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From bwalton at opencsw.org Fri Sep 25 00:41:30 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 24 Sep 2009 18:41:30 -0400 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <4ABBE6C4.3040600@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> Message-ID: <1253832055-sup-9675@ntdws12.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Thu Sep 24 17:38:12 -0400 2009: > So how about > 1) If it's a pure module, py_. > 2) If it's main use is as application, . > 3) In case of doubt, cross-check with other distributions?. Logical and concise. +1. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Sep 25 00:55:29 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Sep 2009 15:55:29 -0700 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <1253832055-sup-9675@ntdws12.chass.utoronto.ca> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Sep 24, 2009 at 3:41 PM, Ben Walton wrote: > Excerpts from Sebastian Kayser's message of Thu Sep 24 17:38:12 -0400 2009: >> So how about >> 1) If it's a pure module, py_. >> 2) If it's main use is as application, . >> 3) In case of doubt, cross-check with other distributions?. > > Logical and concise. ?+1. > > -Ben > -- works for me. only thing left to do is pick a place to officially document this, unless there are objections. traditionally, the person in charge of [language], has primarily been in charge of [stuff to do with that language]. Since Mike Watters is our current python maintainer: Mike, how about I give you perms to edit http://www.opencsw.org/standards/python, and you fill in that, and anything else you think appropriate? From bwalton at opencsw.org Fri Sep 25 04:20:37 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 24 Sep 2009 22:20:37 -0400 Subject: [csw-maintainers] C++ hell with Sun Studio and GCC In-Reply-To: References: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> <1253553057-sup-1892@ntdws12.chass.utoronto.ca> Message-ID: <1253845097-sup-1817@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Sep 22 01:45:33 -0400 2009: > So I propose making a Solaris 8 Ruby with GCC if you really need it > and starting with Solaris 9 and Sun Studio 12 for eveything else. Ok. That's what I'll do. > BTW, are you interested in packaging up RubeEE and Phusion Passenger? > > I would need that also for my project, but as Ruby maintainer this > would naturally be more on your side ;-) I don't use either of these, although Phusion might be interesting. We're about to order replacement hardware for the box running our RoR site though and the new setup won't be running solaris at all...My requirement of keeping solaris 8 support will soon be gone. I'll only need ruby for non-web stuff on our other solaris boxen. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Fri Sep 25 08:38:07 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Sep 2009 08:38:07 +0200 Subject: [csw-maintainers] Problem compiling Python files Message-ID: <0227CF3D-4B4B-4617-AAE8-E23BF480F934@opencsw.org> Hi Ben, hi Mike, when I updated some packages this morning I got these errors: > ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > dtdparser.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/dtdparser.py', 500, 33, '\t elif self.now_at("#FIXED"): > \n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > errors.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > namespace.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > utils.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xcatalog.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlapp.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmldtd.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/xmldtd.py', 318, 37, '\t"True if \'state\' is a final > state."\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlproc.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/xmlproc.py', 341, 6, '\ttry:\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlutils.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlval.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/xmlval.py', 174, 38, '\tdecl_root = self.dtd.get_root_elem() > \n')) > Listing /opt/csw/lib/python/site-packages/_xmlplus/sax ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/sax/ > __init__.py ... > ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/schema ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/schema/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/schema/ > trex.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/schema/ > trex.py', 1464, 38, '\tfor remainder in match_1.remainders:\n')) > Listing /opt/csw/lib/python/site-packages/_xmlplus/unicode ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/unicode/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/unicode/ > iso8859.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/unicode/ > utf8_iso.py ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/utils ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > characters.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > iso8601.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > qp_xml.py ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/xpath ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > BuiltInExtFunctions.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/xpath/ > BuiltInExtFunctions.py', 22, 37, '\tfrom Ft.__init__ import > __version__\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > Context.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > Conversions.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > CoreFunctions.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ExpandedNameWrapper.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > MessageSource.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > NamespaceNode.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAbbreviatedAbsoluteLocationPath.py ... > SyntaxError: ('invalid syntax', ('/opt/csw/lib/python/site-packages/ > _xmlplus/xpath/ParsedAbbreviatedAbsoluteLocationPath.py', 27, 10, > " as = ParsedAxisSpecifier.ParsedAxisSpecifier('descendant-or- > self')\n")) > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAbbreviatedRelativeLocationPath.py ... > SyntaxError: ('invalid syntax', ('/opt/csw/lib/python/site-packages/ > _xmlplus/xpath/ParsedAbbreviatedRelativeLocationPath.py', 31, 10, > " as = ParsedAxisSpecifier.ParsedAxisSpecifier('descendant-or- > self')\n")) > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAbsoluteLocationPath.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAxisSpecifier.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedExpr.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedNodeTest.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedPredicateList.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedRelativeLocationPath.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedStep.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/Set.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/Util.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > XPathGrammar.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > XPathParser.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > XPathParserBase.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > pyxpath.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/xpath/ > pyxpath.py', 264, 46, '\tyappsrt.SyntaxError.__init__(self, pos, msg) > \n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > yappsrt.py ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/xslt ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ApplyTemplatesElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > AttributeElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > AttributeSetElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > AttributeValueTemplate.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > BuiltInExtElements.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CallTemplateElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ChooseElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CommentElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CopyElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CopyOfElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ElementElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ForEachElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > HtmlWriter.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > IfElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > LiteralElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > LiteralText.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > MessageElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > MessageSource.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > NullWriter.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/xslt/ > NullWriter.py', 36, 8, '\treturn\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > NumberElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > OtherXslElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > OtherwiseElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > OutputHandler.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParamElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedLocationPathPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedRelativePathPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedStepPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > PlainTextWriter.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ProcessingInstructionElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > Processor.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/Roman.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > RtfWriter.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > SortElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > Stylesheet.py ... > SyntaxError: ('invalid syntax', ('/opt/csw/lib/python/site-packages/ > _xmlplus/xslt/Stylesheet.py', 376, 14, ' for as in > attribute_sets:\n')) > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > StylesheetReader.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > TemplateElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > TextElement.py ... > ... Do you mind having a look? Best regards -- Dago From dam at opencsw.org Fri Sep 25 08:40:46 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Sep 2009 08:40:46 +0200 Subject: [csw-maintainers] Problem compiling Python files Message-ID: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> Hi Ben, hi Mike, when I updated some packages this morning I got these errors: > ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > dtdparser.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/dtdparser.py', 500, 33, '\t elif self.now_at("#FIXED"): > \n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > errors.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > namespace.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > utils.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xcatalog.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlapp.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmldtd.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/xmldtd.py', 318, 37, '\t"True if \'state\' is a final > state."\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlproc.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/xmlproc.py', 341, 6, '\ttry:\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlutils.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlval.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/xmlval.py', 174, 38, '\tdecl_root = self.dtd.get_root_elem() > \n')) > Listing /opt/csw/lib/python/site-packages/_xmlplus/sax ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/sax/ > __init__.py ... > ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/schema ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/schema/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/schema/ > trex.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/schema/ > trex.py', 1464, 38, '\tfor remainder in match_1.remainders:\n')) > Listing /opt/csw/lib/python/site-packages/_xmlplus/unicode ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/unicode/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/unicode/ > iso8859.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/unicode/ > utf8_iso.py ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/utils ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > characters.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > iso8601.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > qp_xml.py ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/xpath ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > BuiltInExtFunctions.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/xpath/ > BuiltInExtFunctions.py', 22, 37, '\tfrom Ft.__init__ import > __version__\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > Context.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > Conversions.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > CoreFunctions.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ExpandedNameWrapper.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > MessageSource.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > NamespaceNode.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAbbreviatedAbsoluteLocationPath.py ... > SyntaxError: ('invalid syntax', ('/opt/csw/lib/python/site-packages/ > _xmlplus/xpath/ParsedAbbreviatedAbsoluteLocationPath.py', 27, 10, > " as = ParsedAxisSpecifier.ParsedAxisSpecifier('descendant-or- > self')\n")) > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAbbreviatedRelativeLocationPath.py ... > SyntaxError: ('invalid syntax', ('/opt/csw/lib/python/site-packages/ > _xmlplus/xpath/ParsedAbbreviatedRelativeLocationPath.py', 31, 10, > " as = ParsedAxisSpecifier.ParsedAxisSpecifier('descendant-or- > self')\n")) > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAbsoluteLocationPath.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAxisSpecifier.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedExpr.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedNodeTest.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedPredicateList.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedRelativeLocationPath.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedStep.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/Set.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/Util.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > XPathGrammar.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > XPathParser.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > XPathParserBase.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > pyxpath.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/xpath/ > pyxpath.py', 264, 46, '\tyappsrt.SyntaxError.__init__(self, pos, msg) > \n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > yappsrt.py ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/xslt ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ApplyTemplatesElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > AttributeElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > AttributeSetElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > AttributeValueTemplate.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > BuiltInExtElements.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CallTemplateElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ChooseElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CommentElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CopyElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CopyOfElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ElementElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ForEachElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > HtmlWriter.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > IfElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > LiteralElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > LiteralText.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > MessageElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > MessageSource.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > NullWriter.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/xslt/ > NullWriter.py', 36, 8, '\treturn\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > NumberElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > OtherXslElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > OtherwiseElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > OutputHandler.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParamElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedLocationPathPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedRelativePathPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedStepPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > PlainTextWriter.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ProcessingInstructionElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > Processor.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/Roman.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > RtfWriter.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > SortElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > Stylesheet.py ... > SyntaxError: ('invalid syntax', ('/opt/csw/lib/python/site-packages/ > _xmlplus/xslt/Stylesheet.py', 376, 14, ' for as in > attribute_sets:\n')) > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > StylesheetReader.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > TemplateElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > TextElement.py ... > ... Do you mind having a look? Best regards -- Dago From maciej at opencsw.org Fri Sep 25 10:11:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 25 Sep 2009 09:11:39 +0100 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> Message-ID: On Fri, Sep 25, 2009 at 7:40 AM, Dagobert Michelsen wrote: > Hi Ben, hi Mike, > > when I updated some packages this morning I got these errors: Was it an update from current or from testing? How to reproduce this problem? Maciej From dam at opencsw.org Fri Sep 25 12:00:04 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Sep 2009 12:00:04 +0200 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> Message-ID: <94334879-8269-43B0-9995-7ACDCE124BF8@opencsw.org> Hi Maciej, Am 25.09.2009 um 10:11 schrieb Maciej (Matchek) Blizinski: > On Fri, Sep 25, 2009 at 7:40 AM, Dagobert Michelsen > wrote: >> Hi Ben, hi Mike, >> >> when I updated some packages this morning I got these errors: > > Was it an update from current or from testing? How to reproduce this > problem? From current/, I just installed some stuff that pulled in the updates. Best regards -- Dago From maciej at opencsw.org Fri Sep 25 12:59:51 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 25 Sep 2009 11:59:51 +0100 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: <94334879-8269-43B0-9995-7ACDCE124BF8@opencsw.org> References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> <94334879-8269-43B0-9995-7ACDCE124BF8@opencsw.org> Message-ID: On Fri, Sep 25, 2009 at 11:00 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 25.09.2009 um 10:11 schrieb Maciej (Matchek) Blizinski: >> >> On Fri, Sep 25, 2009 at 7:40 AM, Dagobert Michelsen >> wrote: >>> >>> Hi Ben, hi Mike, >>> >>> when I updated some packages this morning I got these errors: >> >> Was it an update from current or from testing? How to reproduce this >> problem? > > From current/, I just installed some stuff that pulled in the updates. I couldn't reproduce that. Perhaps there were old .py files lying around? I'm guessing one of the guilty packages was py_libxml2, right? Maciej From bwalton at opencsw.org Fri Sep 25 14:27:20 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Sep 2009 08:27:20 -0400 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> Message-ID: <1253881445-sup-3063@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Sep 25 02:40:46 -0400 2009: Hi Dago, > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > > dtdparser.py ... > > Sorry: TabError: ('inconsistent use of tabs and spaces in > > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > > xmlproc/dtdparser.py', 500, 33, '\t elif self.now_at("#FIXED"): > > \n')) That file seems to be part of CSWpyxml, which has a REV stamp of 2008.03.17, which is well before cswpycompile came about. I don't see a version of it in testing/, either. It _shouldn't_, as far as I can tell, even be compiling its files at install time. I pulled it onto a machine here and didn't get the errors. Am I missing something? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Fri Sep 25 14:39:09 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 25 Sep 2009 13:39:09 +0100 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: <1253881445-sup-3063@ntdws12.chass.utoronto.ca> References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> <1253881445-sup-3063@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Sep 25, 2009 at 1:27 PM, Ben Walton wrote: > Excerpts from Dagobert Michelsen's message of Fri Sep 25 02:40:46 -0400 2009: > > Hi Dago, > >> > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ >> > dtdparser.py ... >> > Sorry: TabError: ('inconsistent use of tabs and spaces in >> > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ >> > xmlproc/dtdparser.py', 500, 33, '\t ? ?elif self.now_at("#FIXED"): >> > \n')) > > That file seems to be part of CSWpyxml, which has a REV stamp of > 2008.03.17, which is well before cswpycompile came about. ?I don't see > a version of it in testing/, either. ?It _shouldn't_, as far as I can > tell, even be compiling its files at install time. > > I pulled it onto a machine here and didn't get the errors. > > Am I missing something? I kept on seeing that each time I installed a Python package using cswpycompile, it could (re)compile all the existing .py files, not just the ones being installed. Perhaps there were .py files lying around? Try to put a broken .py file in site-packages and reinstall the package. When I do that and install any package which uses cswpycompile, I'm getting: Compiling /opt/csw/lib/python/site-packages/broken.py ... Sorry: IndentationError: ('unexpected indent', ('/opt/csw/lib/python/site-packages/broken.py', 3, 2, '\t\t"is"\n')) Maciej From bwalton at opencsw.org Fri Sep 25 15:24:28 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Sep 2009 09:24:28 -0400 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> <1253881445-sup-3063@ntdws12.chass.utoronto.ca> Message-ID: <1253884984-sup-3102@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Sep 25 08:39:09 -0400 2009: > I kept on seeing that each time I installed a Python package using > cswpycompile, it could (re)compile all the existing .py files, not > just the ones being installed. Perhaps there were .py files lying > around? Try to put a broken .py file in site-packages and reinstall > the package. Ok, so you're saying the cswpycompile is slurping up too much when it runs? I haven't looked (recently) at this... To trigger this bug then, you'd need to update a package that uses cswpycompile and any another python package regardless of cswpycompile use? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Fri Sep 25 15:43:34 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 25 Sep 2009 14:43:34 +0100 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: <1253884984-sup-3102@ntdws12.chass.utoronto.ca> References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> <1253881445-sup-3063@ntdws12.chass.utoronto.ca> <1253884984-sup-3102@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Sep 25, 2009 at 2:24 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Fri Sep 25 08:39:09 -0400 2009: > >> I kept on seeing that each time I installed a Python package using >> cswpycompile, it could (re)compile all the existing .py files, not >> just the ones being installed. Perhaps there were .py files lying >> around? Try to put a broken .py file in site-packages and reinstall >> the package. > > Ok, so you're saying the cswpycompile is slurping up too much when it > runs? ?I haven't looked (recently) at this... > > To trigger this bug then, you'd need to update a package that uses > cswpycompile and any another python package regardless of cswpycompile > use? Yes. In other words, to reproduce: echo '"' > /opt/csw/lib/python/site-packages/broken.py pkgutil -i py_fpconst | less From bwalton at opencsw.org Fri Sep 25 19:05:47 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Sep 2009 13:05:47 -0400 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> <1253881445-sup-3063@ntdws12.chass.utoronto.ca> <1253884984-sup-3102@ntdws12.chass.utoronto.ca> Message-ID: <1253898268-sup-3010@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Sep 25 09:43:34 -0400 2009: > > To trigger this bug then, you'd need to update a package that uses > > cswpycompile and any another python package regardless of cswpycompile > > use? > > Yes. In other words, to reproduce: > > echo '"' > /opt/csw/lib/python/site-packages/broken.py > pkgutil -i py_fpconst | less Ok, looking at the script, this is exactly what happens. It would only get tripped when there is a package supplying bad files though, which is why it didn't show up until now. I seem to recall Mike saying that executing the compilations per-file instead of as a batch like this was too slow. Mike, can you corroborate with my memory on this? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Sep 25 19:23:25 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 25 Sep 2009 10:23:25 -0700 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <59946DCE-F172-4832-82A1-3D7D34D3942E@opencsw.org> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> <59946DCE-F172-4832-82A1-3D7D34D3942E@opencsw.org> Message-ID: On Thu, Sep 24, 2009 at 2:06 PM, Dagobert Michelsen wrote: > > > Are you really thinking the proposed naming is good? >.... > > Having x11proto_fonts_devel is so much different from the original > name fontsproto that I wouldn't know what to install. yes. plus to me, its just too durn long :-} From phil at bolthole.com Fri Sep 25 19:27:58 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 25 Sep 2009 10:27:58 -0700 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4ABBD850.40603@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: On Thu, Sep 24, 2009 at 1:36 PM, William Bonnet wrote: > > Proposition are listed in this poll : > > http://doodle.com/huc5w789f4gmft79 > i finally got around to looking at this... and seems like an option is missing. you were comparing what happens to something called "fooproto". you give "xfooxproto" as an option (which is very confusing to me, sticking something in the MIDDLE). But you dont have "xfooproto" as an option. I guess I personally like x11_fooproto even more anyways. but just saying that the choices seem a little short. From maciej at opencsw.org Fri Sep 25 20:48:29 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 25 Sep 2009 19:48:29 +0100 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: <1253898268-sup-3010@ntdws12.chass.utoronto.ca> References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> <1253881445-sup-3063@ntdws12.chass.utoronto.ca> <1253884984-sup-3102@ntdws12.chass.utoronto.ca> <1253898268-sup-3010@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Sep 25, 2009 at 6:05 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Fri Sep 25 09:43:34 -0400 2009: >> > To trigger this bug then, you'd need to update a package that uses >> > cswpycompile and any another python package regardless of cswpycompile >> > use? >> >> Yes. In other words, to reproduce: >> >> echo '"' > /opt/csw/lib/python/site-packages/broken.py >> pkgutil -i py_fpconst | less > > Ok, looking at the script, this is exactly what happens. ?It would > only get tripped when there is a package supplying bad files though, > which is why it didn't show up until now. Perhaps Python update? There were things that Python 2.5 would turn a blind eye to, but Python 2.6 would not. It'd be nice to have a check for this problem. I'm sure it can be caught during package creation stage. Maciej From trygvis at opencsw.org Fri Sep 25 21:34:56 2009 From: trygvis at opencsw.org (=?UTF-8?B?VHJ5Z3ZlIExhdWdzdMO4bA==?=) Date: Fri, 25 Sep 2009 21:34:56 +0200 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <1253832055-sup-9675@ntdws12.chass.utoronto.ca> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> Message-ID: <4ABD1B60.5060700@opencsw.org> Ben Walton wrote: > Excerpts from Sebastian Kayser's message of Thu Sep 24 17:38:12 -0400 2009: >> So how about >> 1) If it's a pure module, py_. >> 2) If it's main use is as application, . >> 3) In case of doubt, cross-check with other distributions?. > > Logical and concise. +1. Ditto. +1. -- Trygve From dam at opencsw.org Sat Sep 26 10:59:25 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 26 Sep 2009 10:59:25 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: Hi, Am 25.09.2009 um 19:27 schrieb Philip Brown: > On Thu, Sep 24, 2009 at 1:36 PM, William Bonnet > wrote: >> >> Proposition are listed in this poll : >> >> http://doodle.com/huc5w789f4gmft79 >> > > i finally got around to looking at this... and seems like an option > is missing. > > you were comparing what happens to something called "fooproto". > > you give "xfooxproto" as an option (which is very confusing to me, > sticking something in the MIDDLE). But you dont have "xfooproto" as > an option. William, Sebastian, Maciej: Why do you think it is a good idea to reorder the naming parts of the software? Like inputproto -> x11proto_input And I don't want to hear "for consistency", Maciej ;-) Best regards -- Dago From maciej at opencsw.org Sat Sep 26 12:03:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 26 Sep 2009 11:03:30 +0100 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: On Sat, Sep 26, 2009 at 9:59 AM, Dagobert Michelsen wrote: > Hi, > > Am 25.09.2009 um 19:27 schrieb Philip Brown: > >> On Thu, Sep 24, 2009 at 1:36 PM, William Bonnet >> wrote: >>> >>> Proposition are listed in this poll : >>> >>> http://doodle.com/huc5w789f4gmft79 >>> >> >> i finally got around to looking at this... and seems like an option is >> missing. >> >> you were comparing what happens to something called "fooproto". >> >> you give "xfooxproto" as an option (which is very confusing to me, >> sticking something in the MIDDLE). But you dont have "xfooproto" as >> an option. > > William, Sebastian, Maciej: Why do you think it is a good idea to > reorder the naming parts of the software? Like > inputproto -> x11proto_input > > And I don't want to hear "for consistency", Maciej ;-) Actually, I thought about suggesting compressing the prefix even more. We've got pm_* and py_*, right? If there's a whole category of X11 protocols, why not have xp_*? A counterargument could be that xp_* is not self explanatory. Well, neither is pm_*. If anyone is interested in what those packages are (that xp stands for X11 protocol), descriptions will help. What do you think? Maciej From maciej at opencsw.org Sat Sep 26 18:06:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 26 Sep 2009 17:06:13 +0100 Subject: [csw-maintainers] Package comparator Message-ID: Today's shameless plug: I hacked together a small (200 lines of code) tool to compare prototypes of packages. It's especially useful when GAR-ifying packages and making sure that whatever was in the old packages is also present in the new one. It's also useful if one wants to find out whether the new package version contains files with higher major library version. I've submitted the code to the opencsw (!= gar) repository. To get it: $ svn co https://opencsw.svn.sourceforge.net/svnroot/opencsw opencsw To run it: $ opencsw/utilities/compare_pkgs.py -h Usage: compare_pkgs.py [options] Options: -h, --help show this help message and exit -d, --debug -a PACKAGE_DIR_A, --package-dir-a=PACKAGE_DIR_A Package directory A -b PACKAGE_DIR_B, --package-dir-b=PACKAGE_DIR_B Package directory B -c CATALOG_NAME, --catalog-name=CATALOG_NAME Catalog name, for example 'cups' -p, --permissions Whether to analyze permission bits My typical usage scenario would be: $ compare_pkgs.py -a ./old-packages -b ~/staging/build-2009-09-26 -c mysql5 It's a quickly hacked tool and might have rough edges; but I think even now it can be useful for other people. Feel free to flame me now. ;-) Maciej From skayser at opencsw.org Sat Sep 26 19:58:36 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sat, 26 Sep 2009 19:58:36 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: <4ABE564C.6070502@opencsw.org> Dagobert Michelsen wrote on 26.09.2009 10:59: > Am 25.09.2009 um 19:27 schrieb Philip Brown: > >> On Thu, Sep 24, 2009 at 1:36 PM, William Bonnet >> wrote: >>> Proposition are listed in this poll : >>> >>> http://doodle.com/huc5w789f4gmft79 >>> >> i finally got around to looking at this... and seems like an option >> is missing. >> >> you were comparing what happens to something called "fooproto". >> >> you give "xfooxproto" as an option (which is very confusing to me, >> sticking something in the MIDDLE). But you dont have "xfooproto" as >> an option. > > William, Sebastian, Maciej: Why do you think it is a good idea to > reorder the naming parts of the software? Like > inputproto -> x11proto_input Simply as a way to group them via a common prefix. But honestly, i don't mind having a shorter one either. We will hit the 20 chars limit with x11proto_ and that in turn will drag a whole other discussion with it. One that we need to have some time, but maybe not this time. Sebastian From william at wbonnet.net Sun Sep 27 22:11:37 2009 From: william at wbonnet.net (William Bonnet) Date: Sun, 27 Sep 2009 22:11:37 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4ABE564C.6070502@opencsw.org> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> <4ABE564C.6070502@opencsw.org> Message-ID: <4ABFC6F9.7030600@wbonnet.net> Hi > Simply as a way to group them via a common prefix. But honestly, i don't > mind having a shorter one either. > > We will hit the 20 chars limit with x11proto_ and that in turn will drag > a whole other discussion with it. One that we need to have some time, > but maybe not this time. > So do we agree that : For proto packages We add a x11_ prefix to all proto files We keep the name of the package unchanged after the prefix Proto packages that are not named like fooproto, are also unchanged and prefix by x11_ Devel suffix will not be used for these files (even if the contains the same kind of files as _devel packages) Example : fooproto -> x11_fooproto xbarproto -> x11_xbarproto muf -> x11_muf For X11/libs We don't change anything I have commited almost all the proto and libs that were pending on my side. I still have a few options to add to be consistent with Dago's modifications (i am thinking of some extra merge steps). But before doing it i have to release and thus rename a few proto packages. Cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From dam at opencsw.org Sun Sep 27 23:23:05 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 27 Sep 2009 23:23:05 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4ABFC6F9.7030600@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> <4ABE564C.6070502@opencsw.org> <4ABFC6F9.7030600@wbonnet.net> Message-ID: Hi William, Am 27.09.2009 um 22:11 schrieb William Bonnet: >> Simply as a way to group them via a common prefix. But honestly, i >> don't >> mind having a shorter one either. >> >> We will hit the 20 chars limit with x11proto_ and that in turn will >> drag >> a whole other discussion with it. One that we need to have some time, >> but maybe not this time. >> > So do we agree that : > For proto packages > We add a x11_ prefix to all proto files > We keep the name of the package unchanged after the prefix > Proto packages that are not named like fooproto, are also unchanged > and prefix by x11_ > Devel suffix will not be used for these files (even if the contains > the same kind of files as _devel packages) > > Example : fooproto -> x11_fooproto > xbarproto -> x11_xbarproto > muf -> x11_muf > > For X11/libs > We don't change anything > > I have commited almost all the proto and libs that were pending on > my side. I still have a few options to add to be consistent with > Dago's modifications (i am thinking of some extra merge steps). But > before doing it i have to release and thus rename a few proto > packages. This sounds like a good solution :-) Feel free to release any proto you see missing. Best regards -- Dago From rupert at opencsw.org Sun Sep 27 23:37:36 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 27 Sep 2009 23:37:36 +0200 Subject: [csw-maintainers] svn-1.6.5 in testing Message-ID: <6af4270909271437u15d3abbajec081df8fb57d9c@mail.gmail.com> hi, i upgraded svn to 1.6.5 and put it into testing, will test it in our environment this week. the packages are writeable for everybody, so you can overwrite them. rupert. From dam at opencsw.org Mon Sep 28 10:57:20 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 28 Sep 2009 10:57:20 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: Hi Maciej, Am 26.09.2009 um 12:03 schrieb Maciej (Matchek) Blizinski: > On Sat, Sep 26, 2009 at 9:59 AM, Dagobert Michelsen > wrote: >> Hi, >> >> Am 25.09.2009 um 19:27 schrieb Philip Brown: >> >>> On Thu, Sep 24, 2009 at 1:36 PM, William Bonnet >>> >>> wrote: >>>> >>>> Proposition are listed in this poll : >>>> >>>> http://doodle.com/huc5w789f4gmft79 >>>> >>> >>> i finally got around to looking at this... and seems like an >>> option is >>> missing. >>> >>> you were comparing what happens to something called "fooproto". >>> >>> you give "xfooxproto" as an option (which is very confusing to me, >>> sticking something in the MIDDLE). But you dont have "xfooproto" as >>> an option. >> >> William, Sebastian, Maciej: Why do you think it is a good idea to >> reorder the naming parts of the software? Like >> inputproto -> x11proto_input >> >> And I don't want to hear "for consistency", Maciej ;-) > > Actually, I thought about suggesting compressing the prefix even more. > We've got pm_* and py_*, right? If there's a whole category of X11 > protocols, why not have xp_*? A counterargument could be that xp_* is > not self explanatory. Well, neither is pm_*. It is, because the files end in .pm :-) > If anyone is interested > in what those packages are (that xp stands for X11 protocol), > descriptions will help. What do you think? The proposed solution from William with a simple prefix and leaving the rest as defined by upstream sounds very reasonable to me. Best regards -- Dago From maciej at opencsw.org Mon Sep 28 16:31:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 28 Sep 2009 15:31:30 +0100 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: On Mon, Sep 28, 2009 at 9:57 AM, Dagobert Michelsen wrote: >> Actually, I thought about suggesting compressing the prefix even more. >> We've got pm_* and py_*, right? If there's a whole category of X11 >> protocols, why not have xp_*? A counterargument could be that xp_* is >> not self explanatory. Well, neither is pm_*. > > It is, because the files end in .pm :-) That's an excellent ignotum per ignotious right there! ;-) >> If anyone is interested >> in what those packages are (that xp stands for X11 protocol), >> descriptions will help. What do you think? > > The proposed solution from William with a simple prefix and leaving the > rest as defined by upstream sounds very reasonable to me. The x11_foo, where foo is an upstream name which might be ending in 'proto'? It sounds reasonable too, I just wanted to put the shortest possible option out there, so that it can get considered. Maciej From phil at bolthole.com Mon Sep 28 17:18:50 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Sep 2009 08:18:50 -0700 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4ABFC6F9.7030600@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> <4ABE564C.6070502@opencsw.org> <4ABFC6F9.7030600@wbonnet.net> Message-ID: On Sun, Sep 27, 2009 at 1:11 PM, William Bonnet wrote: > > So do we agree that : > For proto packages > ? ? ? ?We add a x11_ prefix to all proto files > ? ? ? ?We keep the name of the package unchanged after the prefix > ? ? ? ?Proto packages that are not named like fooproto, are also unchanged > and prefix by x11_ > ? ? ? ?Devel suffix will not be used for these files (even if the contains > the same kind of files as _devel packages) > > ? ? ? ?Example : fooproto ?-> x11_fooproto > ? ? ? ? ? ? ? ? ?xbarproto -> x11_xbarproto > ? ? ? ? ? ? ? ? ?muf ? ? ? -> x11_muf > with the additional, explicit understanding, that at this time, this ONLY applies to x11 related prototype packages, and NOTHING else... yes I am ok with this also From phil at bolthole.com Mon Sep 28 17:25:47 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Sep 2009 08:25:47 -0700 Subject: [csw-maintainers] Package comparator In-Reply-To: References: Message-ID: On Sat, Sep 26, 2009 at 9:06 AM, Maciej (Matchek) Blizinski wrote: > Today's shameless plug: I hacked together a small (200 lines of code) > tool to compare prototypes of packages. It's especially useful when > GAR-ifying packages and making sure that whatever was in the old > packages is also present in the new one. excellent! we've been needing this for a long time. > $ opencsw/utilities/compare_pkgs.py -h Please rename it to be just "compare_pkgs", though? there's no need to have a .py "extention". we're not dealing with web server cgi interpreters here :-) From maciej at opencsw.org Mon Sep 28 17:37:26 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 28 Sep 2009 16:37:26 +0100 Subject: [csw-maintainers] Package comparator In-Reply-To: References: Message-ID: On Mon, Sep 28, 2009 at 4:25 PM, Philip Brown wrote: > On Sat, Sep 26, 2009 at 9:06 AM, Maciej (Matchek) Blizinski > wrote: >> Today's shameless plug: I hacked together a small (200 lines of code) >> tool to compare prototypes of packages. It's especially useful when >> GAR-ifying packages and making sure that whatever was in the old >> packages is also present in the new one. > > excellent! we've been needing this for a long time. > > >> $ opencsw/utilities/compare_pkgs.py -h > > Please rename it to be just "compare_pkgs", though? > there's no need to have a .py "extention". we're not dealing with web > server cgi interpreters here :-) Yes, that's the plan. The actual binary when deployed will probably be /opt/csw/bin/compare-pkgs; It's going to be a wrapper calling out to /opt/csw/lib/csw/python (or something similar), which is going to contain the compare_pkgs.py file. There's also the opencsw_lib.py with common functions, shared by more Python scripts from the utilities directory. I was thinking that this script could be added to the CSWcswutils package. Maciej From phil at bolthole.com Mon Sep 28 18:20:53 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Sep 2009 09:20:53 -0700 Subject: [csw-maintainers] Package comparator In-Reply-To: References: Message-ID: On Mon, Sep 28, 2009 at 8:37 AM, Maciej (Matchek) Blizinski wrote: > > I was thinking that this script could be added to the CSWcswutils package. > I think that is a good idea... I just wasnt sure if it was gar-specific. Is it? will it be useful if someone is not using gar? From skayser at opencsw.org Mon Sep 28 21:12:07 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 28 Sep 2009 21:12:07 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? Message-ID: <4AC10A87.1090205@opencsw.org> Hi, pkgutil was placed straight at the mirror root a while ago to facilitate downloading, but it doesn't seem to get updates. The version floating around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please be fixed (and be kept in sync in the future pleeeaase :). Furthermore, could pkgutil be made an ARCH=all package, so that there is just _one_ direct link that one can point new users to and not a platform specific one (i know about uname -p, still it just makes things more straightforward)? I see, the package contains a wget which is platform specific. Couldn't we just include two wgets (wget.i386, wget.sparc)? From what i remember, that is the same approach Sun uses for its explorer package. Sebastian [1]http://www.ibiblio.org/pub/packages/solaris/opencsw/pkgutil-i386.pkg [2]http://www.ibiblio.org/pub/packages/solaris/opencsw/pkgutil-sparc.pkg From dam at opencsw.org Mon Sep 28 21:16:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 28 Sep 2009 21:16:43 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <4AC10A87.1090205@opencsw.org> References: <4AC10A87.1090205@opencsw.org> Message-ID: <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> Hi Sebastian, Am 28.09.2009 um 21:12 schrieb Sebastian Kayser: > pkgutil was placed straight at the mirror root a while ago to > facilitate > downloading, but it doesn't seem to get updates. The version floating > around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please be > fixed (and be kept in sync in the future pleeeaase :). > > Furthermore, could pkgutil be made an ARCH=all package, so that > there is > just _one_ direct link that one can point new users to and not a > platform specific one (i know about uname -p, still it just makes > things > more straightforward)? > > I see, the package contains a wget which is platform specific. > Couldn't > we just include two wgets (wget.i386, wget.sparc)? From what i > remember, > that is the same approach Sun uses for its explorer package. This was Peters intent, but Phil argued strongly against having ARCHALL=1 packages with arch-specific binaries. See the thread for details: Best regards -- Dago From maciej at opencsw.org Mon Sep 28 21:36:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 28 Sep 2009 20:36:54 +0100 Subject: [csw-maintainers] Package comparator In-Reply-To: References: Message-ID: On Mon, Sep 28, 2009 at 5:20 PM, Philip Brown wrote: > On Mon, Sep 28, 2009 at 8:37 AM, Maciej (Matchek) Blizinski > wrote: >> >> I was thinking that this script could be added to the CSWcswutils package. >> > > > I think that is a good idea... I just wasnt sure if it was gar-specific. > Is it? > will it be useful if someone is not using gar? Yes it will; it only requires Python, gunzip and pkgtrans to run. Maciej From dam at opencsw.org Mon Sep 28 21:43:52 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 28 Sep 2009 21:43:52 +0200 Subject: [csw-maintainers] Package comparator In-Reply-To: References: Message-ID: <62B51B99-0D5D-4546-90F6-70E1A06C5E69@opencsw.org> Hi Phil, Am 28.09.2009 um 18:20 schrieb Philip Brown: > On Mon, Sep 28, 2009 at 8:37 AM, Maciej (Matchek) Blizinski > wrote: >> >> I was thinking that this script could be added to the CSWcswutils >> package. > > I think that is a good idea... I just wasnt sure if it was gar- > specific. > Is it? > will it be useful if someone is not using gar? It has nothing to do with GAR, it works on .pkg-files. Best regards -- Dago From phil at bolthole.com Mon Sep 28 22:12:46 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Sep 2009 13:12:46 -0700 Subject: [csw-maintainers] Package comparator In-Reply-To: <62B51B99-0D5D-4546-90F6-70E1A06C5E69@opencsw.org> References: <62B51B99-0D5D-4546-90F6-70E1A06C5E69@opencsw.org> Message-ID: On Mon, Sep 28, 2009 at 12:43 PM, Dagobert Michelsen wrote: > > It has nothing to do with GAR, it works on .pkg-files. > > great! well lets see it added then :) From skayser at opencsw.org Mon Sep 28 22:15:06 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 28 Sep 2009 22:15:06 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> Message-ID: <4AC1194A.3040308@opencsw.org> Dagobert Michelsen wrote on 28.09.2009 21:16: > Am 28.09.2009 um 21:12 schrieb Sebastian Kayser: >> pkgutil was placed straight at the mirror root a while ago to >> facilitate >> downloading, but it doesn't seem to get updates. The version floating >> around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please be >> fixed (and be kept in sync in the future pleeeaase :). >> >> Furthermore, could pkgutil be made an ARCH=all package, so that >> there is >> just _one_ direct link that one can point new users to and not a >> platform specific one (i know about uname -p, still it just makes >> things >> more straightforward)? >> >> I see, the package contains a wget which is platform specific. >> Couldn't >> we just include two wgets (wget.i386, wget.sparc)? From what i >> remember, >> that is the same approach Sun uses for its explorer package. > > This was Peters intent, but Phil argued strongly against having > ARCHALL=1 > packages with arch-specific binaries. See the thread for details: > > Wow, that's a huge discussion. I couldn't resist thinking about our motto (while reading): "to provide a straightforward, easy-to-use experience for the user" pkgutil is one out of two possible packages of ours that a user comes across first. While i see that there is a need to decide about what should be an ARCH=all package, i don't really see the need to make an example of pkgutil (considering that one could argue both ways). :/ Sebastian From phil at bolthole.com Mon Sep 28 22:15:13 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Sep 2009 13:15:13 -0700 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <4AC10A87.1090205@opencsw.org> References: <4AC10A87.1090205@opencsw.org> Message-ID: On Mon, Sep 28, 2009 at 12:12 PM, Sebastian Kayser wrote: > Hi, > > pkgutil was placed straight at the mirror root a while ago to facilitate > downloading, but it doesn't seem to get updates. The version floating > around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please be > fixed (and be kept in sync in the future pleeeaase :). >.... > > I see, the package contains a wget which is platform specific. Couldn't > we just include two wgets (wget.i386, wget.sparc)? for the record, that's exactly we provide "two wgets" binaries, in the mirror root itself, directly. Kinda silly to include yet another wget binary wrapped in a package at that level, isnt it? From dam at opencsw.org Mon Sep 28 22:20:58 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 28 Sep 2009 22:20:58 +0200 Subject: [csw-maintainers] Package comparator In-Reply-To: References: <62B51B99-0D5D-4546-90F6-70E1A06C5E69@opencsw.org> Message-ID: <71CDDB93-A1E1-41E2-8F97-45C61CFD910C@opencsw.org> Hi, Am 28.09.2009 um 22:12 schrieb Philip Brown: > On Mon, Sep 28, 2009 at 12:43 PM, Dagobert Michelsen > wrote: >> >> It has nothing to do with GAR, it works on .pkg-files. > > great! > well lets see it added then :) Maciej, the files for cswutils directly live in Would you mind putting it there so I can make an update release? Best regards -- Dago From skayser at opencsw.org Mon Sep 28 22:23:54 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 28 Sep 2009 22:23:54 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: References: <4AC10A87.1090205@opencsw.org> Message-ID: <4AC11B5A.7030409@opencsw.org> Philip Brown wrote on 28.09.2009 22:15: > On Mon, Sep 28, 2009 at 12:12 PM, Sebastian Kayser wrote: >> Hi, >> >> pkgutil was placed straight at the mirror root a while ago to facilitate >> downloading, but it doesn't seem to get updates. The version floating >> around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please be >> fixed (and be kept in sync in the future pleeeaase :). >> .... >> >> I see, the package contains a wget which is platform specific. Couldn't >> we just include two wgets (wget.i386, wget.sparc)? > > for the record, that's exactly we provide "two wgets" binaries, in the > mirror root itself, directly. > Kinda silly to include yet another wget binary wrapped in a package at > that level, isnt it? As a user, i never cared about those wgets in particular. What i cared about and still do care about is a working and easily distributable package utility. Sebastian From maciej at opencsw.org Tue Sep 29 09:50:43 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 29 Sep 2009 08:50:43 +0100 Subject: [csw-maintainers] Package comparator In-Reply-To: <71CDDB93-A1E1-41E2-8F97-45C61CFD910C@opencsw.org> References: <62B51B99-0D5D-4546-90F6-70E1A06C5E69@opencsw.org> <71CDDB93-A1E1-41E2-8F97-45C61CFD910C@opencsw.org> Message-ID: On Mon, Sep 28, 2009 at 9:20 PM, Dagobert Michelsen wrote: > Maciej, the files for cswutils directly live in > > Would you mind putting it there so I can make an update release? I've updated the build file. I implemented pulling a specific revision from subversion, with checksums checking: http://sourceforge.net/apps/trac/gar/changeset/6601 Maciej From dam at opencsw.org Tue Sep 29 11:36:25 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 29 Sep 2009 11:36:25 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <4AC11B5A.7030409@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC11B5A.7030409@opencsw.org> Message-ID: <4D1296B1-F7A4-4479-B27F-F29F86A97450@opencsw.org> Hi Sebastian, Am 28.09.2009 um 22:23 schrieb Sebastian Kayser: > Philip Brown wrote on 28.09.2009 22:15: >> On Mon, Sep 28, 2009 at 12:12 PM, Sebastian Kayser > > wrote: >>> Hi, >>> >>> pkgutil was placed straight at the mirror root a while ago to >>> facilitate >>> downloading, but it doesn't seem to get updates. The version >>> floating >>> around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please >>> be >>> fixed (and be kept in sync in the future pleeeaase :). >>> .... >>> >>> I see, the package contains a wget which is platform specific. >>> Couldn't >>> we just include two wgets (wget.i386, wget.sparc)? >> >> for the record, that's exactly we provide "two wgets" binaries, in >> the >> mirror root itself, directly. >> Kinda silly to include yet another wget binary wrapped in a package >> at >> that level, isnt it? > > As a user, i never cared about those wgets in particular. What i cared > about and still do care about is a working and easily distributable > package utility. I am in favor of making an exception here for ARCHALL too. If it helps making the user experience easier wgets should be included, for pkg-get and pkgutil. Best regards -- Dago From bwalton at opencsw.org Tue Sep 29 14:48:26 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 29 Sep 2009 08:48:26 -0400 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <4D1296B1-F7A4-4479-B27F-F29F86A97450@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC11B5A.7030409@opencsw.org> <4D1296B1-F7A4-4479-B27F-F29F86A97450@opencsw.org> Message-ID: <1254228339-sup-3541@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Sep 29 05:36:25 -0400 2009: > I am in favor of making an exception here for ARCHALL too. If it helps > making the user experience easier wgets should be included, for pkg-get > and pkgutil. Things have changed since the last discussion too. Solaris 8 is best effort only now. Does 9 include LWP::FTP (or whatever) such that wget isn't required as part of the bootstrapping process? I'm not saying that pkgutil should abandon solaris 8, but it may at least be an option. Given the above, I was and still am in favour of the exception in this case. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Tue Sep 29 22:23:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 29 Sep 2009 21:23:58 +0100 Subject: [csw-maintainers] Links from mantis to the 'processing bugs' wiki page Message-ID: Some time ago Dago has written the following page on the wiki: http://wiki.opencsw.org/processing-bugs Would it be hard to include links to this page in Mantis? I was thinking about two places: 1. The header at Mantis, somewhere in the white area to the right of the big blue "OpenCSW Bug Tracker" at the top. 2. The weekly nagging e-mail. What do you think about this? Maciej From glaw at opencsw.org Tue Sep 29 23:17:08 2009 From: glaw at opencsw.org (Gary Law) Date: Tue, 29 Sep 2009 22:17:08 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: 2009/9/23 Philip Brown : >> -- >> Gary Law >> glaw at blastwave.org LOL .... slip of the keyboard ;) -- Gary Law glaw at opencsw.org From bonivart at opencsw.org Wed Sep 30 09:33:19 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 30 Sep 2009 09:33:19 +0200 Subject: [csw-maintainers] Get zero deps with GAR? Message-ID: <625385e30909300033n4a413c46v2c648b90907b72d7@mail.gmail.com> How do I create a package with no dependencies at all with GAR? It always adds common (and perl if it's cpan), how can I override that? -- /peter From dam at opencsw.org Wed Sep 30 10:27:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 30 Sep 2009 10:27:02 +0200 Subject: [csw-maintainers] Get zero deps with GAR? In-Reply-To: <625385e30909300033n4a413c46v2c648b90907b72d7@mail.gmail.com> References: <625385e30909300033n4a413c46v2c648b90907b72d7@mail.gmail.com> Message-ID: <616A3ABB-CAA2-4191-BA65-C25C192D7317@opencsw.org> Hi Peter, Am 30.09.2009 um 09:33 schrieb Peter Bonivart: > How do I create a package with no dependencies at all with GAR? It > always adds common (and perl if it's cpan), how can I override that? The easiest way is to use a custom gspec file. In the dynamic gspec section there is a line %include url file://csw_dyngspec.gspec which includes the file %include url file://%{PKGLIB}/csw_vars.gspec %include url file://%{PKGLIB}/csw_prototype.gspec %pkginfo url file://%{WORKSRC}/csw/pkginfo %depend:merge url file://%{PKGLIB}/csw/depend %include url file://%{PKGLIB}/std_depend.gspec The file pkglib/csw/depend contains the dependency to CSWcommon. All gspecs include that one. So, add something like this to files/CSWpkgutil.gspec: %var bitname pkgutil %var pkgname CSWpkgutil %include url file://%{PKGLIB}/csw_vars.gspec %include url file://%{PKGLIB}/csw_prototype.gspec %pkginfo url file://%{WORKSRC}/csw/pkginfo %include url file://%{PKGLIB}/std_depend.gspec That is, put in the lines from the include with the depend line skipped. It may be good to do more of this inside the GAR Makefile in the future. Best regards -- Dago From dam at opencsw.org Wed Sep 30 15:28:07 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 30 Sep 2009 15:28:07 +0200 Subject: [csw-maintainers] Berkeley DB pending final resolution Message-ID: Hi, due to the involved complexities I am currently rebuilding Berkeley DB in a defined way, where each version gets its own very separate directories. That means there is /opt/csw/bdb43 /opt/csw/bdb44 /opt/csw/bdb... for all relevant versions. The legacy link for /opt/csw/bdb4 will be linked to the contents of /opt/csw/bdb42 making the contained 4.2 version explicit. The generic bdb will be deprecated, the newly build packages should instead be recompiled against bdb47. The existing bdb3 will stay at 3.3.11, updated are neither required nor intended. Linking in the future will always be against specific versions like /opt/csw/bdbXY If we can't unify it let's make it as clean and separate as possible. Feedback? Best regards -- Dago From james at opencsw.org Wed Sep 30 16:55:18 2009 From: james at opencsw.org (James Lee) Date: Wed, 30 Sep 2009 14:55:18 GMT Subject: [csw-maintainers] Berkeley DB pending final resolution In-Reply-To: References: Message-ID: <20090930.14551800.454845078@gyor.oxdrove.co.uk> On 30/09/09, 14:28:07, Dagobert Michelsen wrote regarding [csw-maintainers] Berkeley DB pending final resolution: > due to the involved complexities I am currently rebuilding Berkeley DB > in a defined way, where each version gets its own very separate > directories. > That means there is > /opt/csw/bdb43 > /opt/csw/bdb44 > /opt/csw/bdb... > for all relevant versions. The legacy link for > /opt/csw/bdb4 > will be linked to the contents of /opt/csw/bdb42 making the contained > 4.2 version explicit. The generic bdb will be deprecated, the newly > build > packages should instead be recompiled against bdb47. This is basically back to what it was before in recognition of Berkley DB versions being mutual incompatible. Until existing packages are recompiled your new final solution will break recently built packages that expect 4.7 in /opt/csw/lib. You will have to arrange for atomic release with rebuilds or legacy 4.7 links in the legacy CSWbdb and CSWbdb4 packages. Affected packages: CSWooocore uses 4.7 from CSWbdb4 (CSWbdb4 uses CSWbdb) CSWperl uses 4.7 from CSWbdb CSWpmberkeleydb uses 4.7 from CSWbdb CSWruby uses 4.7 from CSWbdb James. From bonivart at opencsw.org Wed Sep 30 16:55:31 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 30 Sep 2009 16:55:31 +0200 Subject: [csw-maintainers] Get zero deps with GAR? In-Reply-To: <616A3ABB-CAA2-4191-BA65-C25C192D7317@opencsw.org> References: <625385e30909300033n4a413c46v2c648b90907b72d7@mail.gmail.com> <616A3ABB-CAA2-4191-BA65-C25C192D7317@opencsw.org> Message-ID: <625385e30909300755p73e0fae9wc9d750612842510e@mail.gmail.com> On Wed, Sep 30, 2009 at 10:27 AM, Dagobert Michelsen wrote: > The easiest way is to use a custom gspec file. That's how I do it now. I can't get rid of the gspec then. For now... :-) -- /peter From dam at opencsw.org Wed Sep 30 17:06:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 30 Sep 2009 17:06:19 +0200 Subject: [csw-maintainers] Berkeley DB pending final resolution In-Reply-To: <20090930.14551800.454845078@gyor.oxdrove.co.uk> References: <20090930.14551800.454845078@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 30.09.2009 um 16:55 schrieb James Lee: > On 30/09/09, 14:28:07, Dagobert Michelsen wrote > regarding > [csw-maintainers] Berkeley DB pending final resolution: > >> due to the involved complexities I am currently rebuilding Berkeley >> DB >> in a defined way, where each version gets its own very separate >> directories. >> That means there is >> /opt/csw/bdb43 >> /opt/csw/bdb44 >> /opt/csw/bdb... >> for all relevant versions. The legacy link for >> /opt/csw/bdb4 >> will be linked to the contents of /opt/csw/bdb42 making the contained >> 4.2 version explicit. The generic bdb will be deprecated, the newly >> build >> packages should instead be recompiled against bdb47. > > This is basically back to what it was before in recognition of > Berkley DB versions being mutual incompatible. > > Until existing packages are recompiled your new final solution will > break recently built packages that expect 4.7 in /opt/csw/lib. > You will have to arrange for atomic release with rebuilds or legacy > 4.7 links in the legacy CSWbdb and CSWbdb4 packages. I am thinking of legacy links. Fortunately the newly released packages are well maintained and could be rebuild in a reasonable timeframe making the legacy links obsolete soon. Long-term I would want to get rid of the generic CSWbdb and CSWbdb4 and the libs in /opt/csw/lib. > Affected packages: > CSWooocore uses 4.7 from CSWbdb4 (CSWbdb4 uses CSWbdb) > CSWperl uses 4.7 from CSWbdb > CSWpmberkeleydb uses 4.7 from CSWbdb > CSWruby uses 4.7 from CSWbdb Best regards -- Dago From daniel at pocock.com.au Fri Sep 11 18:28:01 2009 From: daniel at pocock.com.au (Daniel Pocock) Date: Fri, 11 Sep 2009 16:28:01 -0000 Subject: [csw-maintainers] libconfuse and Solaris 10 version In-Reply-To: References: Message-ID: <4AAA7A92.5020801@pocock.com.au> Dagobert Michelsen wrote: > Hi Daniel, > > there are two versions of libconfuse in testing, one for Solaris 8+9 and > one for Solaris 10. There is only one version synced to the mirrors: > Solaris 8. Is this what you intended? > Yes, Phil asked me to only supply a Solaris 8 version unless there is a significant reason for having a special Solaris 10 package. I'll remove them all from testing now. From dam at baltic-online.de Fri Sep 11 20:59:05 2009 From: dam at baltic-online.de (Dagobert Michelsen) Date: Fri, 11 Sep 2009 18:59:05 -0000 Subject: [csw-maintainers] Updated TCPWrappers Message-ID: Hi, there is an updated tcpwrappers package in testing now with both 32 and 64 bit. It was quite hard to build and without Phils notices I probably wouldn't have managed to do it. If you use tcpwrappers with standard or extended configuration files please test it and let me know if it works as I don't use tcpwrappers myself (but a lot of my packages depend on tcpwrappers and there was not 64 bit libs). Best regards -- Dago From bchill at bch.net Mon Sep 21 00:19:39 2009 From: bchill at bch.net (Brian Hill) Date: Sun, 20 Sep 2009 22:19:39 +0000 Subject: [csw-maintainers] librsync 0.9.7 uploaded to testing Message-ID: <20090920221939.GA25482@vm-1.bch.net> I have uploaded librsync for testing. It isn't all that useful by itself, but it is needed for rdiff-backup, which is coming soon. Does the descriptions file update at regular intervals or is it done by hand? A pkg-get of librsync from testing doesn't work yet. Brian From philatbolthole at gmail.com Mon Sep 21 04:19:59 2009 From: philatbolthole at gmail.com (Philip Brown) Date: Sun, 20 Sep 2009 19:19:59 -0700 Subject: [csw-maintainers] big package update in testing/ In-Reply-To: <1253403883-sup-5997@ntdws12.chass.utoronto.ca> References: <1253403883-sup-5997@ntdws12.chass.utoronto.ca> Message-ID: <16A40B7B-FBFD-415B-B59F-9072DC2CD970@gmail.com> very cool. you might check with dago to see if it's ok to put the update script also on the testing dir. it probably is. From bonivart at opencsw.org Tue Sep 1 00:09:16 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 1 Sep 2009 00:09:16 +0200 Subject: [csw-maintainers] Firefox 3 release In-Reply-To: <4A9C47D6.4010501@wbonnet.net> References: <4A9C47D6.4010501@wbonnet.net> Message-ID: <625385e30908311509x7959e9cdn520bd4421c3e21c6@mail.gmail.com> On Mon, Aug 31, 2009 at 11:59 PM, William Bonnet wrote: > Hi, > > I'm pleased to announced that Firefox 3.0.13 has been pushed to current. > This version supports Solaris 8 and newer (thanks goes to James Lee for > pointing me the solution). > > Thunderbird has also been updated to version 2.0.0.23, latest stable before > TB3 is released. Nice work! Very high profile packages. -- /peter From trygvis at opencsw.org Tue Sep 1 01:06:35 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 01 Sep 2009 01:06:35 +0200 Subject: [csw-maintainers] robots.txt In-Reply-To: References: <4A9C3D84.5080609@opencsw.org> Message-ID: <4A9C577B.80509@opencsw.org> Philip Brown wrote: > 2009/8/31 Trygve Laugst?l : >> Philip Brown wrote: >>> Any robot that cant figure out to properly prune /page vs >>> /page.php, in this day and age, is a broken robot. >>> We should not modify our configs to make dumb robots look better than they >>> are. >> Actually, they're not. There's no way for the engines out there to know that >> "packages" is the same resource as "packages.php" (it can do some magic, and >> I'm sure they do when they're doing page ranking). However, they will still >> list both as hits, try to seach for "site:opencsw.org CSWbash packages" on >> google and you'll see. > > Err.. that search phrase gives a very long ... aha. now I see. > > you are referring, presumably, to the #1, and #3 results. Not sure, the search result is most likely different for you and me, but yes, there where references to most combinations of the page. > However, this rather underlines my area of concern. > > They are referenced in quite different ways. "packages/CSWbash", vs > "packages.php/bash". > Which hints that google "found" the pages in different ways. Which > hints that somewhere (probably on OUR site), there is something > incorrectly referencing "packages.php/bash" instead of > "packages/bash". > > I think we should fix those out-of-date reference styles, before > making anything canonical. Fixing references is always nice, but adding stuff (be it Apache config or PHP code) to either make sure that the ".php" variant is never used is also required. Now that the links exist, a permanent redirect would be the correct solution. > ALSO: the two results, were from DIFFERENT TIMES. They are actually > "different" pages! If in contrast, the output was the same, google > would probably have coalesced them into one, I would bet. I doubt that they will as the number of candidate pages is quite big if they first where to go down that path. The fact that they list both is to me a sign of that they store both. How would they determine the canonical one anyway? > Hence I still stand by my statement that intelligent search engines > already handle this sort of thing "properly". > It is more appropriate for us fix our internal links, rather than tell > search engines, "ignore our mangled links" ! I think that in this case fixing the references is the right solution. -- Trygve From phil at bolthole.com Tue Sep 1 01:17:52 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 31 Aug 2009 16:17:52 -0700 Subject: [csw-maintainers] robots.txt In-Reply-To: <4A9C577B.80509@opencsw.org> References: <4A9C3D84.5080609@opencsw.org> <4A9C577B.80509@opencsw.org> Message-ID: 2009/8/31 Trygve Laugst?l : > Philip Brown wrote: >The fact that they list both is to me a > sign of that they store both. How would they determine the canonical one > anyway? I would say that the common-sense answer is, if "page", and "page.anything" exists (and the content is the same), then "page" should always be canonical. after all, if "site.com/docs" exists, and "site.com/docs.php" exists... odds are that "site.com/docs" will ALWAYS exist.. but someday, they may change the backend to be .pl, or .cgi, or whoknowswhat. > >> Hence I still stand by my statement that intelligent search engines >> already handle this sort of thing "properly". >> It is more appropriate for us fix our internal links, rather than tell >> search engines, "ignore our mangled links" ! > > I think that in this case fixing the references is the right solution. I'm glad we agree there. The annoying thing is that I'm not sure where the references are, at this point. From my searching through the pages, I dont see any obvious references to ".php" in our site. So assistance from other folks in hunting those down, would be appreciated. From trygvis at opencsw.org Tue Sep 1 01:47:59 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 01 Sep 2009 01:47:59 +0200 Subject: [csw-maintainers] robots.txt In-Reply-To: References: <4A9C3D84.5080609@opencsw.org> <4A9C577B.80509@opencsw.org> Message-ID: <4A9C612F.2090103@opencsw.org> Philip Brown wrote: > 2009/8/31 Trygve Laugst?l : >> Philip Brown wrote: >> The fact that they list both is to me a >> sign of that they store both. How would they determine the canonical one >> anyway? > > I would say that the common-sense answer is, if "page", and > "page.anything" exists (and the content is the same), then "page" > should always be canonical. > > after all, if "site.com/docs" exists, and "site.com/docs.php" > exists... odds are that "site.com/docs" will ALWAYS exist.. but > someday, they may change the backend to be .pl, or .cgi, or > whoknowswhat. > > > > >>> Hence I still stand by my statement that intelligent search engines >>> already handle this sort of thing "properly". >>> It is more appropriate for us fix our internal links, rather than tell >>> search engines, "ignore our mangled links" ! >> I think that in this case fixing the references is the right solution. > > > I'm glad we agree there. The annoying thing is that I'm not sure where > the references are, at this point. From my searching through the > pages, I dont see any obvious references to ".php" in our site. So > assistance from other folks in hunting those down, would be > appreciated. It very well might be old links that has gotten index at some point in time, and since we still return 200 OK on those URLs, Google will keep on re-indexing them. Try adding a permanent redirect from "page.php" to "page" and they will disappear after a while. Another option might be to grep the logs for ".php" and check the referer field if that is logged. Might give you a clue as well. This is where the Webmaster toolkit comes in handy, it can show you how Google view your side (not that I've used it myself, but that's what I've been told). -- Trygve From phil at bolthole.com Tue Sep 1 02:37:38 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 31 Aug 2009 17:37:38 -0700 Subject: [csw-maintainers] robots.txt In-Reply-To: <4A9C612F.2090103@opencsw.org> References: <4A9C3D84.5080609@opencsw.org> <4A9C577B.80509@opencsw.org> <4A9C612F.2090103@opencsw.org> Message-ID: 2009/8/31 Trygve Laugst?l : > > It very well might be old links that has gotten index at some point in time, > and since we still return 200 OK on those URLs, Google will keep on > re-indexing them. Try adding a permanent redirect from "page.php" to "page" > and they will disappear after a while. Seeing as how the .php page is the "real" page, that might be a little challenging. Or perhaps, since we currently have apache "fancy[somethingorother]" to auto-dereference "page", to "page.php" on the back end... there might be an apache setting to automatically redirect "page.php" to "page"? We should only do that for certain subtrees, though. not mantis ones. ugh. From jeff at cjsa.com Tue Sep 1 09:19:53 2009 From: jeff at cjsa.com (Jeffery Small) Date: Tue, 1 Sep 2009 07:19:53 GMT Subject: [csw-maintainers] sendmail and dbus packages Message-ID: Can someone please provide an update on the status of the following two open issues: 1: Is there a revised release of sendmail pending for use with the Berkeley DB 4.x problem, and have all the Berkeley DB issues been resolved? I am in a state of confusion about all this and very afraid to touch anything for fear of getting things out of sync once again. I really don't know what version of the BDB I should be running. I currently have: berkeleydb4 4.2.52,REV=2005.04.28_rev=p4 berkeleydb44 4.4.20,REV=2009.07.28 sendmail 8.14.2,REV=2007.12.17 2: Is anyone still working on the dbus package problem that is keeping Solaris SPARC from being able to disable the service and also making it impossible to cleanly shutdown the system, since we never get to the boot PROM, apparently because this service will not stop. One additional question regarding CSW sendmail. In the /opt/csw/var/spool directory, there are the following two links: ..clientmqueue -> /var/spool/clientmqueue ..mqueue -> /var/spool/mqueue These links are not listed on the webpage for sendmail as part of the package. Do these links exist on other people's systems, and if so, what is their purpose? Thanks. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From bonivart at opencsw.org Tue Sep 1 11:59:23 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 1 Sep 2009 11:59:23 +0200 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: Message-ID: <625385e30909010259r7053c7e0h611d392f28817b96@mail.gmail.com> On Tue, Sep 1, 2009 at 9:19 AM, Jeffery Small wrote: > Can someone please provide an update on the status of the following two > open issues: > > 1: ?Is there a revised release of sendmail pending for use with the Berkeley > ? ?DB 4.x problem, and have all the Berkeley DB issues been resolved? ?I > ? ?am in a state of confusion about all this and very afraid to touch anything > ? ?for fear of getting things out of sync once again. ?I really don't know > ? ?what version of the BDB I should be running. I currently have: > > ? ? ? ?berkeleydb4 ? ? ? ? ? 4.2.52,REV=2005.04.28_rev=p4 > ? ? ? ?berkeleydb44 ? ? ? ? ? ? ? ? 4.4.20,REV=2009.07.28 > ? ? ? ?sendmail ? ? ? ? ? ? ? ? ? ? 8.14.2,REV=2007.12.17 I know there's a lot of work going on to update the Sendmail package. As of now there's nothing to test though. I have several Sendmail servers and I'm holding off all updates until this is resolved. -- /peter From maciej at opencsw.org Tue Sep 1 12:11:15 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 1 Sep 2009 11:11:15 +0100 Subject: [csw-maintainers] robots.txt In-Reply-To: References: <4A9C3D84.5080609@opencsw.org> <4A9C577B.80509@opencsw.org> <4A9C612F.2090103@opencsw.org> Message-ID: On Tue, Sep 1, 2009 at 1:37 AM, Philip Brown wrote: > 2009/8/31 Trygve Laugst?l : >> >> It very well might be old links that has gotten index at some point in time, >> and since we still return 200 OK on those URLs, Google will keep on >> re-indexing them. Try adding a permanent redirect from "page.php" to "page" >> and they will disappear after a while. > > Seeing as how the .php page is the "real" page, that might be a little > challenging. > > Or perhaps, since we currently have apache "fancy[somethingorother]" > to auto-dereference "page", to "page.php" on the back end... there > might be an apache setting to automatically redirect "page.php" to > "page"? > > We should only do that for certain subtrees, though. not mantis ones. > ugh. mod_rewrite[1] could help. There could br a rule along the lines of: RewriteRule ^/packages.php(.*) /packages$1 [R=301] We'd need to test it, of course. [1] http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html#RewriteRule From maciej at opencsw.org Tue Sep 1 16:42:24 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 1 Sep 2009 15:42:24 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: <4A939902.3050808@opencsw.org> References: <4A939902.3050808@opencsw.org> Message-ID: 2009/8/25 Trygve Laugst?l : > Philip Brown wrote: >> >> I think with this sort of thing, you have to consider the likelyhood of >> breakage. >> >> If the nature of the application/configuration is relatively >> straightforward, and/or compatibility between the two versions is very >> strong, then I think the best thing to do is an automated migration. >> >> If on the other hand, breakage is very likely, then probably "halt and >> prompt" is best. >> >> An intermediate possibility, might be if the app has very good >> configuration file verification. >> >> Then you could do the automigration, VERIFY it, and then halt noisily if >> it fails verification. >> >> A post thought: in this case, I think you should always only copy; never >> remove. Worse case, 'mv' old config to config.migrated or something. > > These points sounds like a good policy to me and are similar to what I've > talked about earlier. I wrote up a comparison, for the sake of brevity, formatted as a table. It considers the simplest case, a single file which was previously on /opt/csw/etc and is going to be in /etc/opt/csw. http://wiki.opencsw.org/configuration-directory-migration In a simple case, which option people think is best? Maciej From dam at opencsw.org Tue Sep 1 16:57:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Sep 2009 16:57:49 +0200 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: Hi Maciej, Am 01.09.2009 um 16:42 schrieb Maciej (Matchek) Blizinski: > I wrote up a comparison, for the sake of brevity, formatted as a > table. It considers the simplest case, a single file which was > previously on /opt/csw/etc and is going to be in /etc/opt/csw. > > http://wiki.opencsw.org/configuration-directory-migration > > In a simple case, which option people think is best? Good comparison. In case (4) this means the file is first moved from /opt/csw/etc/foo.conf to /etc/opt/csw/foo.conf and then symlinked? So it is more like (2)+(4). Sounds for me as the best thing to do. The symlink shouldn't be in the package but generated during postinstall with errors ignored because if /etc/opt/csw is lofs'ed to /opt/csw/etc the symlink would point to itself and generation would fail as would the complete package install. Best regards -- Dago From maciej at opencsw.org Tue Sep 1 17:22:23 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 1 Sep 2009 16:22:23 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: On Tue, Sep 1, 2009 at 3:57 PM, Dagobert Michelsen wrote: > Good comparison. In case (4) this means the file is first moved > from /opt/csw/etc/foo.conf to /etc/opt/csw/foo.conf and then symlinked? > So it is more like (2)+(4). I was thinking about doing only the symlinking, so if you opened /etc/opt/csw/foo.conf, you'd get data from /opt/csw/etc/foo.conf. The actual command would be: ln -s ../../../opt/csw/etc/foo.conf ${PKG_INSTALL_ROOT}/etc/opt/csw/foo.conf > Sounds for me as the best thing to do. The symlink shouldn't be > in the package but generated during postinstall with errors ignored > because if /etc/opt/csw is lofs'ed to /opt/csw/etc the symlink would > point to itself and generation would fail as would the complete package > install. I see. Good point. Maciej From dam at opencsw.org Tue Sep 1 17:32:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Sep 2009 17:32:18 +0200 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) Message-ID: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> Hi, there is a parallel gzip in testing/ from Mark Adler: pkg-get -s http://mirror.opencsw.org/opencsw/testing -U -u pigz pkgutil -t http://mirror.opencsw.org/opencsw/testing -i pigz Some tests: > build8st% ls -l x > -rw-r--r-- 1 dam csw 336455680 Sep 1 17:05 x File is roughly 336 MB is size > build8st% time pigz x > pigz x 215.55s user 1.91s system 3065% cpu 7.094 total Compression takes 7 seconds instead 3 1/2 minutes on T5220! > build8st% time unpigz x.gz > unpigz x.gz 10.36s user 1.79s system 143% cpu 8.446 total Parallel gunzip is only 1,5 times faster > build8st% time pigz -9 x > pigz -9 x 396.91s user 1.96s system 2334% cpu 17.087 total Higher compressions take 17 seconds instead of 6 1/2 minutes!! > build8st% cksum x.gz > 585068046 123219628 x.gz Write that down. > build8st% time unpigz x.gz > unpigz x.gz 10.34s user 1.79s system 144% cpu 8.413 total > build8st% time gzip -9 x > gzip -9 x 241.84s user 1.56s system 99% cpu 4:03.40 total Traditional gzip takes less total CPU but 4 minutes total. > build8st% cksum x.gz > 206071496 123179310 x.gz Different checksum, but both archives are valid. I guess I'll switch package compression in GAR to pigz after release. Best regards -- Dago PS: ...and don't forget: it is pronounced "pig-zee" From maciej at opencsw.org Tue Sep 1 18:15:03 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 1 Sep 2009 17:15:03 +0100 Subject: [csw-maintainers] Rebuild package with an updated postinstall script Message-ID: When I update a postinstall script in files/CSWfoo.postinstall and do "gmake repackage", the GAR keeps using the old script in the package. I tried also "reinstall" and "remerge". Do you know if I can get GAR to include the updated postinstall script without recompiling the whole package? Maciej From dam at opencsw.org Tue Sep 1 18:31:53 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Sep 2009 18:31:53 +0200 Subject: [csw-maintainers] Rebuild package with an updated postinstall script In-Reply-To: References: Message-ID: <0CA83913-39A0-4792-B79C-69D5D1A5C47B@opencsw.org> Hi Maciej, Am 01.09.2009 um 18:15 schrieb Maciej (Matchek) Blizinski: > When I update a postinstall script in files/CSWfoo.postinstall and do > "gmake repackage", the GAR keeps using the old script in the package. > I tried also "reinstall" and "remerge". Do you know if I can get GAR > to include the updated postinstall script without recompiling the > whole package? Not easily, not easily. This is because the files are transferred from files/ to donwload/ to $(WORKSRC) during extract phase at the very beginning. GAR can not know what needs to be redone after anything has changed there. For testing purposes you can copy the files from download/ over to work/build-*/, but to be sure the result is reproducable the final package should be build from scratch. This all is a safety measure. It is guaranteed that there is no difference between 'gmake package' and the result after 'gmake repackage' and this guarantee can not be given when you tinker with files from the first phase. Best regards -- Dago From maciej at opencsw.org Wed Sep 2 10:58:11 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 2 Sep 2009 09:58:11 +0100 Subject: [csw-maintainers] unixODBC-2.2.14 in testing In-Reply-To: References: Message-ID: On Wed, Jul 29, 2009 at 11:24 PM, Maciej (Matchek) Blizinski wrote: > The unixODBC package, version 2.2.14 is now in testing. > > http://mirror.opencsw.org/testing/unixodbc-2.2.14,REV=2009.07.29-SunOS5.8-sparc-CSW.pkg.gz > http://mirror.opencsw.org/testing/unixodbc-2.2.14,REV=2009.07.29-SunOS5.8-i386-CSW.pkg.gz > > It's the first version built with GAR, a remake from scratch. I > haven't got access to the original package. This package doesn't > include GUI (QT) support. It keeps the configuration files in > /etc/opt/csw, as opposed to the earlier /opt/csw/etc. Please feel free > to respond with any feedback on the package. I've updated the unixodbc packages. http://mirror.opencsw.org/testing/unixodbc-2.2.14,REV=2009.09.02-SunOS5.8-i386-CSW.pkg.gz http://mirror.opencsw.org/testing/unixodbc-2.2.14,REV=2009.09.02-SunOS5.8-sparc-CSW.pkg.gz The changes include: - 64-bit binaries for sparcv9 and amd64 ISAs - A postinstall script which aids the migration of /opt/csw/etc/odbc*ini files to /etc/opt/csw. The installation should pass non-interactively and unixodbc should preserve its configuration, including the non-global zones. Hint files are placed in the /opt/csw/etc directory. Maciej From maciej at opencsw.org Wed Sep 2 13:25:55 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 2 Sep 2009 12:25:55 +0100 Subject: [csw-maintainers] unixODBC-2.2.14 in testing In-Reply-To: References: Message-ID: On Wed, Sep 2, 2009 at 9:58 AM, Maciej (Matchek) Blizinski wrote: > The changes include: > > - 64-bit binaries for sparcv9 and amd64 ISAs > - A postinstall script which aids the migration of > /opt/csw/etc/odbc*ini files to /etc/opt/csw. The installation should > pass non-interactively and unixodbc should preserve its configuration, > including the non-global zones. Hint files are placed in the > /opt/csw/etc directory. After a request from one of the maintainers, I moved the unixodbc packages to a subdirectory. The new location is: http://mirror.opencsw.org/testing/etc-migration/unixodbc-2.2.14,REV=2009.09.02-SunOS5.8-i386-CSW.pkg.gz http://mirror.opencsw.org/testing/etc-migration/unixodbc-2.2.14,REV=2009.09.02-SunOS5.8-sparc-CSW.pkg.gz Maciej From skayser at opencsw.org Wed Sep 2 13:54:23 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 02 Sep 2009 13:54:23 +0200 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: Message-ID: <4A9E5CEF.6050001@opencsw.org> Jeffery Small wrote on 01.09.2009 09:19: > Can someone please provide an update on the status of the following two > open issues: > > 1: [...] have all the Berkeley DB issues been resolved? I > am in a state of confusion about all this and very afraid to touch anything > for fear of getting things out of sync once again. +1 Same state of uncertainty here. > 2: Is anyone still working on the dbus package problem that is keeping > Solaris SPARC from being able to disable the service and also making it > impossible to cleanly shutdown the system, since we never get to the boot > PROM, apparently because this service will not stop. There should be a fixed dbus package in testing. I didn't get to test it anymore after the initial feedback. I guess William is just waiting for some feedback. http://thread.gmane.org/gmane.os.solaris.opencsw.maintainers/3409 Sebastian From dam at opencsw.org Wed Sep 2 13:39:42 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Sep 2009 13:39:42 +0200 Subject: [csw-maintainers] [csw-users] Firefox 3 release In-Reply-To: <4A9D0946.7060104@wbonnet.net> References: <4A9C47D6.4010501@wbonnet.net> <4A9D084C.1040005@ericsson.com> <4A9D0946.7060104@wbonnet.net> Message-ID: Hi William, Am 01.09.2009 um 13:45 schrieb William Bonnet: > Firefox 3.5.1 is compiling on our build farm, but it is not running > yet. We have several dependencies to update before we can release > it. Work have started on updating this libs, but it will take some > time and a lot of testing... What libs do you need to have updated for this? Best regards -- Dago From phil at bolthole.com Wed Sep 2 18:56:35 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 2 Sep 2009 09:56:35 -0700 Subject: [csw-maintainers] robots.txt In-Reply-To: References: <4A9C3D84.5080609@opencsw.org> <4A9C577B.80509@opencsw.org> <4A9C612F.2090103@opencsw.org> Message-ID: On Tue, Sep 1, 2009 at 3:11 AM, Maciej (Matchek) Blizinski wrote: > > > mod_rewrite[1] could help. There could br a rule along the lines of: > > RewriteRule ^/packages.php(.*) /packages$1 [R=301] > > We'd need to test it, of course. > > [1] http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html#RewriteRule > Not bad. I wouldnt object to Ihsan putting that in there. Although I think we should probably agree that this is a temporary cleanup,and to remove it after some fixed period of time. (6 months?) No need to throw away server resources unneccessarily, once it has served its purpose. From phil at bolthole.com Wed Sep 2 19:00:06 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 2 Sep 2009 10:00:06 -0700 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: Message-ID: On Tue, Sep 1, 2009 at 12:19 AM, Jeffery Small wrote: > Can someone please provide an update on the status of the following two > open issues: > > 1: Is there a revised release of sendmail pending for use with the Berkeley > DB 4.x problem, and have all the Berkeley DB issues been resolved? I > am in a state of confusion about all this and very afraid to touch anything > for fear of getting things out of sync once again. I really don't know > what version of the BDB I should be running. I currently have: > > berkeleydb4 4.2.52,REV=2005.04.28_rev=p4 > berkeleydb44 4.4.20,REV=2009.07.28 > sendmail 8.14.2,REV=2007.12.17 > > I previously suggested/requested that our berkeleydb maintainer(s), repackage the "berkeleyedb4" package, to include the old binaries for the shared libs, until they are no longer used. This basically echos our "normal" policies about shared libs. http://www.opencsw.org/standards/libraries " ... it is usually neccessary to include older versions of a library, in your package. So, if you are releasing libfoo.so.1.3, it is appropriate to copy in the older libfoo.so.1.2 into your package. .... until their maintainers have time to recompile." From ihsan at opencsw.org Wed Sep 2 19:15:31 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 02 Sep 2009 19:15:31 +0200 Subject: [csw-maintainers] [board] maintainer registration? In-Reply-To: <4A9CEAEE.6030708@pocock.com.au> References: <4A927A7D.70600@pocock.com.au> <4A92C8A9.1060307@pocock.com.au> <4A92EEF9.7070804@pocock.com.au> <7D46DB25-88E5-407C-A5B5-B28549D99D23@opencsw.org> <4A96ABAF.70109@pocock.com.au> <052AF7DA-8E8C-41E7-B013-93BB6352BE23@opencsw.org> <4A96EA68.8020000@pocock.com.au> <4A9A8EB4.6080602@opencsw.org> <4A9CEAEE.6030708@pocock.com.au> Message-ID: <4A9EA833.3020908@opencsw.org> Am 1.9.2009 11:35 Uhr, Daniel Pocock schrieb: >>> I haven't got an opencsw.org account as far as I know - I've tried to >>> subscribe to that list using my main email address, daniel at pocock.com.au >>> - I think it is waiting for someone to approve, because I haven't >>> received the confirmation email yet >> >> I can't approve that request because according to our policy, only >> e-mail addresses with an @opencsw.org address can be on the list. >> > Could you kindly clarify the reason for this policy? It's easier to administrate. > Adding an extra email address in my various email clients, and > remembering to change the sender address on each email I send, may only > make participating in opencsw more tedious than it should be. As far you are using Thunderbird, you could install the "Folder Account" extensions. With this extension you can define your sender address per folder. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From daniel at pocock.com.au Tue Sep 1 11:36:20 2009 From: daniel at pocock.com.au (Daniel Pocock) Date: Tue, 01 Sep 2009 10:36:20 +0100 Subject: [csw-maintainers] [board] maintainer registration? In-Reply-To: <4A9A8EB4.6080602@opencsw.org> References: <4A927A7D.70600@pocock.com.au> <4A92C8A9.1060307@pocock.com.au> <4A92EEF9.7070804@pocock.com.au> <7D46DB25-88E5-407C-A5B5-B28549D99D23@opencsw.org> <4A96ABAF.70109@pocock.com.au> <052AF7DA-8E8C-41E7-B013-93BB6352BE23@opencsw.org> <4A96EA68.8020000@pocock.com.au> <4A9A8EB4.6080602@opencsw.org> Message-ID: <4A9CEB14.2@pocock.com.au> Ihsan Dogan wrote: > Am 27.8.2009 22:19 Uhr, Daniel Pocock schrieb: > > >>>> Could you let me know whether this type of thing should be discussed >>>> on the board list, the maintainers list or the devel list? >>>> >>> Usually on maintainers@, but you have to post from your opencsw.org >>> account >>> on the list which you may or may not (Ihsan?) have yet. >>> >>> >> I haven't got an opencsw.org account as far as I know - I've tried to >> subscribe to that list using my main email address, daniel at pocock.com.au >> - I think it is waiting for someone to approve, because I haven't >> received the confirmation email yet >> > > I can't approve that request because according to our policy, only > e-mail addresses with an @opencsw.org address can be on the list. > > Could you kindly clarify the reason for this policy? Wouldn't it be sufficient to just tell the list software to only accept email from subscribers? Adding an extra email address in my various email clients, and remembering to change the sender address on each email I send, may only make participating in opencsw more tedious than it should be. From mats.larsson at ericsson.com Tue Sep 1 13:41:00 2009 From: mats.larsson at ericsson.com (Mats Larsson) Date: Tue, 01 Sep 2009 13:41:00 +0200 Subject: [csw-maintainers] [csw-users] Firefox 3 release In-Reply-To: <4A9C47D6.4010501@wbonnet.net> References: <4A9C47D6.4010501@wbonnet.net> Message-ID: <4A9D084C.1040005@ericsson.com> Hi Will, Good work indeed. Any chance for a Fx 3.5.x soon? BR MOL On 2009-08-31 23:59, William Bonnet wrote: > Hi, > > I'm pleased to announced that Firefox 3.0.13 has been pushed to > current. This version supports Solaris 8 and newer (thanks goes to > James Lee for pointing me the solution). > > Thunderbird has also been updated to version 2.0.0.23, latest stable > before TB3 is released. > > cheers > W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihsan at opencsw.org Wed Sep 2 20:02:47 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 02 Sep 2009 20:02:47 +0200 Subject: [csw-maintainers] Summary for OpenCSW summer camp? In-Reply-To: References: Message-ID: <4A9EB347.4020602@opencsw.org> Am 26.8.2009 15:58 Uhr, Peter FELECAN schrieb: > Now, that we had photos about this event, is it possible to have a > summary of what happened, discussed, &c for those that hadn't the > opportunity to be there? This is my task. I'm already working on it to put it on the wiki. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Wed Sep 2 20:10:02 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 02 Sep 2009 20:10:02 +0200 Subject: [csw-maintainers] FYI: Hosting provider for Solaris In-Reply-To: References: <141B8FA6-FB56-41B4-8FDF-5E5A0A58DE77@familie-michelsen.de> Message-ID: <4A9EB4FA.1060302@opencsw.org> Am 26.8.2009 22:36 Uhr, Dagobert Michelsen schrieb: > the domain hoster I use for opencsw.org is now offering OpenSolaris vServer > starting at 40 Euro per month with 2 TB traffic included. I haven't heard > of another hoster offering Solaris, so you may find this interesting. We (Uplink AG, the company where I work) provide Solaris hosting as well, but at the moment only Solaris and not OpenSolaris. --> http://www.netofficeservices.net/ (currently only in German) Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From daniel at opencsw.org Wed Sep 2 20:32:42 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 02 Sep 2009 19:32:42 +0100 Subject: [csw-maintainers] FYI: Hosting provider for Solaris In-Reply-To: <4A9EB4FA.1060302@opencsw.org> References: <141B8FA6-FB56-41B4-8FDF-5E5A0A58DE77@familie-michelsen.de> <4A9EB4FA.1060302@opencsw.org> Message-ID: <4A9EBA4A.6030109@opencsw.org> Ihsan Dogan wrote: > Am 26.8.2009 22:36 Uhr, Dagobert Michelsen schrieb: > > >> the domain hoster I use for opencsw.org is now offering OpenSolaris vServer >> starting at 40 Euro per month with 2 TB traffic included. I haven't heard >> of another hoster offering Solaris, so you may find this interesting. >> > > We (Uplink AG, the company where I work) provide Solaris hosting as > well, but at the moment only Solaris and not OpenSolaris. > > --> http://www.netofficeservices.net/ > > (currently only in German) > > Many providers offer physical server hosting (using your hardware or their own) - you can then install Xen on top of the supplied Linux distro, and run any virtual machine you like, including Solaris or OpenSolaris My own personal setup has Solaris 10 x86 inside a Debian lenny box. I use iSCSI to export raw LVM volumes to Solaris, this provides a convenient and standardised way to manage the disk space across multiple VMs. From daniel at pocock.com.au Wed Sep 2 20:30:21 2009 From: daniel at pocock.com.au (Daniel Pocock) Date: Wed, 02 Sep 2009 19:30:21 +0100 Subject: [csw-maintainers] FYI: Hosting provider for Solaris In-Reply-To: <4A9EB4FA.1060302@opencsw.org> References: <141B8FA6-FB56-41B4-8FDF-5E5A0A58DE77@familie-michelsen.de> <4A9EB4FA.1060302@opencsw.org> Message-ID: <4A9EB9BD.5010809@pocock.com.au> Ihsan Dogan wrote: > Am 26.8.2009 22:36 Uhr, Dagobert Michelsen schrieb: > > >> the domain hoster I use for opencsw.org is now offering OpenSolaris vServer >> starting at 40 Euro per month with 2 TB traffic included. I haven't heard >> of another hoster offering Solaris, so you may find this interesting. >> > > We (Uplink AG, the company where I work) provide Solaris hosting as > well, but at the moment only Solaris and not OpenSolaris. > > --> http://www.netofficeservices.net/ > > Many providers offer physical server hosting (using your hardware or their own) - you can then install Xen on top of the supplied Linux distro, and run any virtual machine you like, including Solaris or OpenSolaris My own personal setup has Solaris 10 x86 inside a Debian lenny box. I use iSCSI to export raw LVM volumes to Solaris, this provides a convenient and standardised way to manage the disk space across multiple VMs. From dam at opencsw.org Wed Sep 2 21:16:14 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Sep 2009 21:16:14 +0200 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: Message-ID: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> Hi, Am 02.09.2009 um 19:00 schrieb Philip Brown: > On Tue, Sep 1, 2009 at 12:19 AM, Jeffery Small wrote: >> Can someone please provide an update on the status of the following >> two >> open issues: >> >> 1: Is there a revised release of sendmail pending for use with the >> Berkeley >> DB 4.x problem, and have all the Berkeley DB issues been >> resolved? I >> am in a state of confusion about all this and very afraid to >> touch anything >> for fear of getting things out of sync once again. I really >> don't know >> what version of the BDB I should be running. I currently have: >> >> berkeleydb4 4.2.52,REV=2005.04.28_rev=p4 >> berkeleydb44 4.4.20,REV=2009.07.28 >> sendmail 8.14.2,REV=2007.12.17 >> >> > > I previously suggested/requested that our berkeleydb maintainer(s), > repackage the "berkeleyedb4" package, to include the old binaries for > the shared libs, until they are no longer used. > This basically echos our "normal" policies about shared libs. This policy is there to avoid having multiple packages with one version each. Currently we already have multiple packages and correct dependencies to each package version. There is no need to put all in one package. Essentially, you say "go back to the old scheme and let's see that we update all builds to old versions". I fully agree to going back with correct versions inside, but not as one package and links from other packages. It is more difficult to package and maintain and additionally bloats the system with all versions when you only need one. Best regards -- Dago From ihsan at opencsw.org Wed Sep 2 22:05:48 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 02 Sep 2009 22:05:48 +0200 Subject: [csw-maintainers] FYI: Hosting provider for Solaris In-Reply-To: <4A9EBA4A.6030109@opencsw.org> References: <141B8FA6-FB56-41B4-8FDF-5E5A0A58DE77@familie-michelsen.de> <4A9EB4FA.1060302@opencsw.org> <4A9EBA4A.6030109@opencsw.org> Message-ID: <4A9ED01C.8010707@opencsw.org> Am 2.9.2009 20:32 Uhr, Daniel Pocock schrieb: >> We (Uplink AG, the company where I work) provide Solaris hosting as >> well, but at the moment only Solaris and not OpenSolaris. >> >> --> http://www.netofficeservices.net/ >> >> (currently only in German) >> >> > Many providers offer physical server hosting (using your hardware or > their own) - you can then install Xen on top of the supplied Linux > distro, and run any virtual machine you like, including Solaris or > OpenSolaris > > My own personal setup has Solaris 10 x86 inside a Debian lenny box. I > use iSCSI to export raw LVM volumes to Solaris, this provides a > convenient and standardised way to manage the disk space across multiple > VMs. We address actually more the professional market. Xen and iSCSI are, well, not really for production. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From phil at bolthole.com Wed Sep 2 23:16:23 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 2 Sep 2009 14:16:23 -0700 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> References: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> Message-ID: On Wed, Sep 2, 2009 at 12:16 PM, Dagobert Michelsen wrote: > Am 02.09.2009 um 19:00 schrieb Philip Brown: >> I previously suggested/requested that our berkeleydb maintainer(s), >> repackage the "berkeleyedb4" package, to include the old binaries for >> the shared libs, until they are no longer used. >> This basically echos our "normal" policies about shared libs. > > This[standard?] policy is there to avoid having multiple packages with > one version each. Currently we already have multiple packages > and correct dependencies to each package version. There is no > need to put all in one package. Essentially, you say "go back > to the old scheme and let's see that we update all builds > to old versions". That "old scheme" is a bit ambigous. Lets be a bit more explicit, and say "go back to CSW STANDARD scheme". And lets continue to be explicit and spell out the future path for berkeleydb: Once applications have been recompiled to no longer use berkeleydb4X versions of the shared libs, that versioned virtual package should be completely removed from our repository. older berkeleydb4X packages should be in transition to non-existance, once their dependants are gone. agree? From skayser at opencsw.org Thu Sep 3 00:22:09 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 03 Sep 2009 00:22:09 +0200 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> Message-ID: <4A9EF011.8050500@opencsw.org> Philip Brown wrote on 02.09.2009 23:16: > On Wed, Sep 2, 2009 at 12:16 PM, Dagobert Michelsen wrote: >> Am 02.09.2009 um 19:00 schrieb Philip Brown: >>> I previously suggested/requested that our berkeleydb maintainer(s), >>> repackage the "berkeleyedb4" package, to include the old binaries for >>> the shared libs, until they are no longer used. >>> This basically echos our "normal" policies about shared libs. >> This[standard?] policy is there to avoid having multiple packages with >> one version each. Currently we already have multiple packages >> and correct dependencies to each package version. There is no >> need to put all in one package. Essentially, you say "go back >> to the old scheme and let's see that we update all builds >> to old versions". > > That "old scheme" is a bit ambigous. Lets be a bit more explicit, and > say "go back to CSW STANDARD scheme". > > And lets continue to be explicit and spell out the future path for berkeleydb: > > Once applications have been recompiled to no longer use berkeleydb4X > versions of the shared libs, that versioned virtual package should be > completely removed from our repository. > > older berkeleydb4X packages should be in transition to non-existance, > once their dependants are gone. I didn't jump in on the discussion where Dago initially requested feedback for the bdb packaging change [1], but as the bdb stuff caused some hickups some wider discussion might help. Just to understand the status quo: - We do have a CSWbdb package which currently holds 4.7.x, lives in /opt/csw/lib (/opt/csw/lib/libdb.so to be precise), and which might get upgraded to 4.7+ sometime in the future? - Previous CSWbdb packages (like CSWbdb44) lived within their own /opt/csw/lib/bdb4X/ prefix and have been replaced by stub packages containting symlinks to /opt/csw/lib/libdb.so to preserve functionality of existing packages? - Packages linked against previous CSWbdb packages should be changed to link against /opt/csw/lib/libdb.so (or to a symlink named libdb-4.7.so which is also installed by CSWbdb)? Now that we have a "moving version" libdb.so file (plus already existing packages linked against previous versions), the one question that comes to my mind is ABI compatibility? Dago mentioned BDB should be ABI backward-compatible, but i couldn't find any page actually saying so. The only thing i found sounds a bit like the opposite [2]: "Berkeley DB major and minor releases may optionally include changes in all four areas, that is, the application API, region files, database formats, and log files may not be backward-compatible with previous releases." I know API != ABI, but API changes can break ABI compatibility and i couldn't come up with a reference that guarantees ABI compatibility. Sebastian [1]http://lists.opencsw.org/pipermail/maintainers/2009-May/002726.html [2]http://www.oracle.com/technology/documentation/berkeley-db/db/ref/upgrade/process.html From daniel at opencsw.org Thu Sep 3 00:43:57 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 02 Sep 2009 23:43:57 +0100 Subject: [csw-maintainers] FYI: Hosting provider for Solaris In-Reply-To: <4A9ED01C.8010707@opencsw.org> References: <141B8FA6-FB56-41B4-8FDF-5E5A0A58DE77@familie-michelsen.de> <4A9EB4FA.1060302@opencsw.org> <4A9EBA4A.6030109@opencsw.org> <4A9ED01C.8010707@opencsw.org> Message-ID: <4A9EF52D.70900@opencsw.org> Ihsan Dogan wrote: > Am 2.9.2009 20:32 Uhr, Daniel Pocock schrieb: > > >>> We (Uplink AG, the company where I work) provide Solaris hosting as >>> well, but at the moment only Solaris and not OpenSolaris. >>> >>> --> http://www.netofficeservices.net/ >>> >>> (currently only in German) >>> >>> >>> >> Many providers offer physical server hosting (using your hardware or >> their own) - you can then install Xen on top of the supplied Linux >> distro, and run any virtual machine you like, including Solaris or >> OpenSolaris >> >> My own personal setup has Solaris 10 x86 inside a Debian lenny box. I >> use iSCSI to export raw LVM volumes to Solaris, this provides a >> convenient and standardised way to manage the disk space across multiple >> VMs. >> > > We address actually more the professional market. Xen and iSCSI are, > well, not really for production. > > I'm certainly not advocating any solution as better than any other. Xen and iSCSI are certainly sufficient for me to do Ganglia and OpenCSW development/packaging, but that is obviously not the same as production ecommerce systems. The production environment I work in is completely different, both in scale and choice of technology. From dam at opencsw.org Thu Sep 3 09:32:54 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Sep 2009 09:32:54 +0200 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> Message-ID: <1F0E2987-F72A-46A9-B84B-82A4B3AF2DBB@opencsw.org> Hi Phil, Am 02.09.2009 um 23:16 schrieb Philip Brown: > On Wed, Sep 2, 2009 at 12:16 PM, Dagobert Michelsen > wrote: >> Am 02.09.2009 um 19:00 schrieb Philip Brown: >>> I previously suggested/requested that our berkeleydb maintainer(s), >>> repackage the "berkeleyedb4" package, to include the old binaries >>> for >>> the shared libs, until they are no longer used. >>> This basically echos our "normal" policies about shared libs. >> >> This[standard?] policy is there to avoid having multiple packages >> with >> one version each. Currently we already have multiple packages >> and correct dependencies to each package version. There is no >> need to put all in one package. Essentially, you say "go back >> to the old scheme and let's see that we update all builds >> to old versions". > > That "old scheme" is a bit ambigous. Lets be a bit more explicit, and > say "go back to CSW STANDARD scheme". > > And lets continue to be explicit and spell out the future path for > berkeleydb: > > Once applications have been recompiled to no longer use berkeleydb4X > versions of the shared libs, that versioned virtual package should be > completely removed from our repository. > > older berkeleydb4X packages should be in transition to non-existance, > once their dependants are gone. Yes. I propose to put the old shared libs back in to bdb4x until the dependencies are gone and then remove them. There is really no point in moving the shared libs in bdb4 and make bdb4x stubs. The CSW standard doesn't apply here as we already have multiple version packages. Apart from that I am not keen into putting a whole day of work reorganizing the libs where we already have build descriptions for all bdb4x packages. Not because of the work, but because there no gain in clearance and bloat in size. Mike, your opinion? Best regards -- Dago From daniel at opencsw.org Thu Sep 3 12:08:41 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 03 Sep 2009 11:08:41 +0100 Subject: [csw-maintainers] linking against rrdtool fails Message-ID: <4A9F95A9.9060700@opencsw.org> This is a relatively fresh install of OpenCSW, so I'm guessing that the CSWrrd package hasn't dragged in all it's dependencies: configure:19101: checking for rrd_create in -lrrd configure:19131: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 -xarch=386 - I/opt/csw/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib conftest.c -lrrd -lm -lpthread >&5 Undefined first referenced symbol in file cairo_svg_surface_restrict_to_version /opt/csw/lib/librrd.so cairo_svg_surface_create /opt/csw/lib/librrd.so cairo_svg_surface_create_for_stream /opt/csw/lib/librrd.so ld: fatal: Symbol referencing errors. No output written to conftest From dam at opencsw.org Thu Sep 3 12:13:48 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Sep 2009 12:13:48 +0200 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <4A9F95A9.9060700@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> Message-ID: Hi Daniel, Am 03.09.2009 um 12:08 schrieb Daniel Pocock: > This is a relatively fresh install of OpenCSW, so I'm guessing that > the CSWrrd package hasn't dragged in all it's dependencies: > > configure:19101: checking for rrd_create in -lrrd > configure:19131: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 - > xarch=386 - > I/opt/csw/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib > conftest.c -lrrd > -lm -lpthread >&5 > Undefined first referenced > symbol in file > cairo_svg_surface_restrict_to_version /opt/csw/lib/librrd.so > cairo_svg_surface_create /opt/csw/lib/librrd.so > cairo_svg_surface_create_for_stream /opt/csw/lib/librrd.so > ld: fatal: Symbol referencing errors. No output written to conftest There were issues with circular dependencies which have been fixed recently with SVG support. Please try if libcairo from testing solves you problem. This would also help John who did the repackage to release it. Best regards -- Dago From daniel at opencsw.org Thu Sep 3 12:36:18 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 03 Sep 2009 11:36:18 +0100 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: References: <4A9F95A9.9060700@opencsw.org> Message-ID: <4A9F9C22.1080101@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 03.09.2009 um 12:08 schrieb Daniel Pocock: >> This is a relatively fresh install of OpenCSW, so I'm guessing that >> the CSWrrd package hasn't dragged in all it's dependencies: >> >> configure:19101: checking for rrd_create in -lrrd >> configure:19131: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 >> -xarch=386 - >> I/opt/csw/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib >> conftest.c -lrrd >> -lm -lpthread >&5 >> Undefined first referenced >> symbol in file >> cairo_svg_surface_restrict_to_version /opt/csw/lib/librrd.so >> cairo_svg_surface_create /opt/csw/lib/librrd.so >> cairo_svg_surface_create_for_stream /opt/csw/lib/librrd.so >> ld: fatal: Symbol referencing errors. No output written to conftest > > There were issues with circular dependencies which have been fixed > recently with SVG support. Please try if libcairo from testing > solves you problem. This would also help John who did the > repackage to release it. > How do I get it from testing? When I look at the mirrors, I just see stable, current and unstable From dam at opencsw.org Thu Sep 3 12:38:58 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Sep 2009 12:38:58 +0200 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <4A9F9C22.1080101@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> Message-ID: <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> Hi Daniel, Am 03.09.2009 um 12:36 schrieb Daniel Pocock: > Dagobert Michelsen wrote: >> Hi Daniel, >> >> Am 03.09.2009 um 12:08 schrieb Daniel Pocock: >>> This is a relatively fresh install of OpenCSW, so I'm guessing >>> that the CSWrrd package hasn't dragged in all it's dependencies: >>> >>> configure:19101: checking for rrd_create in -lrrd >>> configure:19131: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest - >>> xO3 -xarch=386 - >>> I/opt/csw/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib >>> conftest.c -lrrd >>> -lm -lpthread >&5 >>> Undefined first referenced >>> symbol in file >>> cairo_svg_surface_restrict_to_version /opt/csw/lib/librrd.so >>> cairo_svg_surface_create /opt/csw/lib/librrd.so >>> cairo_svg_surface_create_for_stream /opt/csw/lib/librrd.so >>> ld: fatal: Symbol referencing errors. No output written to conftest >> >> There were issues with circular dependencies which have been fixed >> recently with SVG support. Please try if libcairo from testing >> solves you problem. This would also help John who did the >> repackage to release it. >> > How do I get it from testing? When I look at the mirrors, I just > see stable, current and unstable Ah, ok, from here: Commandlines for pkg-get and pkgutil are also described there. It is btw also available from the farm as /home/testing/ Best regards -- Dago From daniel at opencsw.org Thu Sep 3 12:46:07 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 03 Sep 2009 11:46:07 +0100 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> Message-ID: <4A9F9E6F.2030002@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 03.09.2009 um 12:36 schrieb Daniel Pocock: > >> Dagobert Michelsen wrote: >>> Hi Daniel, >>> >>> Am 03.09.2009 um 12:08 schrieb Daniel Pocock: >>>> This is a relatively fresh install of OpenCSW, so I'm guessing that >>>> the CSWrrd package hasn't dragged in all it's dependencies: >>>> >>>> configure:19101: checking for rrd_create in -lrrd >>>> configure:19131: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 >>>> -xarch=386 - >>>> I/opt/csw/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib >>>> conftest.c -lrrd >>>> -lm -lpthread >&5 >>>> Undefined first referenced >>>> symbol in file >>>> cairo_svg_surface_restrict_to_version /opt/csw/lib/librrd.so >>>> cairo_svg_surface_create /opt/csw/lib/librrd.so >>>> cairo_svg_surface_create_for_stream /opt/csw/lib/librrd.so >>>> ld: fatal: Symbol referencing errors. No output written to conftest >>> >>> There were issues with circular dependencies which have been fixed >>> recently with SVG support. Please try if libcairo from testing >>> solves you problem. This would also help John who did the >>> repackage to release it. >>> >> How do I get it from testing? When I look at the mirrors, I just see >> stable, current and unstable > > Ah, ok, from here: > > Commandlines for pkg-get and pkgutil are also described there. > It is btw also available from the farm as /home/testing/ > Thanks, I had been looking at http://www.opencsw.org/mirrors which mentions testing but doesn't link to that other page. From daniel at opencsw.org Thu Sep 3 12:56:31 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 03 Sep 2009 11:56:31 +0100 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <4A9F9E6F.2030002@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> <4A9F9E6F.2030002@opencsw.org> Message-ID: <4A9FA0DF.4040903@opencsw.org> Daniel Pocock wrote: > Dagobert Michelsen wrote: >> Hi Daniel, >> >> Am 03.09.2009 um 12:36 schrieb Daniel Pocock: >> >>> Dagobert Michelsen wrote: >>>> Hi Daniel, >>>> >>>> Am 03.09.2009 um 12:08 schrieb Daniel Pocock: >>>>> This is a relatively fresh install of OpenCSW, so I'm guessing >>>>> that the CSWrrd package hasn't dragged in all it's dependencies: >>>>> >>>>> configure:19101: checking for rrd_create in -lrrd >>>>> configure:19131: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest >>>>> -xO3 -xarch=386 - >>>>> I/opt/csw/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib >>>>> conftest.c -lrrd >>>>> -lm -lpthread >&5 >>>>> Undefined first referenced >>>>> symbol in file >>>>> cairo_svg_surface_restrict_to_version /opt/csw/lib/librrd.so >>>>> cairo_svg_surface_create /opt/csw/lib/librrd.so >>>>> cairo_svg_surface_create_for_stream /opt/csw/lib/librrd.so >>>>> ld: fatal: Symbol referencing errors. No output written to conftest >>>> >>>> There were issues with circular dependencies which have been fixed >>>> recently with SVG support. Please try if libcairo from testing >>>> solves you problem. This would also help John who did the >>>> repackage to release it. >>>> >>> How do I get it from testing? When I look at the mirrors, I just >>> see stable, current and unstable >> >> Ah, ok, from here: >> >> Commandlines for pkg-get and pkgutil are also described there. >> It is btw also available from the farm as /home/testing/ >> > > Thanks, I had been looking at http://www.opencsw.org/mirrors which > mentions testing but doesn't link to that other page. I did pkgutil -t ... -i CSWrrd and now things like ggrep are broken. It says libiconv is not found, but I can see it in the right place. Do other issues exist in testing? Do I need to update all my packages from testing now? -bash-3.00# ldd /opt/csw/bin/ggrep libintl.so.8 => /opt/csw/lib/pentium_pro/libintl.so.8 libpcre.so.0 => /opt/csw/lib/i386/libpcre.so.0 libc.so.1 => /lib/libc.so.1 libiconv.so.2 => (file not found) libncurses.so.5 => /opt/csw/lib/pentium_pro/libncurses.so.5 libm.so.2 => /lib/libm.so.2 -bash-3.00# ls -l | grep iconv lrwxrwxrwx 1 root root 17 Sep 3 11:46 libiconv.so -> libiconv.so.2.5.0 lrwxrwxrwx 1 root root 17 Sep 3 11:46 libiconv.so.2 -> libiconv.so.2.5.0 -rwxr-xr-x 1 root bin 961948 Jul 31 10:18 libiconv.so.2.5.0 -rw-r--r-- 1 root bin 960320 Jul 31 10:18 preloadable_libiconv.so From dam at opencsw.org Thu Sep 3 13:54:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Sep 2009 13:54:43 +0200 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <4A9FA0DF.4040903@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> <4A9F9E6F.2030002@opencsw.org> <4A9FA0DF.4040903@opencsw.org> Message-ID: <0E96A327-0F1D-48F9-80DA-6D33707496DF@opencsw.org> Hi Daniel, Am 03.09.2009 um 12:56 schrieb Daniel Pocock: > Daniel Pocock wrote: >> Dagobert Michelsen wrote: >>> Hi Daniel, >>> >>> Am 03.09.2009 um 12:36 schrieb Daniel Pocock: >>> >>>> Dagobert Michelsen wrote: >>>>> There were issues with circular dependencies which have been fixed >>>>> recently with SVG support. Please try if libcairo from testing >>>>> solves you problem. This would also help John who did the >>>>> repackage to release it. >> >>>> >>>> How do I get it from testing? When I look at the mirrors, I just >>>> see stable, current and unstable >>> >>> Ah, ok, from here: >>> >>> Commandlines for pkg-get and pkgutil are also described there. >>> It is btw also available from the farm as /home/testing/ >> >> Thanks, I had been looking at http://www.opencsw.org/mirrors which >> mentions testing but doesn't link to that other page. > > I did > pkgutil -t ... -i CSWrrd Please update _only_ cairo, not rrd or anything else as stuff in testing may or may not be broken and you want to test cairo only. > and now things like ggrep are broken. It says libiconv is not > found, but I can see it in the right place. > > Do other issues exist in testing? Do I need to update all my > packages from testing now? Definitely not. Please revert all versions from CSW packages to current except cairo or you will get massive problems. testing/ is not meant to be fully installed as there are no checks done between packages from testing/. Best regards -- Dago From daniel at opencsw.org Thu Sep 3 17:01:57 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 03 Sep 2009 16:01:57 +0100 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <0E96A327-0F1D-48F9-80DA-6D33707496DF@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> <4A9F9E6F.2030002@opencsw.org> <4A9FA0DF.4040903@opencsw.org> <0E96A327-0F1D-48F9-80DA-6D33707496DF@opencsw.org> Message-ID: <4A9FDA65.5000003@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 03.09.2009 um 12:56 schrieb Daniel Pocock: >> Daniel Pocock wrote: >>> Dagobert Michelsen wrote: >>>> Hi Daniel, >>>> >>>> Am 03.09.2009 um 12:36 schrieb Daniel Pocock: >>>> >>>>> Dagobert Michelsen wrote: >>>>>> There were issues with circular dependencies which have been fixed >>>>>> recently with SVG support. Please try if libcairo from testing >>>>>> solves you problem. This would also help John who did the >>>>>> repackage to release it. >>> >>>>> >>>>> How do I get it from testing? When I look at the mirrors, I just >>>>> see stable, current and unstable >>>> >>>> Ah, ok, from here: >>>> >>>> Commandlines for pkg-get and pkgutil are also described there. >>>> It is btw also available from the farm as /home/testing/ >>> >>> Thanks, I had been looking at http://www.opencsw.org/mirrors which >>> mentions testing but doesn't link to that other page. >> >> I did >> pkgutil -t ... -i CSWrrd > > Please update _only_ cairo, not rrd or anything else as stuff in > testing may or may not > be broken and you want to test cairo only. > >> and now things like ggrep are broken. It says libiconv is not found, >> but I can see it in the right place. >> >> Do other issues exist in testing? Do I need to update all my >> packages from testing now? > > Definitely not. Please revert all versions from CSW packages to > current except > cairo or you will get massive problems. testing/ is not meant to be > fully installed > as there are no checks done between packages from testing/. > When I try to get cairo with pkgutil, it wants to grab other packages too, including iconv: -bash-3.00# pkgutil -t http://mirror.opencsw.org/opencsw/testing -i CSWlibcairo Fetching new catalog http://mirror.opencsw.org/opencsw/testing/i386/5.10 if available... --2009-09-03 15:59:32-- http://mirror.opencsw.org/opencsw/testing/i386/5.10/catalog Resolving mirror.opencsw.org... 213.178.77.176 Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 31807 (31K) [text/plain] Saving to: `/var/opt/csw/pkgutil/catalog.mirror.opencsw.org_opencsw_testing_i386_5.10' 100%[======================================>] 31,807 85.4K/s in 0.4s 2009-09-03 15:59:37 (85.4 KB/s) - `/var/opt/csw/pkgutil/catalog.mirror.opencsw.org_opencsw_testing_i386_5.10' saved [31807/31807] Fetching new catalog http://ftp.heanet.ie/pub/opencsw/current/i386/5.10 if available... --2009-09-03 15:59:37-- http://ftp.heanet.ie/pub/opencsw/current/i386/5.10/catalog Resolving ftp.heanet.ie... 193.1.193.64, 2001:770:18:aa40::c101:c140 Connecting to ftp.heanet.ie|193.1.193.64|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 398585 (389K) [text/plain] Saving to: `/var/opt/csw/pkgutil/catalog.ftp.heanet.ie_pub_opencsw_current_i386_5.10' 100%[======================================>] 398,585 72.1K/s in 5.2s 2009-09-03 15:59:42 (74.5 KB/s) - `/var/opt/csw/pkgutil/catalog.ftp.heanet.ie_pub_opencsw_current_i386_5.10' saved [398585/398585] Parsing catalog, may take a while... Updated packages: CSWzlib-1.2.3,REV=2009.04.05 CSWiconv-1.13.1,REV=2009.07.31 CSWftype2-2.3.9,REV=2009.04.16 CSWlibcairo-1.8.8,REV=2009.08.04 Current packages: CSWcommon-1.4.6,REV=2008.04.28 CSWx11common-1.0,REV=2009.05.24 CSWlibxau-1.0.4,REV=2009.06.04 CSWlibxcb-1.3,REV=2009.06.07 CSWlibx11-1.2.2,REV=2009.07.12 CSWexpat-2.0.1,REV=2009.01.22 CSWisaexec-0.2,REV=2009.03.26 CSWxcbutil-0.3.5,REV=2009.06.12 CSWpng-1.2.39,REV=2009.08.13 CSWpixman-0.15.8,REV=2009.06.02 CSWlibxrender-0.9.4,REV=2009.06.11 CSWfconfig-2.6.0,REV=2009.04.24 Total size: 3.9 MB 4 packages to fetch. Do you want to continue? [Y,n] From bonivart at opencsw.org Thu Sep 3 17:46:42 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 3 Sep 2009 17:46:42 +0200 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <4A9FDA65.5000003@opencsw.org> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> <4A9F9E6F.2030002@opencsw.org> <4A9FA0DF.4040903@opencsw.org> <0E96A327-0F1D-48F9-80DA-6D33707496DF@opencsw.org> <4A9FDA65.5000003@opencsw.org> Message-ID: <625385e30909030846u3978ebd5q56153fcfa1d638a7@mail.gmail.com> On Thu, Sep 3, 2009 at 5:01 PM, Daniel Pocock wrote: > When I try to get cairo with pkgutil, it wants to grab other packages too, > including iconv: > > -bash-3.00# pkgutil -t http://mirror.opencsw.org/opencsw/testing -i > CSWlibcairo > > Parsing catalog, may take a while... > Updated packages: CSWzlib-1.2.3,REV=2009.04.05 > CSWiconv-1.13.1,REV=2009.07.31 CSWftype2-2.3.9,REV=2009.04.16 > CSWlibcairo-1.8.8,REV=2009.08.04 Use the -x option to exclude packages: # pkgutil -t http://mirror.opencsw.org/opencsw/testing -i CSWlibcairo -x CSWzlib -x CSWiconv -x CSWftype2 -- /peter From phil at bolthole.com Thu Sep 3 18:25:53 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 3 Sep 2009 09:25:53 -0700 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: <625385e30909030846u3978ebd5q56153fcfa1d638a7@mail.gmail.com> References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> <4A9F9E6F.2030002@opencsw.org> <4A9FA0DF.4040903@opencsw.org> <0E96A327-0F1D-48F9-80DA-6D33707496DF@opencsw.org> <4A9FDA65.5000003@opencsw.org> <625385e30909030846u3978ebd5q56153fcfa1d638a7@mail.gmail.com> Message-ID: On Thu, Sep 3, 2009 at 8:46 AM, Peter Bonivart wrote: > >Use the -x option to exclude packages: > # pkgutil -t http://mirror.opencsw.org/opencsw/testing -i CSWlibcairo > -x CSWzlib -x CSWiconv -x CSWftype2 > or perhaps just download it, and pkgadd it. For example pkg-get -s http://mirror.opencsw.org/opencsw/testing -d libcairo and then gunzip and pkgadd the result. if you dont want to just go to the webpage and click on it with your mouse to download :) From phil at bolthole.com Thu Sep 3 18:33:15 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 3 Sep 2009 09:33:15 -0700 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: <1F0E2987-F72A-46A9-B84B-82A4B3AF2DBB@opencsw.org> References: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> <1F0E2987-F72A-46A9-B84B-82A4B3AF2DBB@opencsw.org> Message-ID: On Thu, Sep 3, 2009 at 12:32 AM, Dagobert Michelsen wrote: > > I propose to put the old shared libs back in to bdb4x until the > dependencies are gone and then remove them. There is really no point > in moving the shared libs in bdb4 and make bdb4x stubs. The CSW standard > doesn't apply here as we already have multiple version packages. Well, there is ONE reason to do it "the standard way": new packages, tend to follow the pattern of older packages. If we dont do it "the right way" now, then 6-12 months down the road when it's time for someone (who may not be you or mike) to do an update, they might just follow along in the same scheme. that would be bad. From phil at bolthole.com Thu Sep 3 18:36:34 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 3 Sep 2009 09:36:34 -0700 Subject: [csw-maintainers] berkeleydb saga Message-ID: On Wed, Sep 2, 2009 at 3:22 PM, Sebastian Kayser wrote: > ..... > Now that we have a "moving version" libdb.so file (plus already existing > packages linked against previous versions), the one question that comes > to my mind is ABI compatibility? > I know API != ABI, but API changes can break ABI compatibility and i > couldn't come up with a reference that guarantees ABI compatibility. > The symlink isnt important. What is important, is the "SONAME" of the library. if it is compiled with SONAME=libdb-4.7, then even if you compile with cc .... -ldb at runtime, it will be dynamically linked aginst "libdb-4.7". So no worries there. the symlink is just a shortcut for "at COMPILE time, use latest version". When ABI compatibility changes, we bump the SONAME. From dam at opencsw.org Thu Sep 3 18:49:57 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Sep 2009 18:49:57 +0200 Subject: [csw-maintainers] sendmail and dbus packages In-Reply-To: References: <77150382-B38E-4CA1-B960-60FB263D6001@opencsw.org> <1F0E2987-F72A-46A9-B84B-82A4B3AF2DBB@opencsw.org> Message-ID: Hi Phil, Am 03.09.2009 um 18:33 schrieb Philip Brown: > On Thu, Sep 3, 2009 at 12:32 AM, Dagobert Michelsen > wrote: >>> I propose to put the old shared libs back in to bdb4x until the >> dependencies are gone and then remove them. There is really no point >> in moving the shared libs in bdb4 and make bdb4x stubs. The CSW >> standard >> doesn't apply here as we already have multiple version packages. > > Well, there is ONE reason to do it "the standard way": > new packages, tend to follow the pattern of older packages. > If we dont do it "the right way" now, then 6-12 months down the road > when it's time for someone (who may not be you or mike) to do an > update, they might just follow along in the same scheme. > that would be bad. The bdb4x packages will most certainly never get an update. The only package to be updated would be bdb4, which already contains 4.7.x, so no worries there. Best regards -- Dago From daniel at opencsw.org Thu Sep 3 18:54:04 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 03 Sep 2009 17:54:04 +0100 Subject: [csw-maintainers] linking against rrdtool fails In-Reply-To: References: <4A9F95A9.9060700@opencsw.org> <4A9F9C22.1080101@opencsw.org> <10072ABB-266B-4337-B174-9B5A03358064@opencsw.org> <4A9F9E6F.2030002@opencsw.org> <4A9FA0DF.4040903@opencsw.org> <0E96A327-0F1D-48F9-80DA-6D33707496DF@opencsw.org> <4A9FDA65.5000003@opencsw.org> <625385e30909030846u3978ebd5q56153fcfa1d638a7@mail.gmail.com> Message-ID: <4A9FF4AC.4070402@opencsw.org> Philip Brown wrote: > On Thu, Sep 3, 2009 at 8:46 AM, Peter Bonivart wrote: > >> Use the -x option to exclude packages: >> # pkgutil -t http://mirror.opencsw.org/opencsw/testing -i CSWlibcairo >> -x CSWzlib -x CSWiconv -x CSWftype2 >> >> > > > or perhaps just download it, and pkgadd it. For example > > pkg-get -s http://mirror.opencsw.org/opencsw/testing -d libcairo > and then gunzip and pkgadd the result. > if you dont want to just go to the webpage and click on it with your > mouse to download :) > Yes, after looking at the pkgutil output, I decided to just download the package and use pkgadd, it didn't complain. The main reason I posted those other comments in that the testing page suggests using pkgutil, but that obviously led to a broken system for me. When I finally got the new libcairo, Ganglia gmetad server built quite happily. I'm now fine-tuning the Makefile for the full Ganglia suite, it will probably be available tomorrow. From phil at bolthole.com Thu Sep 3 19:13:18 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 3 Sep 2009 10:13:18 -0700 Subject: [csw-maintainers] berkeleydb saga Message-ID: On Thu, Sep 3, 2009 at 9:49 AM, Dagobert Michelsen wrote: > Hi Phil, > > Am 03.09.2009 um 18:33 schrieb Philip Brown: >> >> Well, there is ONE reason to do it "the standard way": >> new packages, tend to follow the pattern of older packages. >... > > The bdb4x packages will most certainly never get an update. The > only package to be updated would be bdb4, which already contains > 4.7.x, so no worries there. > my point being, that someone updating bdb4, in the distant future, may see the old, versioned packages, and think, "oh ok, I'd better follow the existing 'standard' for berkeleydb, and make a separate, new, berkeleydb4.8 package" From dam at opencsw.org Thu Sep 3 19:18:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Sep 2009 19:18:31 +0200 Subject: [csw-maintainers] berkeleydb saga In-Reply-To: References: Message-ID: <1E772177-3CCB-4855-9620-3517F5DCE57D@opencsw.org> Hi Phil, Am 03.09.2009 um 19:13 schrieb Philip Brown: > On Thu, Sep 3, 2009 at 9:49 AM, Dagobert Michelsen > wrote: >> Hi Phil, >> >> Am 03.09.2009 um 18:33 schrieb Philip Brown: >>> >>> Well, there is ONE reason to do it "the standard way": >>> new packages, tend to follow the pattern of older packages. >> ... >> >> The bdb4x packages will most certainly never get an update. The >> only package to be updated would be bdb4, which already contains >> 4.7.x, so no worries there. >> > > my point being, that someone updating bdb4, in the distant future, may > see the old, versioned packages, and think, "oh ok, I'd better follow > the existing 'standard' for berkeleydb, and make a separate, new, > berkeleydb4.8 package" Let me put it that way: At least *I* will never forget this, and I'm sure Mike and you won't either. And if in the distant future somebody takes over bdb and all of us are no longer project members I don't care. It is just too much work to build a unified bdb4 only for "the sake of consistency" and taking the negative side effects that every package depending on bdb would pull in all versions as they would be contained in bdb4, right? It would not make things clearer. Best regards -- Dago From william at wbonnet.net Thu Sep 3 23:01:27 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 03 Sep 2009 23:01:27 +0200 Subject: [csw-maintainers] Important ! DBus update and bug fix Message-ID: <4AA02EA7.9010406@wbonnet.net> Hi, A new version of the dbus packages will be pushed to current catalog in the next hours. This version fixes the fllowing bug 0003626: dbus daemon will not stop on reboot/init 6 blocking the shutdown ( http://opencsw.org/bugtrack/view.php?id=3626 ). This bugs prevents dbus from stop correctly. If dbus is running, it will be stop during update, thus update may freeze. In order to avoid this situation, you have to be sure that you don't have dbus running, or if it is running, you will have to kill it by hand before the upgrade. You can retrieve the pid to kill with the following command : bash-3.00# cat /opt/csw/var/run/dbus/pid 1592 or bash-3.00# ps -elf | grep dbus-daemon 0 S messageb 1592 1 0 40 20 ? 634 ? 22:55:25 ? 0:00 /opt/csw/bin/dbus-daemon --system Please "kill -9" the dbus process before running package upgrade. Kind regards W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From dam at opencsw.org Fri Sep 4 10:09:37 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Sep 2009 10:09:37 +0200 Subject: [csw-maintainers] Handling of bug reports Message-ID: Hi Rupert, (cc'ing maintainers@ to enhance consistent handling of bugreports) first thanks a lot for updating the Trac package. However, I received some status changes for bugs which were handled a bit uncustomary :-) It looks like you added your fix to the "Additional Information" field, which is quite confusing as it is meant to be used be the bug reporter. For the sake of consistency it would be nice if you could do the following steps: 1. Assign the bug to yourself 2. Change the status to Feedback/Acknowledged/Confirmed 3. Fix the bug and release a package to testing/ 4. If package is good set status to Resolved including the package version (e. g. "Fixed in 2.2.6,REV=2009.09.03_rev=a released to testing/") 5. Deliver the package to newpkgs/ 6. Set status to Closed when the package hit the mirrors As the updated package has already been released it would be great if you could review the bug reports and do (1) and (6) with the text of (4) in it. For general discussion: For the sake of simplicity I guess (4) could be ommitted. Step (2) is necessary to show someone is working on it, obivously you need (3) and a final close with (6) and the exact version for reference. Thanks and best regards -- Dago From maciej at opencsw.org Fri Sep 4 11:23:15 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 4 Sep 2009 10:23:15 +0100 Subject: [csw-maintainers] /opt/csw/bin/foo=bar=/opt/csw/bin/isaexec in the prototype Message-ID: I just got an error when installing wxwidgets: /opt/csw/lib/libwx_gtk2u_xrc-2.8.so.0 /opt/csw/lib/libwx_gtk2u_xrc-2.8.so.0.6.0 /opt/csw/lib/wx/config/gtk2-unicode-release-2.8 /opt/csw/lib/wx/include/gtk2-unicode-release-2.8/wx/setup.h [ verifying class ] /opt/csw/bin/wxrc ERROR: attribute verification of failed pathname does not exist unable to create link to /opt/csw/bin/wxrc-2.8 Installation of partially failed. ## Interrupted: package not installed in any non-global zones The relevant part of the install directory looks like this: work/install-isa-sparcv8/ `-- opt `-- csw |-- bin | |-- wx-config -> /opt/csw/lib/wx/config/gtk2-unicode-release-2.8 | |-- wxrc -> wxrc-2.8 | `-- wxrc-2.8 |-- include | `-- wx-2.8 | `-- wx | |-- aboutdlg.h ...and the prototype part is: s none /opt/csw/bin/sparcv8/wxrc=/opt/csw/bin/wxrc f none /opt/csw/bin/sparcv8/wxrc-2.8=/opt/csw/bin/wxrc-2.8 0755 root bin s none /opt/csw/bin/wx-config=/opt/csw/lib/wx/config/gtk2-unicode-release-2.8 l none /opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec l none /opt/csw/bin/wxrc-2.8=/opt/csw/bin/isaexec 0755 root bin It looks like there is a problem when there's a symlink which later becomes handled by isaexec. Initial "/opt/csw/bin/wxrc=wxrc-2.8" becomes "/opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec". Is this a valid prototype line? Maciej From james at opencsw.org Fri Sep 4 11:24:16 2009 From: james at opencsw.org (James Lee) Date: Fri, 04 Sep 2009 09:24:16 GMT Subject: [csw-maintainers] berkeleydb saga In-Reply-To: References: Message-ID: <20090904.9241600.918026838@gyor.oxdrove.co.uk> On 03/09/09, 17:36:34, Philip Brown wrote regarding Re: [csw-maintainers] berkeleydb saga: > The symlink isnt important. What is important, is the "SONAME" of the > library. > if it is compiled with SONAME=libdb-4.7, then even if you compile with > cc .... -ldb > at runtime, it will be dynamically linked aginst "libdb-4.7". Which is good, so when I install and use bdb4 generic version 4.X the libraries to which I link are 4.7. Therefore the package version for bdb4 should be 4.7 not 4.2. Currently the displayed package version is 4.2 which reflects the legacy libs also provided by this package as links to the 4.7 files. Being a bdb4 and not bdb42 it has rolling 4.x version unlike the bdb43 and bdbd44 which are fixed to 4.3 and 4.4 respectively. $ dump -Lv /opt/csw/bdb4/lib/libdb.so | grep SONAME [7] SONAME libdb-4.7.so $ pkgchk -l -p /opt/csw/bdb4/lib/libdb.so Pathname: /opt/csw/bdb4/lib/libdb.so Type: symbolic link Source of link: /opt/csw/lib/libdb.so Referenced by the following packages: CSWbdb4 Current status: installed $ pkgparam CSWbdb4 VERSION 4.2.52,REV=2009.07.28 James. From dam at opencsw.org Fri Sep 4 11:33:52 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Sep 2009 11:33:52 +0200 Subject: [csw-maintainers] /opt/csw/bin/foo=bar=/opt/csw/bin/isaexec in the prototype In-Reply-To: References: Message-ID: <8D0F5086-1849-476E-BED4-BC8BFC62AC46@opencsw.org> Hi Maciej, Am 04.09.2009 um 11:23 schrieb Maciej (Matchek) Blizinski: > I just got an error when installing wxwidgets: > > /opt/csw/lib/libwx_gtk2u_xrc-2.8.so.0 > /opt/csw/lib/libwx_gtk2u_xrc-2.8.so.0.6.0 > /opt/csw/lib/wx/config/gtk2-unicode-release-2.8 > /opt/csw/lib/wx/include/gtk2-unicode-release-2.8/wx/setup.h > [ verifying class ] > /opt/csw/bin/wxrc > ERROR: attribute verification of failed > pathname does not exist > unable to create link to > /opt/csw/bin/wxrc-2.8 > > Installation of partially failed. > ## Interrupted: package not installed in any non- > global zones > > > The relevant part of the install directory looks like this: > > work/install-isa-sparcv8/ > `-- opt > `-- csw > |-- bin > | |-- wx-config -> /opt/csw/lib/wx/config/gtk2-unicode- > release-2.8 > | |-- wxrc -> wxrc-2.8 > | `-- wxrc-2.8 > |-- include > | `-- wx-2.8 > | `-- wx > | |-- aboutdlg.h > You are using tree, nice! (whose package is orphaned and there is a new version, btw). > ...and the prototype part is: > > s none /opt/csw/bin/sparcv8/wxrc=/opt/csw/bin/wxrc > f none /opt/csw/bin/sparcv8/wxrc-2.8=/opt/csw/bin/wxrc-2.8 0755 root > bin > s none /opt/csw/bin/wx-config=/opt/csw/lib/wx/config/gtk2-unicode- > release-2.8 > l none /opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec > l none /opt/csw/bin/wxrc-2.8=/opt/csw/bin/isaexec 0755 root bin > > It looks like there is a problem when there's a symlink which later > becomes handled by isaexec. Initial "/opt/csw/bin/wxrc=wxrc-2.8" > becomes "/opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec". Is this a > valid prototype line? Umh, no, this looks broken. Obiously isaexec should not be applied to symlinks and I can add that to GAR. That would mean wxrc would still be a symlink to wxrc-2.8 which would then be isaexec'ed and relocated to subdirs. Does this sound right to you? Best regards -- Dago From james at opencsw.org Fri Sep 4 11:42:14 2009 From: james at opencsw.org (James Lee) Date: Fri, 04 Sep 2009 09:42:14 GMT Subject: [csw-maintainers] berkeleydb saga In-Reply-To: <1E772177-3CCB-4855-9620-3517F5DCE57D@opencsw.org> References: <1E772177-3CCB-4855-9620-3517F5DCE57D@opencsw.org> Message-ID: <20090904.9421400.1835663330@gyor.oxdrove.co.uk> On 03/09/09, 18:18:31, Dagobert Michelsen wrote regarding Re: [csw-maintainers] berkeleydb saga: > >>> Well, there is ONE reason to do it "the standard way": > >>> new packages, tend to follow the pattern of older packages. > >> ... > >> > >> The bdb4x packages will most certainly never get an update. The > >> only package to be updated would be bdb4, which already contains > >> 4.7.x, so no worries there. CSWbdb4 contains no files, only links to CSWbdb. > > my point being, that someone updating bdb4, in the distant future, may > > see the old, versioned packages, and think, "oh ok, I'd better follow > > the existing 'standard' for berkeleydb, and make a separate, new, > > berkeleydb4.8 package" > Let me put it that way: At least *I* will never forget this, > and I'm sure Mike and you won't either. And if in the distant > future somebody takes over bdb and all of us are no longer > project members I don't care. It is just too much work to > build a unified bdb4 only for "the sake of consistency" > and taking the negative side effects that every package > depending on bdb would pull in all versions as they would > be contained in bdb4, right? It would not make things > clearer. I'm confused as to why CSWbdb exists. It's not legacy because it's new. We are in the habit of suffixing the software name with the major version number. The CSWbdb4 should be the 4.X package and currently contain version 4.7 files plus links for the legacy 4.2 libs. We have no need of CSWbdb. James. From maciej at opencsw.org Fri Sep 4 12:04:35 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 4 Sep 2009 11:04:35 +0100 Subject: [csw-maintainers] /opt/csw/bin/foo=bar=/opt/csw/bin/isaexec in the prototype In-Reply-To: <8D0F5086-1849-476E-BED4-BC8BFC62AC46@opencsw.org> References: <8D0F5086-1849-476E-BED4-BC8BFC62AC46@opencsw.org> Message-ID: On Fri, Sep 4, 2009 at 10:33 AM, Dagobert Michelsen wrote: > You are using tree, nice! (whose package is orphaned and there is a new > version, btw). Is this a hint? :-) >> ...and the prototype part is: >> >> s none /opt/csw/bin/sparcv8/wxrc=/opt/csw/bin/wxrc >> f none /opt/csw/bin/sparcv8/wxrc-2.8=/opt/csw/bin/wxrc-2.8 0755 root bin >> s none >> /opt/csw/bin/wx-config=/opt/csw/lib/wx/config/gtk2-unicode-release-2.8 >> l none /opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec >> l none /opt/csw/bin/wxrc-2.8=/opt/csw/bin/isaexec 0755 root bin >> >> It looks like there is a problem when there's a symlink which later >> becomes handled by isaexec. Initial "/opt/csw/bin/wxrc=wxrc-2.8" >> becomes "/opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec". Is this a >> valid prototype line? > > Umh, no, this looks broken. Obiously isaexec should not be applied to > symlinks and I can add that to GAR. That would mean wxrc would still be a symlink to > wxrc-2.8 which would then be isaexec'ed and relocated to subdirs. Does this sound > right to you? Yes, this sounds right. Maciej From dam at opencsw.org Fri Sep 4 15:21:00 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Sep 2009 15:21:00 +0200 Subject: [csw-maintainers] Updated libtool available with GCC support Message-ID: <7609235B-544D-499A-8AD9-A7A7C1325C9E@opencsw.org> Hi folks, I just pushed an updated libtool in testing/ and installed it on test8s (alias for build8st) and test8x. The problem with the existing version is that it was not able to compile stuff with the GCC compilers. It was in there a long time ago when Robin Kay made the package and it took me a while to figure out how this worked. THIS IS COMPLETE MADNESS! Basically you have to compile libtool with every compiler you want support for, then cut out certain parts, put them away and add code in the main libtool to use the snippets when something unknown compiler is encountered. Anyway, it was a good opportunity to do a triple-modulation of ISA, version and compiler (I guess this is the only package this will ever need this). If you want to see how this works you can take a look at A test with freeradius and gcc3/gcc4 builds fine. There is currently no support for gcc2 as there is also no support for gcc2 in GAR. If somebody needs it I'll add it. So please give it a try if you have anything to compile with libtool and gcc. Best regards -- Dago From dam at opencsw.org Fri Sep 4 16:03:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Sep 2009 16:03:55 +0200 Subject: [csw-maintainers] /opt/csw/bin/foo=bar=/opt/csw/bin/isaexec in the prototype In-Reply-To: References: <8D0F5086-1849-476E-BED4-BC8BFC62AC46@opencsw.org> Message-ID: <8148FEFE-AF03-46A7-A14B-76F3EE77CAEB@opencsw.org> Hi Maciej, Am 04.09.2009 um 12:04 schrieb Maciej (Matchek) Blizinski: >>> ...and the prototype part is: >>> >>> s none /opt/csw/bin/sparcv8/wxrc=/opt/csw/bin/wxrc >>> f none /opt/csw/bin/sparcv8/wxrc-2.8=/opt/csw/bin/wxrc-2.8 0755 >>> root bin >>> s none >>> /opt/csw/bin/wx-config=/opt/csw/lib/wx/config/gtk2-unicode- >>> release-2.8 >>> l none /opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec >>> l none /opt/csw/bin/wxrc-2.8=/opt/csw/bin/isaexec 0755 root bin >>> >>> It looks like there is a problem when there's a symlink which later >>> becomes handled by isaexec. Initial "/opt/csw/bin/wxrc=wxrc-2.8" >>> becomes "/opt/csw/bin/wxrc=wxrc-2.8=/opt/csw/bin/isaexec". Is this a >>> valid prototype line? >> >> Umh, no, this looks broken. Obiously isaexec should not be applied to >> symlinks and I can add that to GAR. That would mean wxrc would >> still be a symlink to >> wxrc-2.8 which would then be isaexec'ed and relocated to subdirs. >> Does this sound >> right to you? > > Yes, this sounds right. Ok, fixed in r6176. And isaexec shouldn't have been used in the first place, this was broken since r6148 where I made some reorderings to make all local builds first (needed for pbuilds) which is fixed now in r6177. Best regards -- Dago From phil at bolthole.com Fri Sep 4 18:14:19 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Sep 2009 09:14:19 -0700 Subject: [csw-maintainers] berkeleydb saga In-Reply-To: <20090904.9421400.1835663330@gyor.oxdrove.co.uk> References: <1E772177-3CCB-4855-9620-3517F5DCE57D@opencsw.org> <20090904.9421400.1835663330@gyor.oxdrove.co.uk> Message-ID: On Fri, Sep 4, 2009 at 2:42 AM, James Lee wrote: > > CSWbdb4 contains no files, only links to CSWbdb. Hmmm. I'm thinking it would be better, the other way around. > The CSWbdb4 should be the 4.X package and > currently contain version 4.7 files plus links for the legacy 4.2 > libs. We have no need of CSWbdb. > well, I dont have a strong feeling about the existance of "CSWbdb". but I do agree that the "berkeley db 4.x latest binaries" belong in the package CSWbdb4. From phil at bolthole.com Fri Sep 4 18:17:18 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Sep 2009 09:17:18 -0700 Subject: [csw-maintainers] berkeleydb saga In-Reply-To: <20090904.9241600.918026838@gyor.oxdrove.co.uk> References: <20090904.9241600.918026838@gyor.oxdrove.co.uk> Message-ID: On Fri, Sep 4, 2009 at 2:24 AM, James Lee wrote: > .... so when I install and use bdb4 generic version 4.X the > libraries to which I link are 4.7. Therefore the package version for > bdb4 should be 4.7 not 4.2. >..... > $ pkgparam CSWbdb4 VERSION > 4.2.52,REV=2009.07.28 > good point. there was some mass chaos for a while, when the bdb pkg maintainers were trying to release bugfixes quick. this probably got lost in the confusion there. Hopefully, they will catch up and rectify this soon. From phil at bolthole.com Fri Sep 4 18:54:40 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Sep 2009 09:54:40 -0700 Subject: [csw-maintainers] robots.txt In-Reply-To: References: <4A9C3D84.5080609@opencsw.org> <4A9C577B.80509@opencsw.org> <4A9C612F.2090103@opencsw.org> Message-ID: On Wed, Sep 2, 2009 at 9:56 AM, Philip Brown wrote: > On Tue, Sep 1, 2009 at 3:11 AM, Maciej (Matchek) > Blizinski wrote: >> >> >> mod_rewrite[1] could help. There could br a rule along the lines of: >> >> RewriteRule ^/packages.php(.*) /packages$1 [R=301] >> > > Not bad. I wouldnt object to Ihsan putting that in there. FYI: this is now unneccessary. I have recoded packages.php, to do Location: header redirects. From daniel at opencsw.org Fri Sep 4 22:33:56 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 04 Sep 2009 21:33:56 +0100 Subject: [csw-maintainers] Ganglia update Message-ID: <4AA179B4.3010001@opencsw.org> Hi Dagobert, Thanks for your earlier feedback. The packages are now working, except for init scripts and SMF support. That will come shortly. However, people are welcome to test, just install the packages, and start the processes like so: On every node running the agent: /opt/csw/sbin/gmond -c /opt/csw/etc/ganglia/gmond.conf On the reporting server, run both the agent and the server: /opt/csw/sbin/gmond -c /opt/csw/etc/ganglia/gmond.conf /opt/csw/sbin/gmetad -c /opt/csw/etc/ganglia/gmetad.conf Then just browse to http:///ganglia/ and enjoy watching the graphs. Please let me know if there is anything else horribly wrong in my Makefile Regards, Daniel From dam at opencsw.org Fri Sep 4 22:43:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Sep 2009 22:43:13 +0200 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA179B4.3010001@opencsw.org> References: <4AA179B4.3010001@opencsw.org> Message-ID: Hi Daniel, Am 04.09.2009 um 22:33 schrieb Daniel Pocock: > The packages are now working, except for init scripts and SMF > support. That will come shortly. However, people are welcome to > test, just install the packages, and start the processes like so: > > On every node running the agent: > /opt/csw/sbin/gmond -c /opt/csw/etc/ganglia/gmond.conf > > On the reporting server, run both the agent and the server: > > /opt/csw/sbin/gmond -c /opt/csw/etc/ganglia/gmond.conf > /opt/csw/sbin/gmetad -c /opt/csw/etc/ganglia/gmetad.conf > > Then just browse to http:///ganglia/ and enjoy > watching the graphs. > > Please let me know if there is anything else horribly wrong in my > Makefile Looks mighty good, however there are some minor issues: - ETCGANGLIA should be /etc/opt/csw/ganglia - For httpd-ganglia.conf you should use PRESERVECONF or SAMPLECONF from CSWcswclassutils described here: Best regards -- Dago From yann at pleiades.fr.eu.org Fri Sep 4 22:54:25 2009 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 04 Sep 2009 22:54:25 +0200 Subject: [csw-maintainers] Another problem with Berkeleydb (with cyrus_imapd) Message-ID: <4AA17E81.1010109@pleiades.fr.eu.org> Hi, I run into the same problem with berkeleydb and cyrus imapd: imaps[4196]: [ID 539395 local6.crit] incorrect version of Berkeley db: compiled against 4.2.52, linked against 4.7.25 I saw a lot of thread about berkeleydb, but it's not easy to find what is current situation and what will be done to solve this problem. Can someone explain to me: - if it is planned to provide again the berkeleydb 4.2.52 package or if I have to recompile cyrus against berkeleydb 4.7 ? - if it is 100% guaranted that the upgrade to 4.7 is transparent for the user and that berkeleydb files created with 4.2 will be handled with 4.7 ? I would rather like the berkeleydb 4.2 package to be restored in its previous state so it doesn't break current cyrus installation and to give me some time to test the upgrade path to 4.7. Yann From dam at opencsw.org Fri Sep 4 23:01:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Sep 2009 23:01:26 +0200 Subject: [csw-maintainers] Another problem with Berkeleydb (with cyrus_imapd) In-Reply-To: <4AA17E81.1010109@pleiades.fr.eu.org> References: <4AA17E81.1010109@pleiades.fr.eu.org> Message-ID: <8D063F4A-0B90-4E07-9EFD-D9AE27D10530@opencsw.org> Hi Yann, Am 04.09.2009 um 22:54 schrieb Yann Rouillard: > I run into the same problem with berkeleydb and cyrus imapd: > > imaps[4196]: [ID 539395 local6.crit] incorrect version of Berkeley > db: compiled against 4.2.52, linked against 4.7.25 > > I saw a lot of thread about berkeleydb, but it's not easy to find > what is current situation and what will be done to solve this problem. > > Can someone explain to me: > > - if it is planned to provide again the berkeleydb 4.2.52 package > or if I have to recompile cyrus against berkeleydb 4.7 ? Phil, Mike: Please correct me if I'm wrong. We will put 4.2.52 back in as legacy lib in bdb4. If you could update your package to 4.7 that would be great as we generally want to reducy dependency to old libs. > - if it is 100% guaranted that the upgrade to 4.7 is transparent > for the user and that berkeleydb files created with 4.2 will be > handled with 4.7 ? We thought so. However, I am not 100% sure any more. > I would rather like the berkeleydb 4.2 package to be restored in its > previous state so it doesn't break current cyrus installation and to > give me some time to test the upgrade path to 4.7. Ok, agreed. So again: everybody please be extra careful on upgrades from current as the berkeley db issues have not been fully cleaned. It will unfortunately take some more time to reorganize things again. Best regards -- Dago From phil at bolthole.com Fri Sep 4 23:35:59 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Sep 2009 14:35:59 -0700 Subject: [csw-maintainers] Another problem with Berkeleydb (with cyrus_imapd) In-Reply-To: <8D063F4A-0B90-4E07-9EFD-D9AE27D10530@opencsw.org> References: <4AA17E81.1010109@pleiades.fr.eu.org> <8D063F4A-0B90-4E07-9EFD-D9AE27D10530@opencsw.org> Message-ID: On Fri, Sep 4, 2009 at 2:01 PM, Dagobert Michelsen wrote: > > Phil, Mike: Please correct me if I'm wrong. > > We will put 4.2.52 back in as legacy lib in bdb4. yes this would be good. also good is, >If you could [recompile your cyrus package to use] 4.7 that would be great as we generally want to reduce dependency to old libs. From daniel at opencsw.org Sat Sep 5 01:26:16 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 05 Sep 2009 00:26:16 +0100 Subject: [csw-maintainers] Ganglia update In-Reply-To: References: <4AA179B4.3010001@opencsw.org> Message-ID: <4AA1A218.90709@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 04.09.2009 um 22:33 schrieb Daniel Pocock: >> The packages are now working, except for init scripts and SMF >> support. That will come shortly. However, people are welcome to >> test, just install the packages, and start the processes like so: >> >> On every node running the agent: >> /opt/csw/sbin/gmond -c /opt/csw/etc/ganglia/gmond.conf >> >> On the reporting server, run both the agent and the server: >> >> /opt/csw/sbin/gmond -c /opt/csw/etc/ganglia/gmond.conf >> /opt/csw/sbin/gmetad -c /opt/csw/etc/ganglia/gmetad.conf >> I've now added init scripts and SMF, so that it starts automatically when you install the package. >> Then just browse to http:///ganglia/ and enjoy >> watching the graphs. >> >> Please let me know if there is anything else horribly wrong in my >> Makefile > > Looks mighty good, however there are some minor issues: > - ETCGANGLIA should be /etc/opt/csw/ganglia Done > - For httpd-ganglia.conf you should use PRESERVECONF or SAMPLECONF from > CSWcswclassutils described here: > Done One other thing that caused some issues, I tried adding these lines: ARCHALL_CSWgangliadevel = 1 ARCHALL_CSWgangliaweb = 1 but when it gets to the install-custom code, it looks for files in the wrong place, specifically: @cd $(WORKSRC)/web; \ cp -R * $(DESTDIR)$(WWWGANGLIA) and the other lines referencing $(WORKSRC) look in the wrong place. Any hints would be welcome. From maciej at opencsw.org Sat Sep 5 10:34:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Sep 2009 09:34:58 +0100 Subject: [csw-maintainers] Can't run Sun Studio in vncserver Message-ID: I'm trying to run Sun Studio 12 IDE in vncserver. It doesn't run; it appears to be starting up for some time and the just dies with return code 2: + export netbeans_extraclusters=/opt/studio/sunstudio12.1/prod/nb-clusters/sside1 + netbeans_extraclusters=/opt/studio/sunstudio12.1/prod/nb-clusters/sside1 + /opt/studio/sunstudio12.1/netbeans/bin/netbeans -J-Dspro.home=/opt/studio/sunstudio12.1 -J-Dspro.pwd=/root -J-Dnb.registration.enabled=true -J-Dnetbeans.winsys.ctrltab.editoronly=true -J-Dspro.debugger.count=0 -J-da --branding sunstudio --userdir /root/.sunstudio/12.1-SunOS-sparc --jdkhome / netra ~ # echo $? 2 (I'm running it as root because I need to start cupsd as root and you can't run a binary as a different user than your current one in the IDE.) The computer I'm trying to run the IDE on is a Netra with 2 cores and 2GB of RAM, I think it's sufficient. System Configuration: Sun Microsystems sun4u Netra t 1120/1125 (2 X UltraSPARC-II 440MHz) System clock frequency: 110 MHz Memory size: 2048 Megabytes It doesn't print any error messages. Have you ever encountered a problem like this? Maciej From dam at opencsw.org Sat Sep 5 12:42:52 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 5 Sep 2009 12:42:52 +0200 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: References: Message-ID: <884DDCCA-830F-494A-89E2-014E9A9FA232@opencsw.org> Hi Maciej, Am 05.09.2009 um 10:34 schrieb Maciej (Matchek) Blizinski: > I'm trying to run Sun Studio 12 IDE in vncserver. It doesn't run; it > appears to be starting up for some time and the just dies with return > code 2: ... > It doesn't print any error messages. Have you ever encountered a > problem like this? I also had some problem with vncserver as it is quite old and started work on a refresher. Unfortunately vncserver is awfully hard to package as it uses a combination of Imake and scripts which require tweaking results of Imake. I committed what I have, feel free to take a look. Best regards -- Dago PS: Don't get me wrong: It should not look like everytime you ask a question I propose more work for you ;-) From dam at opencsw.org Sat Sep 5 12:54:00 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 5 Sep 2009 12:54:00 +0200 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA1A218.90709@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> Message-ID: <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> Hi Daniel, Am 05.09.2009 um 01:26 schrieb Daniel Pocock: > One other thing that caused some issues, I tried adding these lines: > > ARCHALL_CSWgangliadevel = 1 > ARCHALL_CSWgangliaweb = 1 > > but when it gets to the install-custom code, it looks for files in > the wrong place, specifically: > > @cd $(WORKSRC)/web; \ > cp -R * $(DESTDIR)$(WWWGANGLIA) > > and the other lines referencing $(WORKSRC) look in the wrong place. > Any hints would be welcome. Theoretically this can't happen as ARCHALL_* only changes the gspec file. However, I would like to reproduce it, but libconfuse has neither been released nor is it in testing/. Please build it so I can install it on build8st and retry. There is also no harm in releasing libconfuse as it is a new library. Best regards -- Dago From glaw at opencsw.org Sat Sep 5 17:48:18 2009 From: glaw at opencsw.org (Gary Law) Date: Sat, 5 Sep 2009 16:48:18 +0100 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} Message-ID: Hi My latest puppet package is clashing with CSWapache2c over permissions of /etc/opt a) what should the permissions be? b) should we put this in CSWcommon? Gary -- glaw at opencsw.org From maciej at opencsw.org Sat Sep 5 17:51:36 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Sep 2009 16:51:36 +0100 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: On Sat, Sep 5, 2009 at 4:48 PM, Gary Law wrote: > Hi > > My latest puppet package is clashing with CSWapache2c over permissions > of /etc/opt > > a) what should the permissions be? Perhaps same as /etc? > b) should we put this in CSWcommon? I think it's a good idea, it's a directory shared my multiple packages. Maciej From bwalton at opencsw.org Sat Sep 5 18:10:56 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 05 Sep 2009 12:10:56 -0400 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: <1252167009-sup-8673@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sat Sep 05 11:51:36 -0400 2009: > > b) should we put this in CSWcommon? > > I think it's a good idea, it's a directory shared my multiple packages. Yes, I think that CSWcommon should swallow up /etc/opt/csw and /var/opt/csw, if it's not already there. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Sat Sep 5 18:21:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Sep 2009 17:21:54 +0100 Subject: [csw-maintainers] Sanity checks in GAR Message-ID: Dago, My day-to-day environment has umask set to 027; but many packages, when built with this umask, end up with binaries having permissions 0750. Perhaps it would be a good idea to do a GAR sanity check: bail out if umask is set to anything else than 022 when building a package? Maciej From maciej at opencsw.org Sat Sep 5 18:29:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Sep 2009 17:29:47 +0100 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: <884DDCCA-830F-494A-89E2-014E9A9FA232@opencsw.org> References: <884DDCCA-830F-494A-89E2-014E9A9FA232@opencsw.org> Message-ID: On Sat, Sep 5, 2009 at 11:42 AM, Dagobert Michelsen wrote: > PS: Don't get me wrong: It should not look like everytime you ask a > question I propose more work for you ;-) I understand that. Such is life! Well, I've spent some time and made a little progress with the build: https://sourceforge.net/apps/trac/gar/changeset/6195 It currently fails by calling 'clean' target on directories with no Makefiles. I couldn't work out where are the calls coming from. I've commited what I have right now. Maciej From glaw at opencsw.org Sat Sep 5 19:07:05 2009 From: glaw at opencsw.org (Gary Law) Date: Sat, 5 Sep 2009 18:07:05 +0100 Subject: [csw-maintainers] New in testing: puppet-0.25 Message-ID: This is the long awaited 'go faster' release of puppet. Enjoy. Gary From daniel at opencsw.org Sat Sep 5 20:41:54 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 05 Sep 2009 19:41:54 +0100 Subject: [csw-maintainers] Ganglia update In-Reply-To: <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> Message-ID: <4AA2B0F2.9030304@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 05.09.2009 um 01:26 schrieb Daniel Pocock: >> One other thing that caused some issues, I tried adding these lines: >> >> ARCHALL_CSWgangliadevel = 1 >> ARCHALL_CSWgangliaweb = 1 >> >> but when it gets to the install-custom code, it looks for files in >> the wrong place, specifically: >> >> @cd $(WORKSRC)/web; \ >> cp -R * $(DESTDIR)$(WWWGANGLIA) >> >> and the other lines referencing $(WORKSRC) look in the wrong place. >> Any hints would be welcome. > > Theoretically this can't happen as ARCHALL_* only changes the gspec > file. However, > I would like to reproduce it, but libconfuse has neither been released > nor is it > in testing/. Please build it so I can install it on build8st and > retry. There is > also no harm in releasing libconfuse as it is a new library. > > I can log in to login.bo.opencsw.org with my ssh key From there, if I try to log in to any other machine (I've tried typing `ssh build8st'), I am asked for a password I found this document on using the build farms, but it is not 100% clear, and it says it is not for GAR users: http://www.opencsw.org/standards/pkg-walkthrough Can you suggest which document I should read for doing all this the first time? From maciej at opencsw.org Sat Sep 5 20:50:48 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Sep 2009 19:50:48 +0100 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: References: <884DDCCA-830F-494A-89E2-014E9A9FA232@opencsw.org> Message-ID: On Sat, Sep 5, 2009 at 5:29 PM, Maciej (Matchek) Blizinski wrote: > On Sat, Sep 5, 2009 at 11:42 AM, Dagobert Michelsen wrote: >> PS: Don't get me wrong: It should not look like everytime you ask a >> question I propose more work for you ;-) > > I understand that. Such is life! Well, I've spent some time and made a > little progress with the build: > > https://sourceforge.net/apps/trac/gar/changeset/6195 > > It currently fails by calling 'clean' target on directories with no > Makefiles. I couldn't work out where are the calls coming from. I've > commited what I have right now. The current issue is that it tries to call a 'clean' target in a directory which doesn't have a Makefile. I tried planting my own Makefile there to define such target, but it gets renamed to Makefile.bak and the build is still failing. I mailed vncserver's mailing list with this question. Maciej From bwalton at opencsw.org Sat Sep 5 21:04:31 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 05 Sep 2009 15:04:31 -0400 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA2B0F2.9030304@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> Message-ID: <1252177400-sup-7813@ntdws12.chass.utoronto.ca> Excerpts from Daniel Pocock's message of Sat Sep 05 14:41:54 -0400 2009: > From there, if I try to log in to any other machine (I've tried typing > `ssh build8st'), I am asked for a password Create a new key on the build farm and add the public half to your authorized_keys file. This will get you access to the build machines. > I found this document on using the build farms, but it is not 100% > clear, and it says it is not for GAR users: > > http://www.opencsw.org/standards/pkg-walkthrough Please consider this deprecated. Use the documents on the following pages as a better getting started guide: http://sourceforge.net/apps/trac/gar/ HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ja at opencsw.org Sat Sep 5 21:34:28 2009 From: ja at opencsw.org (Juergen Arndt) Date: Sat, 05 Sep 2009 21:34:28 +0200 Subject: [csw-maintainers] Why do I get V8+ binaries? Message-ID: Hi all, when compiling spine (checked in into subversion) on Solaris 8 sparc, the binary which is created is a V8+ binary. So my questions are: (1) Why it becomes a V8+? I cannot find a reason for that. (2) Is this a critical thing or can I ignore it? The name of the (one and only) binary: /opt/csw/bin/spine Thank you, Juergen -- Juergen Arndt From daniel at opencsw.org Sat Sep 5 21:54:58 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 05 Sep 2009 20:54:58 +0100 Subject: [csw-maintainers] Ganglia update In-Reply-To: <1252177400-sup-7813@ntdws12.chass.utoronto.ca> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> Message-ID: <4AA2C212.9060706@opencsw.org> > Create a new key on the build farm and add the public half to your > authorized_keys file. This will get you access to the build machines. > > I've just looked in ~/.ssh/ on login, and I see that is all set up - I can actually get to some of the machines, it is just build8st that prompts for the password >> I found this document on using the build farms, but it is not 100% >> clear, and it says it is not for GAR users: >> >> http://www.opencsw.org/standards/pkg-walkthrough >> > > Please consider this deprecated. Use the documents on the following > pages as a better getting started guide: > http://sourceforge.net/apps/trac/gar/ > > Thanks, I had been looking over that as well, but it doesn't give me specific advice about what to do when my packages are ready for release. However, I've just found this: http://www.opencsw.org/standards/ I think the heading `Pkg file creation' might need to be `Pkg file creation and release', as it gives some notes about how to release - is this the most current version of the process? From daniel at opencsw.org Sat Sep 5 22:00:57 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 05 Sep 2009 21:00:57 +0100 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA2C212.9060706@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> <4AA2C212.9060706@opencsw.org> Message-ID: <4AA2C379.1070203@opencsw.org> Daniel Pocock wrote: > >> Create a new key on the build farm and add the public half to your >> authorized_keys file. This will get you access to the build machines. >> >> > I've just looked in ~/.ssh/ on login, and I see that is all set up - I > can actually get to some of the machines, it is just build8st that > prompts for the password >>> I found this document on using the build farms, but it is not 100% >>> clear, and it says it is not for GAR users: >>> >>> http://www.opencsw.org/standards/pkg-walkthrough >>> >> >> Please consider this deprecated. Use the documents on the following >> pages as a better getting started guide: >> http://sourceforge.net/apps/trac/gar/ >> > Thanks, I had been looking over that as well, but it doesn't give me > specific advice about what to do when my packages are ready for > release. However, I've just found this: > > http://www.opencsw.org/standards/ > > I think the heading `Pkg file creation' might need to be `Pkg file > creation and release', as it gives some notes about how to release - > is this the most current version of the process? I've now built libconfuse on build8s, but can't complete the scp to www.opencsw.org as described in the document above: bash-2.03$ hostname build8s bash-2.03$ scp /home/daniel/staging/build-05.Sep.2009/libconfuse-2.6,REV\=2009.09.05-SunOS5.8-sparc-CSW.pkg.gz www.opencsw.org:/home/newpkgs ssh: connect to host www.opencsw.org port 22: Network is unreachable lost connection From daniel at opencsw.org Sat Sep 5 22:19:41 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 05 Sep 2009 21:19:41 +0100 Subject: [csw-maintainers] testing a release candidate from upstream Message-ID: <4AA2C7DD.2090304@opencsw.org> Ganglia 3.1.3 will have some Solaris specific fixes (e.g. a seg fault when the first CPU is not in slot 0) I'd like to test release candidate for 3.1.3 (in other words, the monitor-core-3.1 branch from upstream SVN) by building OpenCSW packages on each of the build machines. This way any final issues can be resolved before upstream tags the release. What is the normal way of doing such a build? I notice that with my existing Makefile for the Ganglia CSW package, it wants to download a released ganglia-X.tar.gz From skayser at opencsw.org Sat Sep 5 23:05:08 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sat, 05 Sep 2009 23:05:08 +0200 Subject: [csw-maintainers] Why do I get V8+ binaries? In-Reply-To: References: Message-ID: <4AA2D284.1030401@opencsw.org> Hi Juergen, Juergen Arndt wrote on 05.09.2009 21:34: > when compiling spine (checked in into subversion) on Solaris 8 sparc, the > binary which is created is a V8+ binary. So my questions are: > > (1) Why it becomes a V8+? I cannot find a reason for that. > (2) Is this a critical thing or can I ignore it? > > The name of the (one and only) binary: /opt/csw/bin/spine it's simple. :) You are using a custom configure target which is missing the $(CONFIGURE_ENV) environment and thus the $(CFLAGS), in particular the -xarch=v8 one. Better use the pre-configure-modulated hook instead. I have committed an adjusted version of the Makefile. $ svn diff -r6089:6199 Makefile In case you want to revert these changes just do $ svn merge -r6199:6089 Makefile $ svn commit -m "spine: Undid r6199" Sebastian From skayser at opencsw.org Sat Sep 5 23:07:11 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sat, 05 Sep 2009 23:07:11 +0200 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA2C379.1070203@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> <4AA2C212.9060706@opencsw.org> <4AA2C379.1070203@opencsw.org> Message-ID: <4AA2D2FF.5050405@opencsw.org> Hi Daniel, Daniel Pocock wrote on 05.09.2009 22:00: > I've now built libconfuse on build8s, but can't complete the scp to > www.opencsw.org as described in the document above: > > bash-2.03$ hostname > build8s > bash-2.03$ scp > /home/daniel/staging/build-05.Sep.2009/libconfuse-2.6,REV\=2009.09.05-SunOS5.8-sparc-CSW.pkg.gz > www.opencsw.org:/home/newpkgs > ssh: connect to host www.opencsw.org port 22: Network is unreachable > lost connection outgoing SSH from the build hosts is blocked. You need to scp from the login host. Sebastian From bonivart at opencsw.org Sun Sep 6 00:08:38 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 6 Sep 2009 00:08:38 +0200 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: <625385e30909051508q2df9f78cpd1cbd9b9294edcee@mail.gmail.com> On Sat, Sep 5, 2009 at 5:48 PM, Gary Law wrote: > Hi > > My latest puppet package is clashing with CSWapache2c over permissions > of /etc/opt > > a) what should the permissions be? > b) should we put this in CSWcommon? Aren't /etc/opt and /var/opt installed by default in Solaris? I think you should start with /etc/opt/csw and /var/opt/csw respectively. Both those are included in CSWcommon and CSWcswclassutils. -- /peter From glaw at opencsw.org Sun Sep 6 00:50:15 2009 From: glaw at opencsw.org (Gary Law) Date: Sat, 5 Sep 2009 23:50:15 +0100 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: <625385e30909051508q2df9f78cpd1cbd9b9294edcee@mail.gmail.com> References: <625385e30909051508q2df9f78cpd1cbd9b9294edcee@mail.gmail.com> Message-ID: 2009/9/5 Peter Bonivart : > Aren't /etc/opt and /var/opt installed by default in Solaris? I think > you should start with /etc/opt/csw and /var/opt/csw respectively. Both > those are included in CSWcommon and CSWcswclassutils. In which case there is a bug in CSWapache2c and my package too. I don't have a clean Solaris install to hand to check this; if someone could confirm this is correct I'll fix up my package and fill a mantis bug on Apache. Thanks Gary -- Gary Law Email: garylaw at garylaw.net Chat googletalk/messenger: gary.law at gmail.com iChat/jabber/AIM: gary.law at mac.com From glaw at opencsw.org Sun Sep 6 02:18:58 2009 From: glaw at opencsw.org (Gary Law) Date: Sun, 6 Sep 2009 01:18:58 +0100 Subject: [csw-maintainers] testing a release candidate from upstream In-Reply-To: <4AA2C7DD.2090304@opencsw.org> References: <4AA2C7DD.2090304@opencsw.org> Message-ID: Hi Daniel 2009/9/5 Daniel Pocock : > I'd like to test release candidate for 3.1.3 (in other words, the > monitor-core-3.1 branch from upstream SVN) by building OpenCSW packages on > each of the build machines. ?This way any final issues can be resolved > before upstream tags the release. I've recently done this with the puppet 0.25 RC build. As it violates OpenCSW rules for release I built it, tested it, and made it available not through OpenCSW (advertised on the puppet dev list). I assumed RC software violates the ''no betas'' rule. Perhaps it would be OK to release this just to ''testing'' but I've not seen this done before and so didn't blaze a trail. Incidentally, this RC trial was very useful and identified at least one bug that would most likely have been missed had I not done this, and which is now fixed upstream. > What is the normal way of doing such a build? ?I notice that with my > existing Makefile for the Ganglia CSW package, it wants to download a > released ganglia-X.tar.gz Is the RC available as a downloadable tar.gz? In which case GAR can be kidded into building it AFAIK. If it's just an SVN checkout you'll have to make a tar of your own and put it where GAR expects to find it I think. Gary -- Gary Law glaw at opencsw.org From bwalton at opencsw.org Sun Sep 6 02:31:19 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 05 Sep 2009 20:31:19 -0400 Subject: [csw-maintainers] testing a release candidate from upstream In-Reply-To: References: <4AA2C7DD.2090304@opencsw.org> Message-ID: <1252197025-sup-3410@ntdws12.chass.utoronto.ca> Excerpts from Gary Law's message of Sat Sep 05 20:18:58 -0400 2009: > Is the RC available as a downloadable tar.gz? In which case GAR can be > kidded into building it AFAIK. If it's just an SVN checkout you'll > have to make a tar of your own and put it where GAR expects to find it > I think. There is some support in GAR for tracking an upstream svn repo instead of a tarball. I haven't used it and can't speak to how well it works, but it is in there. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton at opencsw.org Sun Sep 6 03:08:43 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 05 Sep 2009 21:08:43 -0400 Subject: [csw-maintainers] Summary for OpenCSW summer camp? In-Reply-To: <05320A9D-7803-4BF9-832E-72BF83950470@opencsw.org> References: <1251420014-sup-2740@ntdws12.chass.utoronto.ca> <05320A9D-7803-4BF9-832E-72BF83950470@opencsw.org> Message-ID: <1252199120-sup-3463@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sat Aug 29 04:32:38 -0400 2009: Hi Dago, > Please follow-up so it didn't get lost the second time. I just commited the updated checkpkg to GAR. It's the reference script in gar/bin/checkpkg now, although it's not used by GAR at this point. The following modification would be required to force this version into play: --snip-- Index: gar.pkg.mk =================================================================== --- gar.pkg.mk (revision 6198) +++ gar.pkg.mk (working copy) @@ -587,7 +587,7 @@ pkgcheck-%: @echo " ==> Checking compliance: $*" - @( LC_ALL=C checkpkg $(SPKG_EXPORT)/`$(call _PKG_ENV,$1) mkpackage -qs $(WORKDIR)/$*.gspec -D pkgfile`.gz ) || exit 2 + @( LC_ALL=C $(GARBIN)/checkpkg $(SPKG_EXPORT)/`$(call _PKG_ENV,$1) mkpackage -qs $(WORKDIR)/$*.gspec -D pkgfile`.gz ) || exit 2 pkgcheck-p: @$(foreach COOKIEFILE,$(PKGCHECK_TARGETS), test -e $(COOKIEDIR)/$(COOKIEFILE) ;) --snip-- This new version can handle libraries that are split out as well as inter-set dependencies. I've tested with the packages created by the bind build (since none of them are on the build farm boxes) and it seems to behave properly. If you're happy with this, I can proceed to modifying GAR so that all packages are validated together which would leverage the new capabilities. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ja at opencsw.org Sun Sep 6 06:55:51 2009 From: ja at opencsw.org (Juergen Arndt) Date: Sun, 06 Sep 2009 06:55:51 +0200 Subject: [csw-maintainers] Why do I get V8+ binaries? In-Reply-To: <4AA2D284.1030401@opencsw.org> References: <4AA2D284.1030401@opencsw.org> Message-ID: Hi Sebastian, On Sat, 05 Sep 2009 23:05:08 +0200, Sebastian Kayser wrote: > it's simple. :) You are using a custom configure target which is missing > the $(CONFIGURE_ENV) environment and thus the $(CFLAGS), in particular > the -xarch=v8 one. Uh, shame on me :) Now as you say it, it's obviously :) > Better use the pre-configure-modulated hook instead. I have committed an > adjusted version of the Makefile. Great, thanks a lot! Juergen -- Juergen Arndt From skayser at opencsw.org Sun Sep 6 07:50:21 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 06 Sep 2009 07:50:21 +0200 Subject: [csw-maintainers] testing a release candidate from upstream In-Reply-To: <1252197025-sup-3410@ntdws12.chass.utoronto.ca> References: <4AA2C7DD.2090304@opencsw.org> <1252197025-sup-3410@ntdws12.chass.utoronto.ca> Message-ID: <4AA34D9D.3060501@opencsw.org> Ben Walton wrote on 06.09.2009 02:31: > Excerpts from Gary Law's message of Sat Sep 05 20:18:58 -0400 2009: > >> Is the RC available as a downloadable tar.gz? In which case GAR can be >> kidded into building it AFAIK. If it's just an SVN checkout you'll >> have to make a tar of your own and put it where GAR expects to find it >> I think. > > There is some support in GAR for tracking an upstream svn repo instead > of a tarball. I haven't used it and can't speak to how well it works, > but it is in there. Haven't used it either, but here are a couple of examples https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/websvn/trunk/Makefile https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/xmlrpc_c/trunk/Makefile Sebastian From maciej at opencsw.org Sun Sep 6 09:07:04 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 6 Sep 2009 08:07:04 +0100 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: <625385e30909051508q2df9f78cpd1cbd9b9294edcee@mail.gmail.com> Message-ID: On Sat, Sep 5, 2009 at 11:50 PM, Gary Law wrote: > 2009/9/5 Peter Bonivart : >> Aren't /etc/opt and /var/opt installed by default in Solaris? I think >> you should start with /etc/opt/csw and /var/opt/csw respectively. Both >> those are included in CSWcommon and CSWcswclassutils. > > In which case there is a bug in CSWapache2c and my package too. I > don't have a clean Solaris install to hand to check this; if someone > could confirm this is correct I'll fix up my package and fill a mantis > bug on Apache. Yes, this is correct. You can remove this path, and ignore the warning about the missing path. Maciej From daniel at opencsw.org Sun Sep 6 09:47:14 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Sun, 06 Sep 2009 08:47:14 +0100 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA2D2FF.5050405@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> <4AA2C212.9060706@opencsw.org> <4AA2C379.1070203@opencsw.org> <4AA2D2FF.5050405@opencsw.org> Message-ID: <4AA36902.4050908@opencsw.org> Sebastian Kayser wrote: > Hi Daniel, > > Daniel Pocock wrote on 05.09.2009 22:00: > >> I've now built libconfuse on build8s, but can't complete the scp to >> www.opencsw.org as described in the document above: >> >> bash-2.03$ hostname >> build8s >> bash-2.03$ scp >> /home/daniel/staging/build-05.Sep.2009/libconfuse-2.6,REV\=2009.09.05-SunOS5.8-sparc-CSW.pkg.gz >> www.opencsw.org:/home/newpkgs >> ssh: connect to host www.opencsw.org port 22: Network is unreachable >> lost connection >> > > outgoing SSH from the build hosts is blocked. You need to scp from the > login host. > > OK, the libconfuse package is now in www.opencsw.org:/home/newpkgs How do I go about having it installed on the build machines so that I can build the Ganglia packages for release? From skayser at opencsw.org Sun Sep 6 14:34:33 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 06 Sep 2009 14:34:33 +0200 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA36902.4050908@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> <4AA2C212.9060706@opencsw.org> <4AA2C379.1070203@opencsw.org> <4AA2D2FF.5050405@opencsw.org> <4AA36902.4050908@opencsw.org> Message-ID: <4AA3AC59.4030902@opencsw.org> Daniel Pocock wrote on 06.09.2009 09:47: > Sebastian Kayser wrote: >> Daniel Pocock wrote on 05.09.2009 22:00: >>> I've now built libconfuse on build8s, but can't complete the scp to >>> www.opencsw.org as described in the document above: >>> >>> bash-2.03$ hostname >>> build8s >>> bash-2.03$ scp >>> /home/daniel/staging/build-05.Sep.2009/libconfuse-2.6,REV\=2009.09.05-SunOS5.8-sparc-CSW.pkg.gz >>> www.opencsw.org:/home/newpkgs >>> ssh: connect to host www.opencsw.org port 22: Network is unreachable >>> lost connection >>> >> outgoing SSH from the build hosts is blocked. You need to scp from the >> login host. >> >> > OK, the libconfuse package is now in www.opencsw.org:/home/newpkgs > > How do I go about having it installed on the build machines so that I > can build the Ganglia packages for release? Let Phil now that the libconfuse package resides in newpkgs (see [1] all the way down for some instructions) and once it has been published to the catalog, mail the buildfarm admins [2] to have it installed on the build farm boxes. Sebastian [1] http://opencsw.org/standards/pkg-walkthrough [2] http://opencsw.org/standards/build_farm From ja at opencsw.org Sun Sep 6 16:00:20 2009 From: ja at opencsw.org (Juergen Arndt) Date: Sun, 06 Sep 2009 16:00:20 +0200 Subject: [csw-maintainers] Spine 0.8.7e in testing Message-ID: Hi all, I put spine 0.8.7e into testing. Spine - formally known as Cactid - is a alternative poller for cacti. Feedback is welcome. Juergen -- Juergen Arndt From dam at opencsw.org Sun Sep 6 22:04:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:04:26 +0200 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: Hi Gary, Am 05.09.2009 um 17:48 schrieb Gary Law: > My latest puppet package is clashing with CSWapache2c over permissions > of /etc/opt CSWapache2c should not contain /etc/opt as it is already in SUNWcsr (with root:sys 0755). > a) what should the permissions be? The path should not be included in CSW packages. /etc/opt/csw is already in CSWcommon and should therefore also not be included (and is by default root:bin 0755) > b) should we put this in CSWcommon? It already is amongst /var/opt/csw. See the commondirs excluded from GAR here http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/etc which are extracted from the CSWcommon package. (If it is a good idea to build CSWcommon manually and derive pathes in GAR from it and not the other way round is another discussion). Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:14:20 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:14:20 +0200 Subject: [csw-maintainers] Sanity checks in GAR In-Reply-To: References: Message-ID: <911063D4-D74B-498B-953A-AA5392B7CC92@opencsw.org> Hi Maciej, Am 05.09.2009 um 18:21 schrieb Maciej (Matchek) Blizinski: > My day-to-day environment has umask set to 027; but many packages, > when built with this umask, end up with binaries having permissions > 0750. Perhaps it would be a good idea to do a GAR sanity check: bail > out if umask is set to anything else than 022 when building a package? The standard user:group are already set in cswproto, as are the permissions for directories: > # Prototype defaults > $StdOwn = 'root'; > $StdGrp = 'bin'; > $StdDirPerm = '0755'; I could imagine setting a default for files. Or changing the umask to 022 automatically on GAR invocation. BTW, we still a way of easily tweaking the prototype as PROTOTYPE_FILTERs are still too complex. Something like this could be useful: PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf PROTOTYPE_PERMS_mytweaks = 0644 PROTOTYPE_CLASS_mytweaks = cswconffile PROTOTYPE_MODIFIERS = mytweaks Here, PROTOTYPE_MODIFIERS is a list of modifiers to apply where for each modifier one or more fields can be changed. Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:17:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:17:13 +0200 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: References: <884DDCCA-830F-494A-89E2-014E9A9FA232@opencsw.org> Message-ID: Hi Maciej, Am 05.09.2009 um 18:29 schrieb Maciej (Matchek) Blizinski: > On Sat, Sep 5, 2009 at 11:42 AM, Dagobert Michelsen > wrote: >> PS: Don't get me wrong: It should not look like everytime you ask a >> question I propose more work for you ;-) > > I understand that. Such is life! Well, I've spent some time and made a > little progress with the build: > > https://sourceforge.net/apps/trac/gar/changeset/6195 A small comment: - You have removed "TEST_SCRIPTS =" and inserted "SKIPTEST = 1". The SKIPTEST is meant to be used dynamically during package when you don't want to wait, like gmake clean && SKIPTEST = 1 gmake package When the package doesn't have a test script cleaning TEST_SCRIPTS is clearer. Apart from that: good work! Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:19:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:19:45 +0200 Subject: [csw-maintainers] Why do I get V8+ binaries? In-Reply-To: References: Message-ID: Hi J?rgen, Am 05.09.2009 um 21:34 schrieb Juergen Arndt: > when compiling spine (checked in into subversion) on Solaris 8 > sparc, the binary which is created is a V8+ binary. So my questions > are: > > (1) Why it becomes a V8+? I cannot find a reason for that. > (2) Is this a critical thing or can I ignore it? It is sort of critical as the binaries are then no longer runnable on all machines supported by Solaris 8. However, as we officially deprecated Solaris 8 this is not really bad, but still a Good Thing(tm) to do. Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:22:04 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:22:04 +0200 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA2C212.9060706@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> <4AA2C212.9060706@opencsw.org> Message-ID: <076A724E-CC40-41D9-85E5-291045D393D5@opencsw.org> Hi Daniel, Am 05.09.2009 um 21:54 schrieb Daniel Pocock: >> Create a new key on the build farm and add the public half to your >> authorized_keys file. This will get you access to the build >> machines. >> > > I've just looked in ~/.ssh/ on login, and I see that is all set up - > I can actually get to some of the machines, it is just build8st that > prompts for the password The test machines don't have fully synced user accounts as they tend to be down from time to time. As we are working on LDAP accounts this will go away soon. Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:26:04 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:26:04 +0200 Subject: [csw-maintainers] testing a release candidate from upstream In-Reply-To: <4AA2C7DD.2090304@opencsw.org> References: <4AA2C7DD.2090304@opencsw.org> Message-ID: Hi Daniel, Am 05.09.2009 um 22:19 schrieb Daniel Pocock: > Ganglia 3.1.3 will have some Solaris specific fixes (e.g. a seg > fault when the first CPU is not in slot 0) > > I'd like to test release candidate for 3.1.3 (in other words, the > monitor-core-3.1 branch from upstream SVN) by building OpenCSW > packages on each of the build machines. This way any final issues > can be resolved before upstream tags the release. > > What is the normal way of doing such a build? I notice that with my > existing Makefile for the Ganglia CSW package, it wants to download > a released ganglia-X.tar.gz The easiest thing is that you roll your own ganglia-3.1.3rc1.tar.gz package and put it in /home/src. This will be tried first on downloading. You can also subscribe to SVN which is described in (4) at but "gmake garchive" will not upload the revision, so you may not always get what you expect. That's way I recommend rolling up your dist. Couldn't you just gmake tardist or something from the checked out thing? Then just copy over to /home/ src. Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:27:23 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:27:23 +0200 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA2D2FF.5050405@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA2B0F2.9030304@opencsw.org> <1252177400-sup-7813@ntdws12.chass.utoronto.ca> <4AA2C212.9060706@opencsw.org> <4AA2C379.1070203@opencsw.org> <4AA2D2FF.5050405@opencsw.org> Message-ID: Hi, Am 05.09.2009 um 23:07 schrieb Sebastian Kayser: > Daniel Pocock wrote on 05.09.2009 22:00: >> I've now built libconfuse on build8s, but can't complete the scp to >> www.opencsw.org as described in the document above: >> >> bash-2.03$ hostname >> build8s >> bash-2.03$ scp >> /home/daniel/staging/build-05.Sep.2009/libconfuse-2.6,REV >> \=2009.09.05-SunOS5.8-sparc-CSW.pkg.gz >> www.opencsw.org:/home/newpkgs >> ssh: connect to host www.opencsw.org port 22: Network is unreachable >> lost connection > > outgoing SSH from the build hosts is blocked. You need to scp from the > login host. To be precise: It is not blocked. The buildmachines have private IP adresses from 192.168.* and there is no natting. 'login' is dual-homed with an official and a 192.168.* address. For HTTP and SVN/WebDAV there is a proxy installed. Best regard -- Dago From dam at opencsw.org Sun Sep 6 22:29:21 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:29:21 +0200 Subject: [csw-maintainers] testing a release candidate from upstream In-Reply-To: References: <4AA2C7DD.2090304@opencsw.org> Message-ID: Hi Gary, Am 06.09.2009 um 02:18 schrieb Gary Law: > I've recently done this with the puppet 0.25 RC build. As it violates > OpenCSW rules for release I built it, tested it, and made it available > not through OpenCSW (advertised on the puppet dev list). I assumed RC > software violates the ''no betas'' rule. For release to current/: yes. > Perhaps it would be OK to > release this just to ''testing'' but I've not seen this done before > and so didn't blaze a trail. Absolutely, this is what testing/ is for. Just put in there what you want to have tested. No need to transfer the packages to other sites. Upstream is one of the things I consider very important and we are offering accounts on the build farm to upstream maintainers not making packages, btw. Best regards -- Dago From dam at opencsw.org Sun Sep 6 22:33:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 Sep 2009 22:33:43 +0200 Subject: [csw-maintainers] 'checkpkg' checking multiple packages at once In-Reply-To: <1252199120-sup-3463@ntdws12.chass.utoronto.ca> References: <1251420014-sup-2740@ntdws12.chass.utoronto.ca> <05320A9D-7803-4BF9-832E-72BF83950470@opencsw.org> <1252199120-sup-3463@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 06.09.2009 um 03:08 schrieb Ben Walton: > I just commited the updated checkpkg to GAR. It's the reference > script in gar/bin/checkpkg now, although it's not used by GAR at this > point. The following modification would be required to force this > version into play: > > --snip-- > Index: gar.pkg.mk > =================================================================== > --- gar.pkg.mk (revision 6198) > +++ gar.pkg.mk (working copy) > @@ -587,7 +587,7 @@ > > pkgcheck-%: > @echo " ==> Checking compliance: $*" > - @( LC_ALL=C checkpkg $(SPKG_EXPORT)/`$(call _PKG_ENV,$1) > mkpackage -qs $(WORKDIR)/$*.gspec -D pkgfile`.gz ) || exit 2 > + @( LC_ALL=C $(GARBIN)/checkpkg $(SPKG_EXPORT)/`$(call > _PKG_ENV,$1) mkpackage -qs $(WORKDIR)/$*.gspec -D pkgfile`.gz > ) || exit 2 > > pkgcheck-p: > @$(foreach COOKIEFILE,$(PKGCHECK_TARGETS), test -e > $(COOKIEDIR)/$(COOKIEFILE) ;) > --snip-- > > This new version can handle libraries that are split out as well as > inter-set dependencies. I've tested with the packages created by the > bind build (since none of them are on the build farm boxes) and it > seems to behave properly. > > If you're happy with this, I can proceed to modifying GAR so that all > packages are validated together which would leverage the new > capabilities. Cool! Phil: I would include that into CSWcswutils, ok? Ben: If the updated version gets into CSWcswutils there is no need for a GAR-private checkpkg. CSWcswutils is already built with GAR and checkpkg is tracked at Best regards -- Dago From maciej at opencsw.org Mon Sep 7 10:28:55 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 7 Sep 2009 09:28:55 +0100 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: References: <884DDCCA-830F-494A-89E2-014E9A9FA232@opencsw.org> Message-ID: On Sun, Sep 6, 2009 at 9:17 PM, Dagobert Michelsen wrote: > A small comment: > - You have removed "TEST_SCRIPTS =" and inserted "SKIPTEST = 1". The > SKIPTEST > ?is meant to be used dynamically during package when you don't want to wait, > like > ? ?gmake clean && SKIPTEST = 1 gmake package > ?When the package doesn't have a test script cleaning TEST_SCRIPTS is > clearer. I see, I changed it back to TEST_SCRIPTS. The build scripts for tightvnc are indeed quite convoluted. I was stuck for quite a while at a place where there was a missing flag "-f xmakefile", and gmake wasn't executing the right Makefile. I suspect some changes I'm making to the Makefile aren't really necessary, but it's very time consuming to figure out what are the perfect options, and I only want to have something running, as soon as possible, with the intention to clean it up later. What I really don't like about the way tightvnc is built is that the script don't always stop on errors. For instance: gmake[7]: Entering directory `/home/maciej/src/opencsw/pkg/tightvnc/trunk/work/build-isa-sparcv8/vnc_unixsrc/Xvnc/config/makedepend' /opt/studio/SOS11/SUNWspro/bin/cc -xO3 -xarch=v8 -I/usr/openwin/share/include/X11 -I/opt/csw/include -I/usr/openwin/share/include/X11 -I/opt/csw/include -c -o include.o include.c "/usr/openwin/share/include/X11/Xos.h", line 35: cannot find include file: cc: acomp failed for include.c gmake[7]: *** [include.o] Error 1 gmake[7]: Leaving directory `/home/maciej/src/opencsw/pkg/tightvnc/trunk/work/build-isa-sparcv8/vnc_unixsrc/Xvnc/config/makedepend' okay, continuing in programs/Xserver/cfb32 ...and then it finally fails with: cc: acomp failed for include.c gmake[7]: *** [include.o] Error 1 gmake[7]: Leaving directory `/home/maciej/src/opencsw/pkg/tightvnc/trunk/work/build-isa-sparcv8/vnc_unixsrc/Xvnc/config/makedepend' okay, continuing in programs/Xserver/hw/vnc ../../../../config/makedepend/makedepend -- -I. -I../../../../exports/include/X11 -I../../../../include/fonts -I../../../../exports/include/X11 -I../../cfb -I../../mfb -I../../mi -I../../include -I../../os -I../../../../../include -I/usr/local/include -I../../../.. -I../../../../exports/include -Dsun -DSVR4 -DSHAPE -DINCLUDE_ALLOCA_H -DNDEBUG -DUSE_LIBWRAP=1 -DDDXOSINIT -- init.c sockets.c kbdptr.c cmap.c draw.c cutpaste.c dispcur.c sprite.c rfbserver.c translate.c httpd.c auth.c rre.c corre.c stats.c hextile.c zlib.c tight.c cursor.c gmake[6]: ../../../../config/makedepend/makedepend: Command not found I'm wondering whether anybody has ever built it on Solaris; I guess not. Now I need to track where is the flag -I/usr/openwin/share/include/X11 coming from and fix it. I've committed the current state of the build to the repository: http://sourceforge.net/apps/trac/gar/changeset/6213 Maciej From schwindt at dfki.uni-kl.de Mon Sep 7 10:41:25 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 07 Sep 2009 10:41:25 +0200 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: Your message of "Sat, 05 Sep 2009 09:34:58 BST." Message-ID: <200909070841.n878fPOX017084@dfki.uni-kl.de> [...] > It doesn't print any error messages. Have you ever encountered a > problem like this? Yes - back then I used x11vnc to tunnel the display. It sucks, like vncserver - but java guis get displayed. Nicolai From james at opencsw.org Mon Sep 7 11:54:46 2009 From: james at opencsw.org (James Lee) Date: Mon, 07 Sep 2009 09:54:46 GMT Subject: [csw-maintainers] Why do I get V8+ binaries? In-Reply-To: References: Message-ID: <20090907.9544600.1130459864@gyor.oxdrove.co.uk> On 06/09/09, 21:19:45, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Why do I get V8+ binaries?: > > sparc, the binary which is created is a V8+ binary. So my questions > > are: > > > > (1) Why it becomes a V8+? I cannot find a reason for that. > > (2) Is this a critical thing or can I ignore it? > It is sort of critical as the binaries are then no longer runnable on > all > machines supported by Solaris 8. However, as we officially deprecated > Solaris 8 this is not really bad, but still a Good Thing(tm) to do. Solaris 9 runs on sun4m so the Solaris 8 point is invalid. We will continue to support 9 for some time so the sun4m question remains. Does sun4m matter? It seems to matter to a few people and although they are only small number it is 100% critical to them. I do my bit to run a living computer museum but I am long past running a sun4m machine for anything other than a toy or test. I can just see why a stand alone server might be better on a Sparc20 as my SS20 (125MHz, 512GB RAM) uses 58 Watts idle whereas my Blade2000 (1.2GHz, 8GB RAM) use 185W idle. Of course the Blade 2000 can do what a the SS20 can in one of its corners with no one noticing plus 10 times more but this assume I have the faster machine running and have more to do. Why anyone chooses to run GUI apps on such slow hardware is beyond me. However because we run an integrated system long dependency chains dictate the base arch, i.e. if one package fails the system fails. Finally it's worth pointing out that in most cases sun4m (code not chip) gives the same performance as sun4u (sparcv8plus+vis) and where it differs and matters we have the isaexec and $ISALIST mechanisms. Consider also that for many programs speed is not important and small size might be the goal (-xO3 -xspace), e.g. background daemons and network limited. James. From dam at opencsw.org Mon Sep 7 13:23:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 7 Sep 2009 13:23:55 +0200 Subject: [csw-maintainers] Why do I get V8+ binaries? In-Reply-To: <20090907.9544600.1130459864@gyor.oxdrove.co.uk> References: <20090907.9544600.1130459864@gyor.oxdrove.co.uk> Message-ID: <1B5148EF-904C-43ED-BA62-72AF77F182AC@opencsw.org> Hi James, Am 07.09.2009 um 11:54 schrieb James Lee: > On 06/09/09, 21:19:45, Dagobert Michelsen wrote > regarding >> It is sort of critical as the binaries are then no longer runnable on >> all >> machines supported by Solaris 8. However, as we officially deprecated >> Solaris 8 this is not really bad, but still a Good Thing(tm) to do. > > Solaris 9 runs on sun4m so the Solaris 8 point is invalid. We will > continue to support 9 for some time so the sun4m question remains. Ups, sorry. > Does sun4m matter? It seems to matter to a few people and although > they are only small number it is 100% critical to them. > > I do my bit to run a living computer museum but I am long past running > a sun4m machine for anything other than a toy or test. I can just see > why a stand alone server might be better on a Sparc20 as my SS20 > (125MHz, 512GB RAM) WOW! 512 GB is a hell of a lot - even for a Sparc20 :-D > uses 58 Watts idle whereas my Blade2000 (1.2GHz, > 8GB RAM) use 185W idle. Of course the Blade 2000 can do what a the > SS20 can in one of its corners with no one noticing plus 10 times more > but this assume I have the faster machine running and have more to do. > Why anyone chooses to run GUI apps on such slow hardware is beyond me. > However because we run an integrated system long dependency chains > dictate the base arch, i.e. if one package fails the system fails. Best regards -- Dago From james at opencsw.org Mon Sep 7 13:47:43 2009 From: james at opencsw.org (James Lee) Date: Mon, 07 Sep 2009 11:47:43 GMT Subject: [csw-maintainers] Why do I get V8+ binaries? In-Reply-To: <1B5148EF-904C-43ED-BA62-72AF77F182AC@opencsw.org> References: <20090907.9544600.1130459864@gyor.oxdrove.co.uk> <1B5148EF-904C-43ED-BA62-72AF77F182AC@opencsw.org> Message-ID: <20090907.11474300.259407791@gyor.oxdrove.co.uk> On 07/09/09, 12:23:55, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Why do I get V8+ binaries?: > > why a stand alone server might be better on a Sparc20 as my SS20 > > (125MHz, 512GB RAM) > WOW! 512 GB is a hell of a lot - even for a Sparc20 :-D Ha, that shows the GB has been the basic unit of RAM for so long... James. From bwalton at opencsw.org Mon Sep 7 23:09:53 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Sep 2009 17:09:53 -0400 Subject: [csw-maintainers] updated libxslt in testing Message-ID: <1252357584-sup-7025@ntdws12.chass.utoronto.ca> Hi All, I've placed updated packages (untested by myself yet) in testing/. These introduce catalog name changes for the python bindings (now py_libxslt) and the devel files (libxslt_devel now). The update includes a patch to correct a sefault while debugging xsltproc runs but otherwise should be identical to the current release. I'll be testing the packages later tonight or tomorrow, but if you happen to update from testing today you may want to be aware of these name changes. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Tue Sep 8 10:33:57 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 8 Sep 2009 09:33:57 +0100 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory Message-ID: Most packages put their files in /opt/csw; but some seem to be special, and use /opt/csw/${something}. For instance, MySQL 5 uses /opt/csw/mysql5. I understand that it's a way of having multiple versions of MySQL on one system at the same time, but it's somewhat annoying to not have the mysql binaries in the PATH right after installation. Was /opt/csw/mysql5 with a separate bin with no symlinks from /opt/csw/bin a solution that was a result of a discussion, or was is only because the maintainer just did it this way? Maciej From maciej at opencsw.org Tue Sep 8 20:46:10 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 8 Sep 2009 19:46:10 +0100 Subject: [csw-maintainers] sh: gnome-config: not found Message-ID: I'm trying to build pinentry. Here's where I'm currently stuck: $ PKG_CONFIG=/opt/csw/lib/pkgconfig pkg-config --exists gtk+-2.0 sh: gnome-config: not found The needed file is present on the disk: $ glocate gtk+-2.0.pc /opt/csw/lib/amd64/pkgconfig/gtk+-2.0.pc /opt/csw/lib/pkgconfig/gtk+-2.0.pc /usr/lib/amd64/pkgconfig/gtk+-2.0.pc /usr/lib/pkgconfig/gtk+-2.0.pc Is it a common problem? Is there a workaround? Maciej From skayser at opencsw.org Tue Sep 8 21:06:43 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 08 Sep 2009 21:06:43 +0200 Subject: [csw-maintainers] sh: gnome-config: not found In-Reply-To: References: Message-ID: <4AA6AB43.7060304@opencsw.org> Maciej (Matchek) Blizinski wrote on 08.09.2009 20:46: > I'm trying to build pinentry. Here's where I'm currently stuck: > > $ PKG_CONFIG=/opt/csw/lib/pkgconfig pkg-config --exists gtk+-2.0 > sh: gnome-config: not found > > The needed file is present on the disk: > > $ glocate gtk+-2.0.pc > /opt/csw/lib/amd64/pkgconfig/gtk+-2.0.pc > /opt/csw/lib/pkgconfig/gtk+-2.0.pc > /usr/lib/amd64/pkgconfig/gtk+-2.0.pc > /usr/lib/pkgconfig/gtk+-2.0.pc > > Is it a common problem? Is there a workaround? Seems to be a result of the CSW X11 lib relocation to /opt/csw/X11/lib. While looking for gtk+-2.0, pkg-config searches for xcb, falls back to legacy gnome-config and fails (issue pkg-config with --debug to trace this down). Pointing PKG_CONFIG_PATH to /opt/csw/X11/lib does the trick for me. Should this PKG_CONFIG_PATH be added to the GAR defaults? Sebastian From maciej at opencsw.org Tue Sep 8 21:12:22 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 8 Sep 2009 20:12:22 +0100 Subject: [csw-maintainers] sh: gnome-config: not found In-Reply-To: <4AA6AB43.7060304@opencsw.org> References: <4AA6AB43.7060304@opencsw.org> Message-ID: On Tue, Sep 8, 2009 at 8:06 PM, Sebastian Kayser wrote: > Seems to be a result of the CSW X11 lib relocation to /opt/csw/X11/lib. > While looking for gtk+-2.0, pkg-config searches for xcb, falls back to > legacy gnome-config and fails (issue pkg-config with --debug to trace > this down). > > Pointing PKG_CONFIG_PATH to /opt/csw/X11/lib does the trick for me. Works here too. Thanks! > Should this PKG_CONFIG_PATH be added to the GAR defaults? +1 Maciej From dam at opencsw.org Tue Sep 8 23:01:56 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 Sep 2009 23:01:56 +0200 Subject: [csw-maintainers] Bug resolving processess Message-ID: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> Hi, after some discussion with James I made an outline for processing bugs on the wiki: Feel free to comment. Best regards -- Dago From maciej at opencsw.org Tue Sep 8 23:09:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 8 Sep 2009 22:09:46 +0100 Subject: [csw-maintainers] Bug resolving processess In-Reply-To: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> References: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> Message-ID: On Tue, Sep 8, 2009 at 10:01 PM, Dagobert Michelsen wrote: > Hi, > > after some discussion with James I made an outline for processing > bugs on the wiki: > > Feel free to comment. In the case of hard-to-reproduce bugs, there could be a timeout on the response from the reporter. In other words, if there was a bug report which a maintainer could not reproduce and the reporter has disappeared, the bug could be closed after X amount of time. Maciej From maciej at opencsw.org Tue Sep 8 23:12:09 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 8 Sep 2009 22:12:09 +0100 Subject: [csw-maintainers] Bug resolving processess In-Reply-To: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> References: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> Message-ID: On Tue, Sep 8, 2009 at 10:01 PM, Dagobert Michelsen wrote: > after some discussion with James I made an outline for processing > bugs on the wiki: > > Feel free to comment. Point 9 looks like it could be automated. If there was a machine readable information about which version fixes the issue, a script could test mirrors for this version and mail the maintainer or even close the bug automatically. Maciej From skayser at opencsw.org Tue Sep 8 23:19:34 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 08 Sep 2009 23:19:34 +0200 Subject: [csw-maintainers] Bug resolving processess In-Reply-To: References: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> Message-ID: <4AA6CA66.5000008@opencsw.org> Maciej (Matchek) Blizinski wrote on 08.09.2009 23:12: > On Tue, Sep 8, 2009 at 10:01 PM, Dagobert Michelsen wrote: >> after some discussion with James I made an outline for processing >> bugs on the wiki: >> >> Feel free to comment. > > Point 9 looks like it could be automated. If there was a machine > readable information about which version fixes the issue, a script > could test mirrors for this version and mail the maintainer or even > close the bug automatically. Or the maintainer could submit that information (think "Closes #XXXX") along with the new package in a machine readable format. The release manager could then hook this into the release process and have it close the bug automatically on package release. Sebastian From bonivart at opencsw.org Tue Sep 8 23:45:38 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 8 Sep 2009 23:45:38 +0200 Subject: [csw-maintainers] Bug resolving processess In-Reply-To: <4AA6CA66.5000008@opencsw.org> References: <7B06F6CF-7574-46F3-9DB3-EFA4C4506041@opencsw.org> <4AA6CA66.5000008@opencsw.org> Message-ID: <625385e30909081445o6316e82dtbdc155924109461c@mail.gmail.com> On Tue, Sep 8, 2009 at 11:19 PM, Sebastian Kayser wrote: >> Point 9 looks like it could be automated. If there was a machine >> readable information about which version fixes the issue, a script >> could test mirrors for this version and mail the maintainer or even >> close the bug automatically. > > Or the maintainer could submit that information (think "Closes #XXXX") > along with the new package in a machine readable format. The release > manager could then hook this into the release process and have it close > the bug automatically on package release. I'm all for automation but in this case it seems it saves very little time and effort. Compared to the process of fixing the bug, testing the solution, releasing a new package a couple of clicks is nothing. The only real benefit I see is that we don't forget to close bugs but we already get weekly reminders so... -- /peter From maciej at opencsw.org Wed Sep 9 10:39:10 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 09:39:10 +0100 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) Message-ID: I've spent some more time on tightvnc. There was a response from their mailing list, perhaps I'll get some help there. I'm currently trying to build it the simplest way possible, just to get it to build, and then gradually tidy it up. I'm using a short shell script. It currently fails with: gmake[3]: Leaving directory `/home/maciej/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc' LD_RUN_PATH=/usr/openwin/lib /opt/studio/SOS12/SUNWspro/bin/cc -o Xvnc -xO3 -Xa -L/opt/csw/lib -L../.././/exports/lib dix/libdix.a os/libos.a ../.././/lib/Xau/libXau.a ../.././/lib/Xdmcp/libXdmcp.a ../.././/exports/lib/libfont.a hw/vnc/libvnc.a ../.././/../libvncauth/libvncauth.a cfb/libcfb.a cfb16/libcfb.a cfb24/libcfb.a cfb32/libcfb.a mfb/libmfb.a dix/libxpstubs.a mi/libmi.a Xext/libext.a -lsocket -lnsl -lm -L/usr/local/lib -ljpeg -lz -lcrypt Undefined first referenced symbol in file ffsl os/libos.a(WaitFor.o) ld: fatal: Symbol referencing errors. No output written to Xvnc gmake[2]: *** [Xvnc] Error 1 The libos.a library in fact refers to the ffsl symbol: maciej at netra ~/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver $ nm os/libos.a | grep ffsl [51] | 0| 0|FUNC |GLOB |0 |UNDEF |ffsl [91] | 0| 0|FUNC |GLOB |0 |UNDEF |ffsl [51] | 0| 0|FUNC |GLOB |0 |UNDEF |ffsl ...and libdix.a contains it: maciej at netra ~/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver $ nm dix/libdix.a | grep ffsl dix/libdix.a[ffsl.o]: [9] | 16| 72|FUNC |GLOB |0 |2 |ffsl [1] | 0| 0|FILE |LOCL |0 |ABS |ffsl.c The script and its output: http://netra.chopin.edu.pl/~maciej/tightvnc/tightvnc-1.3.10-20090909-095450-build.sh.txt http://netra.chopin.edu.pl/~maciej/tightvnc/tightvnc-1.3.10-20090909-095450.log I find it strange that it doesn't find this symbol, because dix/libdix.a is present in the cc invocation (see above). Do you have any ideas what might be the problem? Maciej From skayser at opencsw.org Wed Sep 9 11:05:46 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 09 Sep 2009 11:05:46 +0200 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: References: Message-ID: <4AA76FEA.1060408@opencsw.org> Maciej (Matchek) Blizinski wrote on 09.09.2009 10:39: > I've spent some more time on tightvnc. There was a response from their > mailing list, perhaps I'll get some help there. I'm currently trying > to build it the simplest way possible, just to get it to build, and > then gradually tidy it up. I'm using a short shell script. It > currently fails with: > > gmake[3]: Leaving directory > `/home/maciej/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc' > LD_RUN_PATH=/usr/openwin/lib /opt/studio/SOS12/SUNWspro/bin/cc -o Xvnc > -xO3 -Xa -L/opt/csw/lib -L../.././/exports/lib dix/libdix.a > os/libos.a ../.././/lib/Xau/libXau.a ../.././/lib/Xdmcp/libXdmcp.a > ../.././/exports/lib/libfont.a hw/vnc/libvnc.a > ../.././/../libvncauth/libvncauth.a cfb/libcfb.a cfb16/libcfb.a > cfb24/libcfb.a cfb32/libcfb.a mfb/libmfb.a dix/libxpstubs.a mi/libmi.a > Xext/libext.a -lsocket -lnsl -lm -L/usr/local/lib > -ljpeg -lz -lcrypt > Undefined first referenced > symbol in file > ffsl os/libos.a(WaitFor.o) > ld: fatal: Symbol referencing errors. No output written to Xvnc > gmake[2]: *** [Xvnc] Error 1 > > The libos.a library in fact refers to the ffsl symbol: > > maciej at netra ~/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver $ nm > os/libos.a | grep ffsl > [51] | 0| 0|FUNC |GLOB |0 |UNDEF |ffsl > [91] | 0| 0|FUNC |GLOB |0 |UNDEF |ffsl > [51] | 0| 0|FUNC |GLOB |0 |UNDEF |ffsl > > ...and libdix.a contains it: > > maciej at netra ~/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver $ nm > dix/libdix.a | grep ffsl > dix/libdix.a[ffsl.o]: > [9] | 16| 72|FUNC |GLOB |0 |2 |ffsl > [1] | 0| 0|FILE |LOCL |0 |ABS |ffsl.c > > The script and its output: > http://netra.chopin.edu.pl/~maciej/tightvnc/tightvnc-1.3.10-20090909-095450-build.sh.txt > http://netra.chopin.edu.pl/~maciej/tightvnc/tightvnc-1.3.10-20090909-095450.log > > I find it strange that it doesn't find this symbol, because > dix/libdix.a is present in the cc invocation (see above). Do you have > any ideas what might be the problem? AFAIR symbol resolution during the link phase takes place _once_ from left to right, where symbol references come first and symbol definitions need to be placed on the right hand side. >From ld(1): Archives are traditionally specified at the end of the command line so that their symbol definitions resolve any preceding references. However, specifying archives multiple times to satisfy their own interdependencies, can be neces- sary. Above, dix/libdix.a (symbol definition) comes before os/libos.a (symbol reference). Does it make a difference when add another dix/libdix.a _after_ os/libos.a? Sebastian From maciej at opencsw.org Wed Sep 9 11:26:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 10:26:01 +0100 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: <4AA76FEA.1060408@opencsw.org> References: <4AA76FEA.1060408@opencsw.org> Message-ID: On Wed, Sep 9, 2009 at 10:05 AM, Sebastian Kayser wrote: > Maciej (Matchek) Blizinski wrote on 09.09.2009 10:39: >> I find it strange that it doesn't find this symbol, because >> dix/libdix.a is present in the cc invocation (see above). Do you have >> any ideas what might be the problem? > > AFAIR symbol resolution during the link phase takes place _once_ from > left to right, where symbol references come first and symbol definitions > need to be placed on the right hand side. > > >From ld(1): > > Archives are > traditionally specified at the end of the command line > so that their symbol definitions resolve any preceding > references. However, specifying archives multiple times > to satisfy their own interdependencies, can be neces- > sary. > > Above, dix/libdix.a (symbol definition) comes before os/libos.a (symbol > reference). Does it make a difference when add another dix/libdix.a > _after_ os/libos.a? maciej at netra ~/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver $ LD_RUN_PATH=/usr/openwin/lib /opt/studio/SOS12/SUNWspro/bin/cc -o Xvnc -xO3 -Xa -L/opt/csw/lib -L../.././/exports/lib dix/libdix.a os/libos.a dix/libdix.a ../.././/lib/Xau/libXau.a ../.././/lib/Xdmcp/libXdmcp.a ../.././/exports/lib/libfont.a hw/vnc/libvnc.a ../.././/../libvncauth/libvncauth.a cfb/libcfb.a cfb16/libcfb.a cfb24/libcfb.a cfb32/libcfb.a mfb/libmfb.a dix/libxpstubs.a mi/libmi.a Xext/libext.a -lsocket -lnsl -lm -L/usr/local/lib -ljpeg -lz -lcrypt maciej at netra ~/src/vnc-nongar/vnc_unixsrc/Xvnc/programs/Xserver $ Wow, it worked! Thanks! Maciej From dam at opencsw.org Wed Sep 9 11:31:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Sep 2009 11:31:45 +0200 Subject: [csw-maintainers] Updating all farm servers to current/ Message-ID: Hi, I am updating all build servers to current now. Please stand by. Sorry for the inconvenience -- Dago From maciej at opencsw.org Wed Sep 9 14:56:45 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 13:56:45 +0100 Subject: [csw-maintainers] Using package overlay with UNCOMMITTED packages Message-ID: I'm currently developing a workflow for building and testing packages at work. I'm using pkgutil's package overlay support with "-t". The current problem I see is that if a package has UNCOMMITTED status, pkgutil doesn't install it. I can (non-)solve this by committing every change before building. Otherwise, I perhaps could stop GAR from appending UNCOMMITTED, or make pkgutil accept them. Which one do you think is best? Maciej From dam at opencsw.org Wed Sep 9 15:18:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Sep 2009 15:18:22 +0200 Subject: [csw-maintainers] Using package overlay with UNCOMMITTED packages In-Reply-To: References: Message-ID: <1A0ADE92-E692-4B22-92D2-8114993702EF@opencsw.org> Hi Maciej, Am 09.09.2009 um 14:56 schrieb Maciej (Matchek) Blizinski: > I'm currently developing a workflow for building and testing packages > at work. I'm using pkgutil's package overlay support with "-t". The > current problem I see is that if a package has UNCOMMITTED status, > pkgutil doesn't install it. I can (non-)solve this by committing every > change before building. Otherwise, I perhaps could stop GAR from > appending UNCOMMITTED, or make pkgutil accept them. Which one do you > think is best? It is not related to pkgutil as my catalog generation tool skips files with UNCOMMITTED in them. If we consider it generally ok to have those packages in testing I can change that and include them in the catalog. I'll write something up as it is related to the new release process we have been talking about in Oslo. Best regards -- Dago From skayser at opencsw.org Wed Sep 9 15:23:24 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 09 Sep 2009 15:23:24 +0200 Subject: [csw-maintainers] Using package overlay with UNCOMMITTED packages In-Reply-To: <1A0ADE92-E692-4B22-92D2-8114993702EF@opencsw.org> References: <1A0ADE92-E692-4B22-92D2-8114993702EF@opencsw.org> Message-ID: <4AA7AC4C.6050100@opencsw.org> Dagobert Michelsen wrote on 09.09.2009 15:18: > Am 09.09.2009 um 14:56 schrieb Maciej (Matchek) Blizinski: >> I'm currently developing a workflow for building and testing packages >> at work. I'm using pkgutil's package overlay support with "-t". The >> current problem I see is that if a package has UNCOMMITTED status, >> pkgutil doesn't install it. I can (non-)solve this by committing every >> change before building. Otherwise, I perhaps could stop GAR from >> appending UNCOMMITTED, or make pkgutil accept them. Which one do you >> think is best? > > It is not related to pkgutil as my catalog generation tool skips > files with UNCOMMITTED in them. If we consider it generally ok to > have those packages in testing I can change that and include them > in the catalog. Sounds like something that should rather go into "experimental". Would be nice to get testing a bit more stable so that users can test stuff in there without hosing their system. Sebastian From maciej at opencsw.org Wed Sep 9 16:01:45 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 15:01:45 +0100 Subject: [csw-maintainers] Using package overlay with UNCOMMITTED packages In-Reply-To: <4AA7AC4C.6050100@opencsw.org> References: <1A0ADE92-E692-4B22-92D2-8114993702EF@opencsw.org> <4AA7AC4C.6050100@opencsw.org> Message-ID: On Wed, Sep 9, 2009 at 2:23 PM, Sebastian Kayser wrote: >> It is not related to pkgutil as my catalog generation tool skips >> files with UNCOMMITTED in them. If we consider it generally ok to >> have those packages in testing I can change that and include them >> in the catalog. > > Sounds like something that should rather go into "experimental". Would > be nice to get testing a bit more stable so that users can test stuff in > there without hosing their system. Maybe this could be an option to bldcat: --experimental or --include-uncommitted, or something similar. Maciej From dam at opencsw.org Wed Sep 9 16:15:54 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Sep 2009 16:15:54 +0200 Subject: [csw-maintainers] Using package overlay with UNCOMMITTED packages In-Reply-To: References: <1A0ADE92-E692-4B22-92D2-8114993702EF@opencsw.org> <4AA7AC4C.6050100@opencsw.org> Message-ID: <851E90D7-B2FD-427C-8CDF-BC1220E26974@opencsw.org> Hi Maciej, Am 09.09.2009 um 16:01 schrieb Maciej (Matchek) Blizinski: > On Wed, Sep 9, 2009 at 2:23 PM, Sebastian > Kayser wrote: >>> It is not related to pkgutil as my catalog generation tool skips >>> files with UNCOMMITTED in them. If we consider it generally ok to >>> have those packages in testing I can change that and include them >>> in the catalog. >> >> Sounds like something that should rather go into "experimental". >> Would >> be nice to get testing a bit more stable so that users can test >> stuff in >> there without hosing their system. > > Maybe this could be an option to bldcat: --experimental or > --include-uncommitted, or something similar. Ok, maybe I didn't make that clear: It is my tool linking packages to the subdir where the catalog is made. bldcat just takes everything in there and adds it to the catalog, the files are just linked in there. Best regards -- Dago From maciej at opencsw.org Wed Sep 9 17:32:28 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 16:32:28 +0100 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: References: <4AA76FEA.1060408@opencsw.org> Message-ID: Dago, I could get it to build, but only when I didn't use the USE_LIBWRAP bit. Here's a change that builds on Solaris 10 with SOS12 for me: http://sourceforge.net/apps/trac/gar/changeset/6245 I'll now test it on the buildfarm. Can you tell me why USE_LIBWRAP and is it important that it's being used? Maciej From bwalton at opencsw.org Wed Sep 9 17:37:03 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Sep 2009 11:37:03 -0400 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: References: <4AA76FEA.1060408@opencsw.org> Message-ID: <1252510559-sup-591@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Sep 09 11:32:28 -0400 2009: > Can you tell me why USE_LIBWRAP and is it important that it's being used? If the old package was using libwrap, it's fairly important for the update to use it also. Users would need a BIG BOLD notice if this behaviour changed since they may be relying on that security layer. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Wed Sep 9 17:44:59 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Sep 2009 17:44:59 +0200 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: References: <4AA76FEA.1060408@opencsw.org> Message-ID: <21CC7EA2-B1FB-4079-A8F7-177C4F60C608@opencsw.org> Hi Maciej, Am 09.09.2009 um 17:32 schrieb Maciej (Matchek) Blizinski: > Dago, I could get it to build, but only when I didn't use the > USE_LIBWRAP bit. Here's a change that builds on Solaris 10 with SOS12 > for me: > > http://sourceforge.net/apps/trac/gar/changeset/6245 > > I'll now test it on the buildfarm. > > Can you tell me why USE_LIBWRAP and is it important that it's being > used? That is TCPWrappers, allowing to restrict access to the port centrally to certain IP-adresses or ranges. Where is the problem? The tcpwrappers version we have is current (7.6), but without 64 bit libraries. Phil: Do you mind pushing the build notes so I can get it into GAR with 64 bit libs? Best regards -- Dago From maciej at opencsw.org Wed Sep 9 18:16:24 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 17:16:24 +0100 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: <21CC7EA2-B1FB-4079-A8F7-177C4F60C608@opencsw.org> References: <4AA76FEA.1060408@opencsw.org> <21CC7EA2-B1FB-4079-A8F7-177C4F60C608@opencsw.org> Message-ID: On Wed, Sep 9, 2009 at 4:44 PM, Dagobert Michelsen wrote: > That is TCPWrappers, allowing to restrict access to the port > centrally to certain IP-adresses or ranges. Where is the problem? /usr/ccs/bin/ar cq libvnc.a init.o sockets.o kbdptr.o cmap.o draw.o cutpaste.o dispcur.o sprite.o rfbserver.o translate.o httpd.o auth.o rre.o corre.o stats.o hextile.o zlib.o tight.o cursor.o gmake[5]: Leaving directory `/home/maciej/src/opencsw/pkg/tightvnc/trunk/work/build-isa-sparcv8/vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc' LD_RUN_PATH=/usr/openwin/lib /opt/studio/SOS11/SUNWspro/bin/cc -o Xvnc -xO3 -Xa -L/opt/csw/lib -L../.././/exports/lib dix/libdix.a os/libos.a ../.././/lib/Xau/libXau.a ../.././/lib/Xdmcp/libXdmcp.a dix/libdix.a ../.././/exports/lib/libfont.a hw/vnc/libvnc.a ../.././/../libvncauth/libvncauth.a cfb/libcfb.a cfb16/libcfb.a cfb24/libcfb.a cfb32/libcfb.a mfb/libmfb.a dix/libxpstubs.a mi/libmi.a Xext/libext.a -lsocket -lnsl -lm -L/usr/local/lib -ljpeg -lz -lcrypt Undefined first referenced symbol in file hosts_ctl hw/vnc/libvnc.a(sockets.o) ld: fatal: Symbol referencing errors. No output written to Xvnc gmake[4]: *** [Xvnc] Error 1 The build ignores the EXTRA_LIBRARIES variable. It's present in the generated Makefile, but set to something different that what's in the GAR Makefile. Maciej From bwalton at opencsw.org Wed Sep 9 18:34:28 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Sep 2009 12:34:28 -0400 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: References: <4AA76FEA.1060408@opencsw.org> <21CC7EA2-B1FB-4079-A8F7-177C4F60C608@opencsw.org> Message-ID: <1252514027-sup-683@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Sep 09 12:16:24 -0400 2009: > The build ignores the EXTRA_LIBRARIES variable. It's present in the > generated Makefile, but set to something different that what's in the > GAR Makefile. So you're adding -lwrap (or whatever the format is) to EXTRA_LIBRARIES and it's completely ignoring it? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Wed Sep 9 18:49:50 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 17:49:50 +0100 Subject: [csw-maintainers] Building tightvnc (was: Can't run Sun Studio in vncserver) In-Reply-To: <1252514027-sup-683@ntdws12.chass.utoronto.ca> References: <4AA76FEA.1060408@opencsw.org> <21CC7EA2-B1FB-4079-A8F7-177C4F60C608@opencsw.org> <1252514027-sup-683@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Sep 9, 2009 at 5:34 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Wed Sep 09 12:16:24 -0400 2009: > >> The build ignores the EXTRA_LIBRARIES variable. It's present in the >> generated Makefile, but set to something different that what's in the >> GAR Makefile. > > So you're adding -lwrap (or whatever the format is) to EXTRA_LIBRARIES > and it's completely ignoring it? Yes. Tired of being a gentleman with this build, I took a big hammer and forced -lwrap down its throat: diff --git a/Xvnc/config/cf/vnclibs.def b/Xvnc/config/cf/vnclibs.def index c033ca7..948fd7a 100644 --- a/Xvnc/config/cf/vnclibs.def +++ b/Xvnc/config/cf/vnclibs.def @@ -11,7 +11,7 @@ VNCLIBS = $(TOP)/../libvncauth/libvncauth.a /* Avoid linking with different libjpeg in /usr/shlib under Tru64. */ VNCSYSLIBS = /usr/local/lib/libjpeg.a /usr/local/lib/libz.a -lcrypt #else -VNCSYSLIBS = -L/usr/local/lib -ljpeg -lz -lcrypt +VNCSYSLIBS = -L/usr/local/lib -ljpeg -lz -lcrypt -lwrap #endif VNCCPPFLAGS = -I$(TOP)/../include -I/usr/local/include -- 1.6.3.2 It builds now! Maciej From maciej at opencsw.org Wed Sep 9 21:15:33 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 20:15:33 +0100 Subject: [csw-maintainers] Can't run Sun Studio in vncserver In-Reply-To: <200909070841.n878fPOX017084@dfki.uni-kl.de> References: <200909070841.n878fPOX017084@dfki.uni-kl.de> Message-ID: I've just successfully built tightvnc-1.3.10. It passed the smoke test, including running Sun Studio in it -- it works! The binaries are available in testing. Enjoy! Maciej From maciej at opencsw.org Wed Sep 9 21:18:41 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 20:18:41 +0100 Subject: [csw-maintainers] Basic X fonts from OpenCSW Message-ID: When one installs vncserver from OpenCSW and tries to run it, one gets: $ vncserver :1 Couldn't start Xvnc; trying default font path. Please set correct fontPath in the vncserver script. How about providing a dependency -- a package with basic X fonts? Has anyone here tried that yet? Maciej From maciej at opencsw.org Wed Sep 9 21:35:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Sep 2009 20:35:39 +0100 Subject: [csw-maintainers] Builds that are difficult on Solaris 8 Message-ID: Some builds are more difficult on Solaris 8 than others. For instance, pinentry contains code which doesn't compile with SOS11. I could probably fix it, but I'm not really willing to spend more time re-writing bits of code to compile there, but there are thing I feel are more important to me than that. What's the best way of going about it? Is it okay to build and release Solaris 10-only packages? (I mean small things like pinentry, that is.) Maciej From bwalton at opencsw.org Wed Sep 9 21:46:46 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Sep 2009 15:46:46 -0400 Subject: [csw-maintainers] Builds that are difficult on Solaris 8 In-Reply-To: References: Message-ID: <1252525541-sup-901@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Sep 09 15:35:39 -0400 2009: > it? Is it okay to build and release Solaris 10-only packages? (I mean > small things like pinentry, that is.) Don't forget about solaris 9! :) Also, if the build would go with gcc on solaris 8, that's still a better option[1], imo. -Ben [1] Says the guy who still has solaris 8 boxes using the CSW stack in production... :( -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ihsan at dogan.ch Thu Sep 10 09:07:27 2009 From: ihsan at dogan.ch (Ihsan Dogan) Date: Thu, 10 Sep 2009 09:07:27 +0200 Subject: [csw-maintainers] Oracle Says ... Message-ID: <4AA8A5AF.6010807@dogan.ch> http://www.oracle.com/features/suncustomers.html -- ihsan at dogan.ch http://blog.dogan.ch/ From daniel at opencsw.org Thu Sep 10 19:26:27 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 10 Sep 2009 18:26:27 +0100 Subject: [csw-maintainers] Ganglia update In-Reply-To: <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> Message-ID: <4AA936C3.1090002@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 05.09.2009 um 01:26 schrieb Daniel Pocock: >> One other thing that caused some issues, I tried adding these lines: >> >> ARCHALL_CSWgangliadevel = 1 >> ARCHALL_CSWgangliaweb = 1 >> >> but when it gets to the install-custom code, it looks for files in >> the wrong place, specifically: >> >> @cd $(WORKSRC)/web; \ >> cp -R * $(DESTDIR)$(WWWGANGLIA) >> >> and the other lines referencing $(WORKSRC) look in the wrong place. >> Any hints would be welcome. > > Theoretically this can't happen as ARCHALL_* only changes the gspec > file. However, > I would like to reproduce it, but libconfuse has neither been released > nor is it > in testing/. Please build it so I can install it on build8st and > retry. There is > also no harm in releasing libconfuse as it is a new library. Phil has accepted it, but I notice errors about mantis on the package page: http://www.opencsw.org/packages/libconfuse "Err: cannot find maintainer for libconfuse in mantis." I've tried creating an account for myself in Mantis using the same email address that I included in the package, but the error remains. Not sure how long it takes to appear in the mirrors, or is there anything else I need to do before that happens? From maciej at opencsw.org Thu Sep 10 20:41:14 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Sep 2009 19:41:14 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: After considering all the options, I wrote an example implementation[1] of the one that does symlinks, and used it for the unixodbc package. Trygvis had objected to putting it into testing, and then disappeared in a black hole. I pulled the package from testing; moved it into a subdirectory. Meanwhile, there is more and more packages that are being held back by this issue, notably, there are cups and tightvnc. Let's get it sorted out and move forward! The issue isn't entirely new, one might point out. There are packages which already migrate their configuration files[2]. The case currently discussed isn't as simple though, because it's a migration from a single shared configuration instance into many per-zone configuration instances. There is a number of options discussed on the wiki page[3]. I'd like to ask if people have any other options to offer. There another case to consider: the case when the configuration files can't be automatically migrated. Should the preinstall script abort the installation? (Can it really abort the installation?) Any other ideas? At the end of the discussion, I'd be happy if we had a canonical implementation of the migration; possibly using a common script, put into cswclassutils. Please respond to the mailing list, and I'll update the wiki page. Maciej [1] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/unixodbc/trunk/files/CSWunixodbc.postinstall [2] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/phpldapadmin/trunk/files/CSWphpldapadmin.preinstall [3] http://opencsw.wikidot.com/configuration-directory-migration From phil at bolthole.com Thu Sep 10 21:49:16 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Sep 2009 12:49:16 -0700 Subject: [csw-maintainers] Oracle Says ... In-Reply-To: <4AA8A5AF.6010807@dogan.ch> References: <4AA8A5AF.6010807@dogan.ch> Message-ID: Would have been nice to have a summary, Ihsan ;-) Nice pointer though. summary: oracle plans to double sun's previous spending on hardware dev, AND solaris dev. "we're in it to win it", Larry Ellison says. interesting. On Thu, Sep 10, 2009 at 12:07 AM, Ihsan Dogan wrote: > http://www.oracle.com/features/suncustomers.html > > -- From phil at bolthole.com Thu Sep 10 21:50:41 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Sep 2009 12:50:41 -0700 Subject: [csw-maintainers] Builds that are difficult on Solaris 8 In-Reply-To: References: Message-ID: On Wed, Sep 9, 2009 at 12:35 PM, Maciej (Matchek) Blizinski wrote: > Some builds are more difficult on Solaris 8 than others. For instance, > pinentry contains code which doesn't compile with SOS11. I could > probably fix it, but I'm not really willing to spend more time > re-writing bits of code to compile there, but there are thing I feel > are more important to me than that. What's the best way of going about > it? I think that it is ALWAYS a good idea, when you feel stumped/overwhelmed yourself, to post your specific errors encountered to the maint list. Your own "impossible block" problem, may be someone else's "been there done that". From bwalton at opencsw.org Thu Sep 10 21:55:16 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 10 Sep 2009 15:55:16 -0400 Subject: [csw-maintainers] Oracle Says ... In-Reply-To: References: <4AA8A5AF.6010807@dogan.ch> Message-ID: <1252612402-sup-9351@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Sep 10 15:49:16 -0400 2009: > summary: oracle plans to double sun's previous spending on hardware > dev, AND solaris dev. SPARC dev, not just hardware, which could be taken to mean their x86 server engineering. It'll be interesting to watch, for sure. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Thu Sep 10 21:55:31 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Sep 2009 12:55:31 -0700 Subject: [csw-maintainers] Ganglia update In-Reply-To: <4AA936C3.1090002@opencsw.org> References: <4AA179B4.3010001@opencsw.org> <4AA1A218.90709@opencsw.org> <1063F7C6-F4D1-4B59-82F1-BAE4C58DAC8E@opencsw.org> <4AA936C3.1090002@opencsw.org> Message-ID: On Thu, Sep 10, 2009 at 10:26 AM, Daniel Pocock wrote: > > I've tried creating an account for myself in Mantis using the same email > address that I included in the package, but the error remains. > > Not sure how long it takes to appear in the mirrors, or is there anything > else I need to do before that happens? > arg. ok, bumped things. From maciej at opencsw.org Fri Sep 11 00:13:57 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Sep 2009 23:13:57 +0100 Subject: [csw-maintainers] Pinentry compilation problem Message-ID: I'm trying to compile pinentry with SOS11 on Solaris 8. I'm getting the following error: gmake[4]: Entering directory `/home/maciej/src/opencsw/pkg/pinentry/trunk/work/build-isa-sparcv8/pinentry-0.7.6/secmem' source='secmem.c' object='secmem.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../depcomp \ /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I.. -I/opt/csw/X11/include -I/opt/csw/include -xO3 -xarch=v8 -I/opt/csw/X11/include -I/opt/csw/include -c secmem.c source='util.c' object='util.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../depcomp \ /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I.. -I/opt/csw/X11/include -I/opt/csw/include -xO3 -xarch=v8 -I/opt/csw/X11/include -I/opt/csw/include -c util.c "util.c", line 57: syntax error before or at: { "util.c", line 57: undefined symbol: __result "util.c", line 57: undefined symbol: __result "util.c", line 57: undefined symbol: __result "util.c", line 57: syntax error before or at: ) "util.c", line 58: warning: syntax error: empty declaration "util.c", line 59: cannot recover from previous errors cc: acomp failed for util.c gmake[4]: *** [util.o] Error 2 The place in the code that causes the problem is: #ifndef TEMP_FAILURE_RETRY #define TEMP_FAILURE_RETRY(expression) \ ( \ ({ long int __result; \ do __result = (long int) (expression); \ while (__result == -1L && errno == EINTR); \ __result; })) #endif With SOS12, this code compiles just fine. Any ideas? Maciej From james at opencsw.org Fri Sep 11 10:41:28 2009 From: james at opencsw.org (James Lee) Date: Fri, 11 Sep 2009 08:41:28 GMT Subject: [csw-maintainers] Pinentry compilation problem In-Reply-To: References: Message-ID: <20090911.8412800.3475687791@gyor.oxdrove.co.uk> On 10/09/09, 23:13:57, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] Pinentry compilation problem: > "util.c", line 57: syntax error before or at: { > "util.c", line 57: undefined symbol: __result > "util.c", line 57: undefined symbol: __result > "util.c", line 57: undefined symbol: __result > "util.c", line 57: syntax error before or at: ) > "util.c", line 58: warning: syntax error: empty declaration > "util.c", line 59: cannot recover from previous errors > cc: acomp failed for util.c > gmake[4]: *** [util.o] Error 2 > The place in the code that causes the problem is: > #ifndef TEMP_FAILURE_RETRY > #define TEMP_FAILURE_RETRY(expression) \ > ( \ > ({ long int __result; \ > do __result = (long int) (expression); \ > while (__result == -1L && errno == EINTR); \ > __result; })) > #endif It's so nasty it deserves to fail anyway but let's look at the syntax. It condenses to: answer = ( { 1; 2; } ); in the hope that answer is assigned to 2. I'd object to it and it isn't valid in Java either. Try passing the lvalue to the macro and using like a void function: #define TEMP_FAILURE_RETRY(result, expression) \ { long int __result; \ do __result = (long int) (expression); \ while (__result == -1L && errno == EINTR); \ result = __result; } #endif Or rewrite as a function, this might not be work depending on the values used for expression: long int TEMP_FAILURE_RETRY(long int (*expression)(void)) { long int __result; do __result = (long int) (expression); while (__result == -1L && errno == EINTR); return __result; } Clean up: long int TEMP_FAILURE_RETRY(long int (*expression)(void)) { long int result; while ((result = (long int) (expression)) == -1L && errno == EINTR); return result; } James. From james at opencsw.org Fri Sep 11 10:51:04 2009 From: james at opencsw.org (James Lee) Date: Fri, 11 Sep 2009 08:51:04 GMT Subject: [csw-maintainers] Pinentry compilation problem In-Reply-To: <20090911.8412800.3475687791@gyor.oxdrove.co.uk> References: <20090911.8412800.3475687791@gyor.oxdrove.co.uk> Message-ID: <20090911.8510400.1335098705@gyor.oxdrove.co.uk> On 11/09/09, 09:41:28, James Lee wrote regarding Re: [csw-maintainers] Pinentry compilation problem: I really should try things before emailing :-) it's been too long since I wrote any pointer to functions. long int TEMP_FAILURE_RETRY(long int (*expression)(void)) { long int __result; do __result = expression(); while (__result == -1L && errno == EINTR); return __result; } Clean up: long int TEMP_FAILURE_RETRY(long int (*expression)(void)) { long int result; while ((result = expression()) == -1L && errno == EINTR); return result; } That looks better - but I've still not tried it. James. From dam at opencsw.org Fri Sep 11 12:02:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 11 Sep 2009 12:02:13 +0200 Subject: [csw-maintainers] Release of updated cairo In-Reply-To: <4AAA1F2F.30806@pocock.com.au> References: <4AA522F3.6070903@pocock.com.au> <9D68CA91-DBC1-4756-B90F-007E2122F831@opencsw.org> <4AA56225.1050307@pocock.com.au> <6130367B-C3FE-49B3-81B0-B3850DBAC572@opencsw.org> <4AAA1B8B.7030700@pocock.com.au> <60378F51-D464-46B7-8A85-16B771E6D104@opencsw.org> <4AAA1F2F.30806@pocock.com.au> Message-ID: Hi, Am 11.09.2009 um 11:58 schrieb Daniel Pocock: > Dagobert Michelsen wrote: >> Hi Daniel, >> >> Am 11.09.2009 um 11:42 schrieb Daniel Pocock: >>> I also need the rrdtool package on all the build machines so I can >>> build my packages. >> >> ?? rrdtool is already on all build machines, or are you missing >> something? > > Actually, you are right - rrd.h is there, it is the cairo issue John: How about releasing the updated cairo from testing? Best regards -- Dago From dam at opencsw.org Fri Sep 11 16:52:08 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 11 Sep 2009 16:52:08 +0200 Subject: [csw-maintainers] Updated OpenLDAP and other things In-Reply-To: References: <4A37FE7D.5080608@opencsw.org> Message-ID: <26D3D290-8AC5-4530-BC8B-314B0E7877FA@opencsw.org> Hi, Updated packages with the latest OpenLDAP 2.4.18 is in testing. Mike: It would be great if you could take a look at the startup scripts and do some more testing on it. The build recipe is fully committed. Dominique, Sebastian and I had a terrific day hacking at OpenLDAP and also Kerberos 1.7 is almost finished :) To anyone with spare cycles: There is *a lot* of updated stuff in testing/. Please try it out and give feedback of any kind. Best regards -- Dago From dam at opencsw.org Fri Sep 11 16:56:01 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 11 Sep 2009 16:56:01 +0200 Subject: [csw-maintainers] libconfuse and Solaris 10 version Message-ID: Hi Daniel, there are two versions of libconfuse in testing, one for Solaris 8+9 and one for Solaris 10. There is only one version synced to the mirrors: Solaris 8. Is this what you intended? Best regards -- Dago From trygvis at opencsw.org Fri Sep 11 17:11:27 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Fri, 11 Sep 2009 17:11:27 +0200 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: <4AAA689F.1030703@opencsw.org> Dagobert Michelsen wrote: > Hi Gary, > > Am 05.09.2009 um 17:48 schrieb Gary Law: >> My latest puppet package is clashing with CSWapache2c over permissions >> of /etc/opt > > CSWapache2c should not contain /etc/opt as it is already in SUNWcsr > (with root:sys 0755). > >> a) what should the permissions be? > > The path should not be included in CSW packages. /etc/opt/csw is already > in CSWcommon and should therefore also not be included (and is by > default root:bin 0755) > >> b) should we put this in CSWcommon? > > It already is amongst /var/opt/csw. See the commondirs excluded from GAR > here > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/etc > which are extracted from the CSWcommon package. (If it is a good idea > to build CSWcommon manually and derive pathes in GAR from it and not > the other way round is another discussion). These requirements sounds like something that should be implemented in checkpkg. -- Trygve From phil at bolthole.com Fri Sep 11 18:01:15 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Sep 2009 09:01:15 -0700 Subject: [csw-maintainers] Basic X fonts from OpenCSW In-Reply-To: References: Message-ID: If the system already HAS "basic X fonts", this seems rather a waste of space. We sometimes duplicate sun packages, but usually only because there is a specific benefit to it. I'm not sure there is a benefit in this case, though. It may be better to simply declare a dependancy on the SUNW basic fonts package. On Wed, Sep 9, 2009 at 12:18 PM, Maciej (Matchek) Blizinski wrote: > When one installs vncserver from OpenCSW and tries to run it, one gets: > > $ vncserver :1 > Couldn't start Xvnc; trying default font path. > Please set correct fontPath in the vncserver script. > > How about providing a dependency -- a package with basic X fonts? Has > anyone here tried that yet? > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > From phil at bolthole.com Fri Sep 11 18:04:23 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Sep 2009 09:04:23 -0700 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: Message-ID: well,, there are multiple potential "issues" at play here. on the one hand, I understand your frustration at not having it normally in the path. But what would be the side effects of having a symlink /opt/csw/bin/mysql -> /opt/csw/mysql5/bin/mysql ? Would it break auto-detection of mysql location, when compiling? and... is that ok anyway, since we dont have auto-detection now anyway? :-) It may indeed be appropriate to adjust our mysql5 package to have the symlink in there. BTW: would you be intersted in taking over our mysql package, for purposes of updating, and putting the symlink in there? (pleasepleasepleaseplease? :-) On Tue, Sep 8, 2009 at 1:33 AM, Maciej (Matchek) Blizinski wrote: > Most packages put their files in /opt/csw; but some seem to be > special, and use /opt/csw/${something}. For instance, MySQL 5 uses > /opt/csw/mysql5. I understand that it's a way of having multiple > versions of MySQL on one system at the same time, but it's somewhat > annoying to not have the mysql binaries in the PATH right after > installation. Was /opt/csw/mysql5 with a separate bin with no symlinks > from /opt/csw/bin a solution that was a result of a discussion, or was > is only because the maintainer just did it this way? > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > From phil at bolthole.com Fri Sep 11 18:22:05 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Sep 2009 09:22:05 -0700 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: On Thu, Sep 10, 2009 at 11:41 AM, Maciej (Matchek) Blizinski wrote: > > There another case to consider: the case when the configuration files > can't be automatically migrated. Should the preinstall script abort > the installation? (Can it really abort the installation?) Any other > ideas? > I did already give my own opinion on this one; yes it should stop the install. and yes it has the power to do that. simply exit with non-zero status. From phil at bolthole.com Fri Sep 11 20:11:08 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Sep 2009 11:11:08 -0700 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: On Sat, Sep 5, 2009 at 8:48 AM, Gary Law wrote: > Hi > > My latest puppet package is clashing with CSWapache2c over permissions > of /etc/opt > > a) what should the permissions be? The permissions are "none of your business" :-) neither you, nor CSWapache2c, should be setting permissions on /etc/opt itself. We do not "own" it. we do not have rights to set permissions on it. only /etc/opt/csw and below. From dam at opencsw.org Fri Sep 11 20:14:38 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 11 Sep 2009 20:14:38 +0200 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: Hi, Am 11.09.2009 um 20:11 schrieb Philip Brown: > On Sat, Sep 5, 2009 at 8:48 AM, Gary Law wrote: >> Hi >> >> My latest puppet package is clashing with CSWapache2c over >> permissions >> of /etc/opt >> >> a) what should the permissions be? > > The permissions are "none of your business" :-) > > neither you, nor CSWapache2c, should be setting permissions on > /etc/opt itself. We do not "own" it. we do not have rights to set > permissions on it. only /etc/opt/csw and below. Ok then, checkpkg could check that there are no pathes from CSWcommon in the package and no pathes "before them". Best regards -- Dago From phil at bolthole.com Fri Sep 11 20:22:57 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Sep 2009 11:22:57 -0700 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: On Fri, Sep 11, 2009 at 11:14 AM, Dagobert Michelsen wrote: > > > Ok then, checkpkg could check that there are no pathes from > CSWcommon in the package and no pathes "before them". it's kind of a pain to check for *ANY* path, considering the various permutations and "tricky stuff" people might do. there is currently a check for bare "/opt". that's the most common case. are you proposing checks for... "/opt /etc /etc/opt /var /var/opt" ? From dam at opencsw.org Fri Sep 11 20:37:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 11 Sep 2009 20:37:51 +0200 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: Hi Phil, Am 11.09.2009 um 20:22 schrieb Philip Brown: > On Fri, Sep 11, 2009 at 11:14 AM, Dagobert Michelsen > wrote: >> >> >> Ok then, checkpkg could check that there are no pathes from >> CSWcommon in the package and no pathes "before them". > > > it's kind of a pain to check for *ANY* path, considering the various > permutations and "tricky stuff" people might do. > > there is currently a check for bare "/opt". that's the most common > case. > are you proposing checks for... "/opt /etc /etc/opt /var /var/opt" ? Sure. Take all pathes in CSWcommon, generate every prefix path and check that there are none of them in there. And there must be a direct prefix of every file in the package in CSWcommon. Best regards -- Dago From phil at bolthole.com Fri Sep 11 22:59:08 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Sep 2009 13:59:08 -0700 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: On Fri, Sep 11, 2009 at 11:37 AM, Dagobert Michelsen wrote: > Hi Phil, > > Am 11.09.2009 um 20:22 schrieb Philip Brown: >> >> >> it's kind of a pain to check for *ANY* path, considering the various >> permutations and "tricky stuff" people might do. >> >> there is currently a check for bare "/opt". that's the most common case. >> are you proposing checks for... "/opt /etc /etc/opt /var /var/opt" ? > > Sure. Take all pathes in CSWcommon, generate every prefix path and check > that there are none of them in there. And there must be a direct prefix > of every file in the package in CSWcommon. > Errr.. that's not what I was saying at all. From schwindt at dfki.uni-kl.de Fri Sep 11 23:33:17 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Fri, 11 Sep 2009 23:33:17 +0200 (CEST) Subject: [csw-maintainers] libsmi in testiing Message-ID: <33062.88.134.82.77.1252704797.squirrel@www.dfki.uni-kl.de> This is 'A Library to Access SMI MIB Information' It will be needed for a new version of wireshark. Nicolai ----------------------------------------- This email was sent using SquirrelMail. "Webmail for nuts!" http://squirrelmail.org/ From trygvis at opencsw.org Sat Sep 12 07:33:26 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sat, 12 Sep 2009 07:33:26 +0200 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: <4AAB32A6.5060305@opencsw.org> Maciej (Matchek) Blizinski wrote: > After considering all the options, I wrote an example > implementation[1] of the one that does symlinks, and used it for the > unixodbc package. Trygvis had objected to putting it into testing, and > then disappeared in a black hole. I pulled the package from testing; > moved it into a subdirectory. Meanwhile, there is more and more > packages that are being held back by this issue, notably, there are > cups and tightvnc. Let's get it sorted out and move forward! > > The issue isn't entirely new, one might point out. There are packages > which already migrate their configuration files[2]. The case currently > discussed isn't as simple though, because it's a migration from a > single shared configuration instance into many per-zone configuration > instances. > > There is a number of options discussed on the wiki page[3]. I'd like > to ask if people have any other options to offer. > > There another case to consider: the case when the configuration files > can't be automatically migrated. Should the preinstall script abort > the installation? (Can it really abort the installation?) Any other > ideas? > > At the end of the discussion, I'd be happy if we had a canonical > implementation of the migration; possibly using a common script, put > into cswclassutils. > > Please respond to the mailing list, and I'll update the wiki page. As I see it there are actually two discussions going on here simultaneously: * Handling configuration files for zones and NFS environments For this point I think we need to find more examples to be able to figure out a reasonable policy. * The actual upgrade process and the physical moving of existing configuration files -- Trygve From bwalton at opencsw.org Sat Sep 12 16:01:53 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 12 Sep 2009 10:01:53 -0400 Subject: [csw-maintainers] gar default change... Message-ID: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> Hi All, I'd like to make a change to the GAR defaults that would see our recently agreed upon /opt/csw/{etc,var} -> /{etc,var}opt/csw become the norm. This would mean that any packages wanting to stay in their current locations would need to set sysconfdir, etc manually. If you're never intending to move your files these modifications would become permanent parts of your recipes. Is everyone ok with this? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Sat Sep 12 16:45:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 12 Sep 2009 16:45:49 +0200 Subject: [csw-maintainers] gar default change... In-Reply-To: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> References: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 12.09.2009 um 16:01 schrieb Ben Walton: > I'd like to make a change to the GAR defaults that would see our > recently agreed upon /opt/csw/{etc,var} -> /{etc,var}opt/csw become > the norm. This would mean that any packages wanting to stay in their > current locations would need to set sysconfdir, etc manually. If > you're never intending to move your files these modifications would > become permanent parts of your recipes. > > Is everyone ok with this? I propose something slightly different: The default of sysconfdir will be changed to /etc/opt/csw and localstatedir to /var/opt/csw. Additionally, every Makefile containing $(sysconfdir) or $(localstatedir) will get something like this in the head of the file in the same commit: # The default has been changed to /etc/opt/csw and /var/opt/csw. # Please remove the lines below after reviewing that your package still works. sysconfdir = /opt/csw/etc localstatedur = /opt/csw/var Best regards -- Dago From dam at opencsw.org Sat Sep 12 16:48:05 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 12 Sep 2009 16:48:05 +0200 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: Hi Phil, Am 11.09.2009 um 22:59 schrieb Philip Brown: > On Fri, Sep 11, 2009 at 11:37 AM, Dagobert Michelsen > wrote: >> Am 11.09.2009 um 20:22 schrieb Philip Brown: >>> it's kind of a pain to check for *ANY* path, considering the various >>> permutations and "tricky stuff" people might do. >>> >>> there is currently a check for bare "/opt". that's the most common >>> case. >>> are you proposing checks for... "/opt /etc /etc/opt /var /var/opt" ? >> >> Sure. Take all pathes in CSWcommon, generate every prefix path and >> check >> that there are none of them in there. And there must be a direct >> prefix >> of every file in the package in CSWcommon. > > Errr.. that's not what I was saying at all. What I said boils down to what you said, only that I would infer that from CSWcommon instead of hardcoding it. Best regards -- Dago From bwalton at opencsw.org Sat Sep 12 17:05:37 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 12 Sep 2009 11:05:37 -0400 Subject: [csw-maintainers] gar default change... In-Reply-To: References: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> Message-ID: <1252767797-sup-6541@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sat Sep 12 10:45:49 -0400 2009: Hi Dago, > /var/opt/csw. Additionally, every Makefile containing $(sysconfdir) > or $(localstatedir) will get something like this in the head of the > file in the same commit: > > # The default has been changed to /etc/opt/csw and /var/opt/csw. > # Please remove the lines below after reviewing that your package > # > still works. > sysconfdir = /opt/csw/etc > localstatedur = > # /opt/csw/var I like this. Do you mean every Makefile _not_ containing explicit settings for those variables though? This could potentially cause problems for packages that only override $(prefix) too... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From trygvis at opencsw.org Sat Sep 12 17:07:10 2009 From: trygvis at opencsw.org (=?UTF-8?B?VHJ5Z3ZlIExhdWdzdMO4bA==?=) Date: Sat, 12 Sep 2009 17:07:10 +0200 Subject: [csw-maintainers] gar default change... In-Reply-To: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> References: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> Message-ID: <4AABB91E.4090208@opencsw.org> Ben Walton wrote: > Hi All, > > I'd like to make a change to the GAR defaults that would see our > recently agreed upon /opt/csw/{etc,var} -> /{etc,var}opt/csw become > the norm. This would mean that any packages wanting to stay in their > current locations would need to set sysconfdir, etc manually. If > you're never intending to move your files these modifications would > become permanent parts of your recipes. > > Is everyone ok with this? +1 -- Trygve From william at wbonnet.net Sat Sep 12 23:25:51 2009 From: william at wbonnet.net (William Bonnet) Date: Sat, 12 Sep 2009 23:25:51 +0200 Subject: [csw-maintainers] [security-notice] Firefox 3.0.14 is available Message-ID: <4AAC11DF.6030600@wbonnet.net> Hi, Several vulnerabilities have been fixed by the latest version of Firefox 3.0 ( 3.0.14 ). This version is a security release, and will be in current in a version short time, and is right now available from testing. . http://mirror.opencsw.org/testing/firefox-3.0.14,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz . http://mirror.opencsw.org/testing/firefox-3.0.14,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz The list of fixed vulnerabilities is available from here : http://www.mozilla.org/security/known-vulnerabilities/firefox30.html Fixed in Firefox 3.0.14 MFSA 2009-51 Chrome privilege escalation with FeedWriter MFSA 2009-50 Location bar spoofing via tall line-height Unicode characters MFSA 2009-49 TreeColumns dangling pointer vulnerability MFSA 2009-48 Insufficient warning for PKCS11 module installation and removal MFSA 2009-47 Crashes with evidence of memory corruption (rv:1.9.1.3/1.9.0.14) cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From dam at opencsw.org Sun Sep 13 22:11:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 13 Sep 2009 22:11:17 +0200 Subject: [csw-maintainers] gar default change... In-Reply-To: <1252767797-sup-6541@ntdws12.chass.utoronto.ca> References: <1252763844-sup-1748@ntdws12.chass.utoronto.ca> <1252767797-sup-6541@ntdws12.chass.utoronto.ca> Message-ID: <60DF8571-9660-4975-AD7C-8D9F13F8C46B@opencsw.org> Hi Ben, Am 12.09.2009 um 17:05 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Sat Sep 12 10:45:49 > -0400 2009: > > Hi Dago, > >> /var/opt/csw. Additionally, every Makefile containing $(sysconfdir) >> or $(localstatedir) will get something like this in the head of the >> file in the same commit: >> >> # The default has been changed to /etc/opt/csw and /var/opt/csw. >> # Please remove the lines below after reviewing that your package >> # > still works. > sysconfdir = /opt/csw/etc > localstatedur = >> # /opt/csw/var > > I like this. Do you mean every Makefile _not_ containing explicit > settings for those variables though? This could potentially cause > problems for packages that only override $(prefix) too... Ok, so it would be safest to add the header and existing default to *every* Makefile to ensure the issue has been looked at when the package is next reviewed. Better safe and remove some lines then get strange effects after release. Thoughts? Best regards -- Dago From dam at opencsw.org Sun Sep 13 22:16:47 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 13 Sep 2009 22:16:47 +0200 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: Hi Phil, Am 11.09.2009 um 18:22 schrieb Philip Brown: > On Thu, Sep 10, 2009 at 11:41 AM, Maciej (Matchek) Blizinski > wrote: >> >> There another case to consider: the case when the configuration files >> can't be automatically migrated. Should the preinstall script abort >> the installation? (Can it really abort the installation?) Any other >> ideas? > > I did already give my own opinion on this one; yes it should stop the > install. and yes it has the power to do that. simply exit with > non-zero status. Let me remind you that this is contrary to what you advised me on transitioning Mantis: Am 21.03.2008 um 22:08 schrieb Philip Brown: > On Fri, Mar 21, 2008 at 09:56:16PM +0100, Dagobert Michelsen wrote: >> No. If someone has a modified config-file I'll need to take >> care of it or the symlink in htdocs could not be created. >> This must be tested and this all takes some time. >> >> If you say I should just move the stuff over I'll it right >> now, but this is not a smooth transitions for users. > > yeah. just move it over. > > it would be nice if you just had a quicky postinstall check for, > "was there an older install? if so, post a warning message for 30 sec" > but that's about it. > It's too messy otherwise. And I think it was the right thing you advised me: Make the transition automatic if possible and stop if it can't be migrated safely. Best regards -- Dago From trygvis at opencsw.org Sun Sep 13 22:24:56 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 13 Sep 2009 22:24:56 +0200 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: <4AAD5518.1080708@opencsw.org> Dagobert Michelsen wrote: > Hi Phil, > > Am 11.09.2009 um 18:22 schrieb Philip Brown: >> On Thu, Sep 10, 2009 at 11:41 AM, Maciej (Matchek) Blizinski >> wrote: >>> >>> There another case to consider: the case when the configuration files >>> can't be automatically migrated. Should the preinstall script abort >>> the installation? (Can it really abort the installation?) Any other >>> ideas? >> >> I did already give my own opinion on this one; yes it should stop the >> install. and yes it has the power to do that. simply exit with >> non-zero status. > > Let me remind you that this is contrary to what you advised me on > transitioning Mantis: > > Am 21.03.2008 um 22:08 schrieb Philip Brown: >> On Fri, Mar 21, 2008 at 09:56:16PM +0100, Dagobert Michelsen wrote: >>> No. If someone has a modified config-file I'll need to take >>> care of it or the symlink in htdocs could not be created. >>> This must be tested and this all takes some time. >>> >>> If you say I should just move the stuff over I'll it right >>> now, but this is not a smooth transitions for users. >> >> yeah. just move it over. >> >> it would be nice if you just had a quicky postinstall check for, >> "was there an older install? if so, post a warning message for 30 sec" >> but that's about it. >> It's too messy otherwise. > > And I think it was the right thing you advised me: Make the transition > automatic if possible and stop if it can't be migrated safely. If it is obvious where it was and where it should be moved to (like mpd's mpd.conf file), just move it. Otherwise just fail. -- Trygve From trygvis at opencsw.org Mon Sep 14 14:12:01 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Mon, 14 Sep 2009 14:12:01 +0200 Subject: [csw-maintainers] OpenCSW summer camp: What were your impressions? Brainstorming for further camps. In-Reply-To: <4A999C1B.9010506@opencsw.org> References: <4A999C1B.9010506@opencsw.org> Message-ID: <4AAE3311.5040601@opencsw.org> Sebastian Kayser wrote: > Hi, > > thanks again to Ihsan for dealing with organizational stuff and Trygve > for setting us up with the gorgeous venue above Olso. "After the game, > is before the game" (as the saying goes in soccer), hence i would like > to capture some of the impressions that you took away from Oslo while > they are still fresh so that we know what to take care of for further > meetings. > > - How would you sum up the weekend and what you took away from it? > > - What would you like to see again? > > - What would you have wished to be different? How? > > - Any other ideas that don't fit into the two above? Stuff that we > should try next time? I liked it that we just sat until we got hungry and everyone was fed up with hacking. It makes it kinda harder to prepare a place up front, but if you don't go for anything very fancy it was quite easy to find a decent place to eat at. Being able to bring a laptop or at least notes is probably nice as not everyone feel like getting drunk and would like to continue to talk/work throughout the evening. -- Trygve From schwindt at dfki.uni-kl.de Mon Sep 14 15:12:45 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 14 Sep 2009 15:12:45 +0200 Subject: [csw-maintainers] Transmission 1.75 in testing Message-ID: <200909141312.n8EDCj8H021207@dfki.uni-kl.de> I put Transmission 1.75 into testing. Transmission is a cross-platform BitTorrent client Nicolai From william at wbonnet.net Mon Sep 14 16:07:58 2009 From: william at wbonnet.net (William Bonnet) Date: Mon, 14 Sep 2009 16:07:58 +0200 Subject: [csw-maintainers] /testing Seamonkey 1.1.18 is available Message-ID: <4AAE4E3E.2060703@wbonnet.net> Hi Seamonkey 1.1.18 is available from testing for Solaris 8+ http://mirror.opencsw.org/testing/seamonkey-1.1.18,REV=2009.09.14-SunOS5.8-i386-CSW.pkg.gz http://mirror.opencsw.org/testing/seamonkey-1.1.18,REV=2009.09.14-SunOS5.8-sparc-CSW.pkg.gz Feedbacks are welcome since it is my first version of the package. This package will be updated with the rest of the Mozilla's applications. cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From daniel at opencsw.org Mon Sep 14 17:49:50 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Mon, 14 Sep 2009 16:49:50 +0100 Subject: [csw-maintainers] Release of updated cairo In-Reply-To: References: <4AA522F3.6070903@pocock.com.au> <9D68CA91-DBC1-4756-B90F-007E2122F831@opencsw.org> <4AA56225.1050307@pocock.com.au> <6130367B-C3FE-49B3-81B0-B3850DBAC572@opencsw.org> <4AAA1B8B.7030700@pocock.com.au> <60378F51-D464-46B7-8A85-16B771E6D104@opencsw.org> <4AAA1F2F.30806@pocock.com.au> Message-ID: <4AAE661E.4000000@opencsw.org> Dagobert Michelsen wrote: > Hi, > > Am 11.09.2009 um 11:58 schrieb Daniel Pocock: >> Dagobert Michelsen wrote: >>> Hi Daniel, >>> >>> Am 11.09.2009 um 11:42 schrieb Daniel Pocock: >>>> I also need the rrdtool package on all the build machines so I can >>>> build my packages. >>> >>> ?? rrdtool is already on all build machines, or are you missing >>> something? >> >> Actually, you are right - rrd.h is there, it is the cairo issue > > John: How about releasing the updated cairo from testing? > I haven't seen any problems with the new cairo package on my test machine running the Ganglia packages. Is there any further work to do to get the new cairo package out of testing, and is it something I could assist with? From phil at bolthole.com Mon Sep 14 19:20:01 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Sep 2009 10:20:01 -0700 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: On Sun, Sep 13, 2009 at 1:16 PM, Dagobert Michelsen wrote: > Hi Phil, >.... > > Let me remind you that this is contrary to what you advised me on > transitioning Mantis: >... and this is why I am AGAINST having a strict policy on the issue of transitioning etc files, but believe that each package should be carefully considered on its own merits :-) It's a potentially very sticky issue. I do not think people should do it casually. I think that having a deep "policy" on this issue, would discorage people from actually THINKING about what is best for their package. This would be the opposite of best practice, in my opinion. I think that "the policy" should not be much more than, "keep local configs in /etc/opt/csw, and local state in /var/opt/csw", and leave the "how to get there" mostly to the maintainer. From dam at opencsw.org Mon Sep 14 20:29:40 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 14 Sep 2009 20:29:40 +0200 Subject: [csw-maintainers] Release of updated cairo In-Reply-To: <4AAE661E.4000000@opencsw.org> References: <4AA522F3.6070903@pocock.com.au> <9D68CA91-DBC1-4756-B90F-007E2122F831@opencsw.org> <4AA56225.1050307@pocock.com.au> <6130367B-C3FE-49B3-81B0-B3850DBAC572@opencsw.org> <4AAA1B8B.7030700@pocock.com.au> <60378F51-D464-46B7-8A85-16B771E6D104@opencsw.org> <4AAA1F2F.30806@pocock.com.au> <4AAE661E.4000000@opencsw.org> Message-ID: <89247C5F-4220-4E69-B6B9-26959592B7F6@opencsw.org> Hi Daniel, Am 14.09.2009 um 17:49 schrieb Daniel Pocock: > Dagobert Michelsen wrote: >> Hi, >> Am 11.09.2009 um 11:58 schrieb Daniel Pocock: >>> Dagobert Michelsen wrote: >>>> Hi Daniel, >>>> >>>> Am 11.09.2009 um 11:42 schrieb Daniel Pocock: >>>>> I also need the rrdtool package on all the build machines so I >>>>> can build my packages. >>>> >>>> ?? rrdtool is already on all build machines, or are you missing >>>> something? >>> >>> Actually, you are right - rrd.h is there, it is the cairo issue >> John: How about releasing the updated cairo from testing? > > I haven't seen any problems with the new cairo package on my test > machine running the Ganglia packages. > > Is there any further work to do to get the new cairo package out of > testing, and is it something I could assist with? Yes, you need to copy them over from 'login' to www.opencsw.org:/home/newpkgs and write an email to phil@ with "newpkgs" in the subject stating what should be released and what has changed. Best regards -- Dago From phil at bolthole.com Mon Sep 14 21:16:44 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Sep 2009 12:16:44 -0700 Subject: [csw-maintainers] Release of updated cairo In-Reply-To: <89247C5F-4220-4E69-B6B9-26959592B7F6@opencsw.org> References: <4AA522F3.6070903@pocock.com.au> <9D68CA91-DBC1-4756-B90F-007E2122F831@opencsw.org> <4AA56225.1050307@pocock.com.au> <6130367B-C3FE-49B3-81B0-B3850DBAC572@opencsw.org> <4AAA1B8B.7030700@pocock.com.au> <60378F51-D464-46B7-8A85-16B771E6D104@opencsw.org> <4AAA1F2F.30806@pocock.com.au> <4AAE661E.4000000@opencsw.org> <89247C5F-4220-4E69-B6B9-26959592B7F6@opencsw.org> Message-ID: On Mon, Sep 14, 2009 at 11:29 AM, Dagobert Michelsen wrote: > > Yes, you need to copy them over from 'login' to > ?www.opencsw.org:/home/newpkgs > and write an email to phil@ with "newpkgs" in the subject stating what > should be > released and what has changed. > > erm.... thats sligthly overkill. It is helpful to know which packages are "brand new", vs "upgrades to prior ones". Also, if anything MAJOR has changed, it's useful to let me know. But it isnt neccessary to email me a changelog or anything :-) From daniel at opencsw.org Mon Sep 14 21:33:16 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Mon, 14 Sep 2009 20:33:16 +0100 Subject: [csw-maintainers] newpks Re: Release of updated cairo In-Reply-To: References: <4AA522F3.6070903@pocock.com.au> <9D68CA91-DBC1-4756-B90F-007E2122F831@opencsw.org> <4AA56225.1050307@pocock.com.au> <6130367B-C3FE-49B3-81B0-B3850DBAC572@opencsw.org> <4AAA1B8B.7030700@pocock.com.au> <60378F51-D464-46B7-8A85-16B771E6D104@opencsw.org> <4AAA1F2F.30806@pocock.com.au> <4AAE661E.4000000@opencsw.org> <89247C5F-4220-4E69-B6B9-26959592B7F6@opencsw.org> Message-ID: <4AAE9A7C.5020309@opencsw.org> Philip Brown wrote: > On Mon, Sep 14, 2009 at 11:29 AM, Dagobert Michelsen wrote: >> Yes, you need to copy them over from 'login' to >> www.opencsw.org:/home/newpkgs >> and write an email to phil@ with "newpkgs" in the subject stating what >> should be >> released and what has changed. >> >> > > erm.... thats sligthly overkill. It is helpful to know which packages > are "brand new", vs "upgrades to prior ones". > > Also, if anything MAJOR has changed, it's useful to let me know. But > it isnt neccessary to email me a changelog or anything :-) This appears to be a minor upgrade from 1.8.6 to 1.8.8 It appears to resolve issues when linking with rrdtool, therefore, even though I don't maintain the libcairo package, I am putting it in newpkgs so people can use rrdtool again Phil, please let Dago know when it is ready so he can put it on the build farm and I can build the Ganglia packages. daniel at login [login]:/home/testing > ls -l libcai* -rw-r--r-- 1 ellson csw 496243 Aug 4 20:45 libcairo-1.8.8,REV=2009.08.04-SunOS5.8-i386-CSW.pkg.gz -rw-r--r-- 1 ellson csw 620887 Aug 4 20:45 libcairo-1.8.8,REV=2009.08.04-SunOS5.8-sparc-CSW.pkg.gz -rw-r--r-- 1 ellson csw 26668 Aug 4 20:45 libcairo_devel-1.8.8,REV=2009.08.04-SunOS5.8-i386-CSW.pkg.gz -rw-r--r-- 1 ellson csw 26540 Aug 4 20:45 libcairo_devel-1.8.8,REV=2009.08.04-SunOS5.8-sparc-CSW.pkg.gz -rw-r--r-- 1 ellson csw 149356 Aug 4 20:45 libcairo_doc-1.8.8,REV=2009.08.04-SunOS5.8-all-CSW.pkg.gz daniel at login [login]:/home/testing > scp libcai* www.opencsw.org:/home/newpkgs/ libcairo-1.8.8,REV=2 100% |*****************************| 484 KB 00:00 libcairo-1.8.8,REV=2 100% |*****************************| 606 KB 00:00 libcairo_devel-1.8.8 100% |*****************************| 26668 00:00 libcairo_devel-1.8.8 100% |*****************************| 26540 00:00 libcairo_doc-1.8.8,R 100% |*****************************| 145 KB 00:00 From maciej at opencsw.org Mon Sep 14 21:37:10 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 14 Sep 2009 20:37:10 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: <4AAB32A6.5060305@opencsw.org> References: <4A939902.3050808@opencsw.org> <4AAB32A6.5060305@opencsw.org> Message-ID: 2009/9/12 Trygve Laugst?l : > As I see it there are actually two discussions going on here simultaneously: > > * Handling configuration files for zones and NFS environments > > For this point I think we need to find more examples to be able to figure > out a reasonable policy. > > * The actual upgrade process and the physical moving of existing > configuration files If you want to split it up, I'd suggest three discussions: 1. What should be the guidelines for configuration files for environments with shared/read-only /opt.[1] 2. The actual migration process which does not involve shared/read-only /opt ("just move it" works) 3. The actual migration process involving shared/read-only /opt. ("just move it" does not work) I'm mostly concerned with the discussion number 3, as it's blocking my work with three pieces of software (cups, unixodbc and tightvnc). Trygve, since you objected to putting my sample implementation into testing, can you comment on the suggested solutions or suggest one of your own? Maciej [1] Phil suggests: http://lists.opencsw.org/pipermail/maintainers/2009-September/004144.html From bwalton at opencsw.org Tue Sep 15 01:44:11 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 14 Sep 2009 19:44:11 -0400 Subject: [csw-maintainers] CSWcommon update request Message-ID: <1252971767-sup-7257@ntdws12.chass.utoronto.ca> Hi Phil, Please add the following directories to CSWcommon: /etc/opt/csw/pkg-hooks/prebatchinstall.d/ /etc/opt/csw/pkg-hooks/postbatchinstall.d/ /etc/opt/csw/pkg-hooks/prebatchupgrade.d/ /etc/opt/csw/pkg-hooks/postbatchupgrade.d/ /etc/opt/csw/pkg-hooks/prebatchremove.d/ /etc/opt/csw/pkg-hooks/postbatchremove.d/ /etc/opt/csw/pkg-hooks/preinstall.d/ /etc/opt/csw/pkg-hooks/postinstall.d/ /etc/opt/csw/pkg-hooks/preupgrade.d/ /etc/opt/csw/pkg-hooks/postupgrade.d/ /etc/opt/csw/pkg-hooks/preremove.d/ /etc/opt/csw/pkg-hooks/postremove.d/ /var/opt/csw/pkg-hooks Hooks are implemented in pkgutil 1.7, and I'll soon start releasing packages that use them. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Tue Sep 15 02:13:38 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Sep 2009 17:13:38 -0700 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: On Sat, Sep 12, 2009 at 7:48 AM, Dagobert Michelsen wrote: > >> >> Errr.. that's not what I was saying at all. > > What I said boils down to what you said, only that I would infer that > from CSWcommon instead of hardcoding it. > > no. i was only saying, "check for, and warn about, any paths in a package that are not under /opt/csw, or /etc/opt/csw, or /var/opt/etc". You are saying, "AND in addition, check for any paths that are in CSWcommon, and gripe about that". I think that's going too far. If a package wants to declare some of the same directories/perms as what is in CSWcommon, it's a little redundant, but it's not "wrong". From dam at opencsw.org Tue Sep 15 10:14:25 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Sep 2009 10:14:25 +0200 Subject: [csw-maintainers] Release of updated cairo In-Reply-To: <89247C5F-4220-4E69-B6B9-26959592B7F6@opencsw.org> References: <4AA522F3.6070903@pocock.com.au> <9D68CA91-DBC1-4756-B90F-007E2122F831@opencsw.org> <4AA56225.1050307@pocock.com.au> <6130367B-C3FE-49B3-81B0-B3850DBAC572@opencsw.org> <4AAA1B8B.7030700@pocock.com.au> <60378F51-D464-46B7-8A85-16B771E6D104@opencsw.org> <4AAA1F2F.30806@pocock.com.au> <4AAE661E.4000000@opencsw.org> <89247C5F-4220-4E69-B6B9-26959592B7F6@opencsw.org> Message-ID: <4C245342-60D8-4BA6-BD8E-F31E089C6727@opencsw.org> Hi, Am 14.09.2009 um 20:29 schrieb Dagobert Michelsen: > Am 14.09.2009 um 17:49 schrieb Daniel Pocock: >> I haven't seen any problems with the new cairo package on my test >> machine running the Ganglia packages. >> Is there any further work to do to get the new cairo package out of >> testing, and is it something I could assist with? > > Yes, you need to copy them over from 'login' to > www.opencsw.org:/home/newpkgs > and write an email to phil@ with "newpkgs" in the subject stating > what should be > released and what has changed. The updated libcairo has been installed on all buildfarm servers. Now work can proceed with Ganglia and Graphviz :-) Best regards -- Dago From trygvis at opencsw.org Tue Sep 15 10:40:18 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 15 Sep 2009 10:40:18 +0200 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> Message-ID: <4AAF52F2.4060804@opencsw.org> Philip Brown wrote: > On Sun, Sep 13, 2009 at 1:16 PM, Dagobert Michelsen wrote: >> Hi Phil, >> .... >> >> Let me remind you that this is contrary to what you advised me on >> transitioning Mantis: >> ... > > and this is why I am AGAINST having a strict policy on the issue of > transitioning etc files, but believe that each package should be > carefully considered on its own merits :-) > > It's a potentially very sticky issue. I do not think people should do > it casually. I think that having a deep "policy" on this issue, would > discorage people from actually THINKING about what is best for their > package. This would be the opposite of best practice, in my opinion. I think it is very important to have a policy on how it is supposed to be. If not people will INVENT their own methods and we will have no CONSISTENCY leading to OpenCSW packages being hard to use. I agree that you can't and shouldn't make a policy that goes into every detail, but having guidelines explaining why we do thing this way is a good thing. It is very confusing for new maintainers to figure out where stuff is supposed to go. By having a set of reason it is easier to understand why it is supposed to be that way and to make your own choices when that is required. > I think that "the policy" should not be much more than, "keep local > configs in /etc/opt/csw, and local state in /var/opt/csw", and leave > the "how to get there" mostly to the maintainer. A policy definitely needs to mention when it is correct to use /opt/csw/etc vs /etc/opt/csw. -- Trygve From phil at bolthole.com Tue Sep 15 18:27:34 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Sep 2009 09:27:34 -0700 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: <4AAF52F2.4060804@opencsw.org> References: <4A939902.3050808@opencsw.org> <4AAF52F2.4060804@opencsw.org> Message-ID: 2009/9/15 Trygve Laugst?l : > Philip Brown wrote: >> >> It's a potentially very sticky issue. I do not think people should do >> it casually. I think that having a deep "policy" on this issue, would >> discorage people from actually THINKING about what is best for their >> package. This would be the opposite of best practice, in my opinion. > > I think it is very important to have a policy on how it is supposed to be. > If not people will INVENT their own methods and we will have no CONSISTENCY > leading to OpenCSW packages being hard to use. > rather than call that part "policy", I would rather say we should have a set of recommendations, and offer tools, so that maintainers can re-use solutions, rather than have to invent their own. Sometimes, they will HAVE to. but for most people, if you offer them a tool that works, they will use it by their own preference. > A policy definitely needs to mention when it is correct to use /opt/csw/etc > vs /etc/opt/csw. true enough. and I thought we had a writeup of that already. .... we do. http://www.opencsw.org/standards/layout Subdirectories of /opt/csw ... etc Global Configuration files. (Machine-local conf files should go in /etc/opt/csw/[softwarename] or /etc/opt/csw) Seems to be explicit, and clear. From maciej at opencsw.org Tue Sep 15 20:11:52 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Sep 2009 19:11:52 +0100 Subject: [csw-maintainers] CUPS issues Message-ID: There's an issue with cups-polld that I've been investigating for some time now. When I attempted to reproduce it under a debugger, another bug surfaced, I'm just about to file a bug report with CUPS developers. After implementing a workaround against the second bug, the original issue doesn't show up at all. I'm suspecting that it's something dependent on the optimization level. To summarize: with -xO2 bug1 is triggered, but bug2 is not with -xO0 bug1 is not triggered, but bug2 is. Since bug2 seems to be relatively easy to fix, I got working binaries by compiling cups with -xO0 and thus hiding bug1. The dilemma is as follows: - optimized binaries work for most people but fail miserably in my production environment - unoptimized binaries work fine in my environment, but I feel it's wrong to ship unoptimized binaries from OpenCSW I'm stuck here. I can't debug it. I can't ship it. Help! Maciej P.S. I'll do more testing, perhaps I'll be able to reproduce bug1, but I haven't been so far. From maciej at opencsw.org Tue Sep 15 20:14:17 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Sep 2009 19:14:17 +0100 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: Message-ID: On Fri, Sep 11, 2009 at 5:04 PM, Philip Brown wrote: > well,, there are multiple potential "issues" at play here. > on the one hand, I understand your frustration at not having it > normally in the path. > But what would be the side effects of having a symlink > /opt/csw/bin/mysql -> /opt/csw/mysql5/bin/mysql ? I was thinking about this... what if someone has mysql4 also installed? Perhaps some sort of "switch" app, which would change the symlinks, would be good. I need to think about it some more. > Would it break auto-detection of mysql location, when compiling? It depends on how is the autodetection done (if at all ;-) ), I'd give symlinks a shot and see if there is any yelling from the users. > It may indeed be appropriate to adjust our mysql5 package to have the > symlink in there. > > BTW: would you be intersted in taking over our mysql package, for > purposes of updating, and putting the symlink in there? > (pleasepleasepleaseplease? :-) :-) I've already done some work towards this end, but I was recently shaving a yak. I should have something to show within a week or two. I don't use MySQL on Solaris myself, I'm not sure if I'm the best candidate for a long-term MySQL maintainer, but I can at least, for the fun of it, bring the build to the form in which it works and can be easily handed off to another person. Maciej From phil at bolthole.com Tue Sep 15 20:49:17 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Sep 2009 11:49:17 -0700 Subject: [csw-maintainers] article on opensolaris vs linux Message-ID: interesting article on opensolaris vs linux. Some of the comments on the article are actually useful, too. I learned a thing or two. http://www.tuxradar.com/content/opensolaris-vs-linux From phil at bolthole.com Tue Sep 15 20:53:06 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Sep 2009 11:53:06 -0700 Subject: [csw-maintainers] CUPS issues In-Reply-To: References: Message-ID: On Tue, Sep 15, 2009 at 11:11 AM, Maciej (Matchek) Blizinski wrote: > > > To summarize: > > with -xO2 bug1 is triggered, but bug2 is not > with -xO0 bug1 is not triggered, but bug2 is. > > Since bug2 seems to be relatively easy to fix, I got working binaries > by compiling cups with -xO0 and thus hiding bug1. owch. Please remember that, odds are, its only ONE FILE, that needs to be compiled this way. If you feel masochistic,you might try substituting files around to see which ones are critical. Then again... do you REAAALLY need optimized cups? :-) oh, btw; you are concerned about a specific demon, not the library (yes?), you also certainly have the option of compiling with gcc without it affecting anything else(?). Although you might also use older/newer version of sun compiler as alternative, too! From daniel at opencsw.org Tue Sep 15 22:40:19 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Tue, 15 Sep 2009 21:40:19 +0100 Subject: [csw-maintainers] dependency issue while checking packages Message-ID: <4AAFFBB3.7000106@opencsw.org> My ganglia Makefile generates a number of packages: PACKAGES = CSWgangliart CSWgangliaagent CSWgangliadevel CSWgangliagmetad CSWgangliaweb CSWgangliamodpython When I run gmake package it builds CSWgangliaagent, and then complains because CSWgangliart doesn't exist or is not installed When I build on my own machine (Solaris 10 x86 + current + Sun Studio 12) I am able to build all the packages successfully without this error. On build8s, however, only the ganglia_agent package file is generated and the build goes no further: Examining 'depend' file P CSWcswclassutils cswclassutils - CSW class action utilities P CSWexpat expat - XML Parser Toolkit P CSWlibconfuse libconfuse - a configuration file parser library P CSWapache2rt apache2rt - A high performance Unix-based HTTP server. P CSWgangliart ganglia_rt - Ganglia runtime libraries P CSWcommon common - common files and dirs for CSW packages application CSWapache2rt apache2rt - A high performance Unix-based HTTP server. system CSWcommon common - common files and dirs for CSW packages application CSWcswclassutils cswclassutils - CSW class action utilities application CSWexpat expat - XML Parser Toolkit ERROR: information for "CSWgangliart" was not found ERROR: Invalid package CSWgangliart specified. Check of /tmp/ganglia_agent-3.1.3,REV=2009.09.15-SunOS5.8-sparc-UNCOMMITTED.pkg.gz fails gmake: *** [pkgcheck-CSWgangliaagent] Error 2 bash-2.03$ ls ~/staging/build-15.Sep.2009/ ganglia_agent-3.1.3,REV=2009.09.15-SunOS5.8-sparc-UNCOMMITTED.pkg.gz From skayser at opencsw.org Tue Sep 15 23:27:27 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 15 Sep 2009 23:27:27 +0200 Subject: [csw-maintainers] Solaris 8&9: No header file for (get|set|end)usershell, but libc provides it? Message-ID: <4AB006BF.1000302@opencsw.org> Hi, does anyone know why there would be no include files with function declarations for the (get|set|end)usershell functions on Solaris 8 & 9, although the functions are documented and provided by libc? I have an application that tries to build with -errwarn and bails out with implicit function declaration warnings. On both build8s and build9s the situation is about the same $ apropos usershell endusershell getusershell (3c) - get legal user shells getusershell getusershell (3c) - get legal user shells setusershell getusershell (3c) - get legal user shells $ ggrep -Er '(get|set|end)usershell' /usr/include/ $ $ nm -p /usr/lib/libc.so | ggrep -Er '(get|set|end)usershell' 0000247760 T endusershell 0000247684 T getusershell 0000000000 f getusershell.c 0000247860 T setusershell build10s does have the function declaration in unistd.h $ ggrep -Er '(get|set|end)usershell' /usr/include/ /usr/include/unistd.h:extern void endusershell(void); /usr/include/unistd.h:extern char *getusershell(void); /usr/include/unistd.h:extern void setusershell(void); /usr/include/unistd.h:extern void endusershell(); /usr/include/unistd.h:extern char *getusershell(); /usr/include/unistd.h:extern void setusershell(); What i noticed so far is that the man page for the affected libc calls (in contrast to others) does not mention an include file on Solaris 8 & 9 ... never seen this before. Sebastian From phil at bolthole.com Tue Sep 15 23:36:25 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Sep 2009 14:36:25 -0700 Subject: [csw-maintainers] Solaris 8&9: No header file for (get|set|end)usershell, but libc provides it? In-Reply-To: <4AB006BF.1000302@opencsw.org> References: <4AB006BF.1000302@opencsw.org> Message-ID: It happens sometimes. just fake your own extern.h file if you must, or something like that. On Tue, Sep 15, 2009 at 2:27 PM, Sebastian Kayser wrote: > Hi, > > does anyone know why there would be no include files with function > declarations for the (get|set|end)usershell functions on Solaris 8 & 9, > although the functions are documented and provided by libc? > From maciej at opencsw.org Wed Sep 16 00:30:24 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Sep 2009 23:30:24 +0100 Subject: [csw-maintainers] dependency issue while checking packages In-Reply-To: <4AAFFBB3.7000106@opencsw.org> References: <4AAFFBB3.7000106@opencsw.org> Message-ID: On Tue, Sep 15, 2009 at 9:40 PM, Daniel Pocock wrote: > > > > My ganglia Makefile generates a number of packages: > > PACKAGES = CSWgangliart CSWgangliaagent CSWgangliadevel CSWgangliagmetad > CSWgangliaweb CSWgangliamodpython > > When I run > > gmake package > > it builds CSWgangliaagent, and then complains because CSWgangliart doesn't > exist or is not installed A workaround: ENABLE_CHECK=0 gmake package There's going to be a fix, but I don't think it has been released yet. Maciej From daniel at opencsw.org Wed Sep 16 01:23:34 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 16 Sep 2009 00:23:34 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing Message-ID: <4AB021F6.3050505@opencsw.org> Thanks for all the assistance and feedback about the CSW packaging process I've finally got the unofficial 3.1.3 code into testing now - feedback is welcome Please note the following about versions: 3.1.2 is the latest official release - this builds successfully on Solaris 10 with Sun Studio 12, no patching required - it doesn't build successfully on Sun Studio 11 or Solaris 8 (multiple issues) 3.1.3 is not yet in the RC stage, but very close to it - I have used the code from the monitor-core-3.1 branch upstream, and built a sample 3.1.3 package which is now in OpenCSW testing. During this process, I identified one further change that is required to support Sun Studio 11, otherwise, it seems to be good for Solaris 8 and above, Sun Studio 11 or 12. For a bare minimum install: - put ganglia_agent on all machines to be monitored - put ganglia_web on the machine which is meant to be the monitoring server - restart Apache on the monitoring server - browse to http:///ganglia/ The agent interoperates smoothly with the Linux agent on the same network. Any feedback is welcome - if anyone has configuration/deployment questions outside the scope of OpenCSW, please feel free to email me personally or use the Ganglia discussion lists. From skayser at opencsw.org Wed Sep 16 17:48:22 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 16 Sep 2009 17:48:22 +0200 (CEST) Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB021F6.3050505@opencsw.org> References: <4AB021F6.3050505@opencsw.org> Message-ID: <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> Hi Daniel, Daniel Pocock wrote: > Thanks for all the assistance and feedback about the CSW packaging process > > I've finally got the unofficial 3.1.3 code into testing now - feedback > is welcome your packages have the UNCOMMITED status (see their file names), which means that you had uncommitted local changes when building the package. UNCOMITTED packages won't be considered for the testing catalog. Issue 'svn status' to see which files are still uncomitted, take care of them (commit or branch if necessary), rebuild the packages and replace the current ones in /home/testing. Thanks Sebastian From bwalton at opencsw.org Wed Sep 16 17:55:02 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 16 Sep 2009 11:55:02 -0400 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> Message-ID: <1253116461-sup-7722@ntdws12.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Wed Sep 16 11:48:22 -0400 2009: > Issue 'svn status' to see which files are still uncomitted, take care of > them (commit or branch if necessary), rebuild the packages and replace the > current ones in /home/testing. If you still have the build/install files in work/, you can commit the changes and simply issue `gmake repackage` without having to do the build, test, etc steps. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From daniel at opencsw.org Wed Sep 16 17:55:57 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 16 Sep 2009 16:55:57 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> Message-ID: <4AB10A8D.2040504@opencsw.org> Sebastian Kayser wrote: > Hi Daniel, > > Daniel Pocock wrote: > > Thanks for all the assistance and feedback about the CSW packaging > process > > > > I've finally got the unofficial 3.1.3 code into testing now - feedback > > is welcome > > your packages have the UNCOMMITED status (see their file names), which > means that you had uncommitted local changes when building the package. > UNCOMITTED packages won't be considered for the testing catalog. > > Issue 'svn status' to see which files are still uncomitted, take care of > them (commit or branch if necessary), rebuild the packages and replace the > current ones in /home/testing. That is because I don't want to commit the checksum for ganglia-3.1.3.tar.gz as it is not an official release There are a couple of Makefile changes that are safe to commit though. I'm planning to tag 3.1.3 upstream on Friday, but I would like to get feedback from OpenCSW users before I do that. From maciej at opencsw.org Wed Sep 16 17:58:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 16 Sep 2009 16:58:30 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB10A8D.2040504@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> Message-ID: On Wed, Sep 16, 2009 at 4:55 PM, Daniel Pocock wrote: > Sebastian Kayser wrote: >> >> Hi Daniel, >> >> Daniel Pocock wrote: >> > Thanks for all the assistance and feedback about the CSW packaging >> > process >> > >> > I've finally got the unofficial 3.1.3 code into testing now - feedback >> > is welcome >> >> your packages have the UNCOMMITED status (see their file names), which >> means that you had uncommitted local changes when building the package. >> UNCOMITTED packages won't be considered for the testing catalog. >> >> Issue 'svn status' to see which files are still uncomitted, take care of >> them (commit or branch if necessary), rebuild the packages and replace the >> current ones in /home/testing. > > That is because I don't want to commit the checksum for ganglia-3.1.3.tar.gz > as it is not an official release I'd suggest creating a branch, and committing your code there. Maciej From skayser at opencsw.org Wed Sep 16 18:15:33 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 16 Sep 2009 18:15:33 +0200 (CEST) Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB10A8D.2040504@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> Message-ID: <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> Daniel Pocock schrieb: > Sebastian Kayser wrote: >> Daniel Pocock wrote: >> > Thanks for all the assistance and feedback about the CSW packaging >> process >> > >> > I've finally got the unofficial 3.1.3 code into testing now - feedback >> > is welcome >> >> your packages have the UNCOMMITED status (see their file names), which >> means that you had uncommitted local changes when building the package. >> UNCOMITTED packages won't be considered for the testing catalog. >> >> Issue 'svn status' to see which files are still uncomitted, take care of >> them (commit or branch if necessary), rebuild the packages and replace >> the >> current ones in /home/testing. > > That is because I don't want to commit the checksum for > ganglia-3.1.3.tar.gz as it is not an official release > > There are a couple of Makefile changes that are safe to commit though. > I'm planning to tag 3.1.3 upstream on Friday, but I would like to get > feedback from OpenCSW users before I do that. You could simply create a branch to work on the upcoming release. ~/mgar/pkg/ganglia$ svn cp trunk/ branches/ganglia-3.1.3-rc Then continue your work there, commit the changes and you will get packages without the UNCOMMITTED status. The point being: packages with the UNCOMITTED status (as your current ones) are skipped by the script that builds the testing catalog, i.e. pkg-get / pkgutil will NOT see them (although they are happily stored in /home/testing). Sebastian P.S.: No need to CC me, i am on the list. From bwalton at opencsw.org Wed Sep 16 18:37:22 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 16 Sep 2009 12:37:22 -0400 Subject: [csw-maintainers] interdependent packages moving to /etc/opt/csw Message-ID: <1253118865-sup-4588@ntdws12.chass.utoronto.ca> Hi All, I've got a large stack of interdependent packages that will be all changing $sysconfdir to /etc/opt/csw. I don't see a clean way to handle this move short of manually removing all of the packages and then adding them back. [Some packages register things in files provided by other packages, etc.] If I provide detailed instructions on the ordering of these operations, is that sufficient for our user base? NOTE: This is completely separate from the other changes that have been discussed recently. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Wed Sep 16 20:33:17 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Sep 2009 11:33:17 -0700 Subject: [csw-maintainers] interdependent packages moving to /etc/opt/csw In-Reply-To: <1253118865-sup-4588@ntdws12.chass.utoronto.ca> References: <1253118865-sup-4588@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Sep 16, 2009 at 9:37 AM, Ben Walton wrote: > > Hi All, > > I've got a large stack of interdependent packages that will be all > changing $sysconfdir to /etc/opt/csw. ?I don't see a clean way to > handle this move short of manually removing all of the packages and > then adding them back. ?[Some packages register things in files > provided by other packages, etc.] > > If I provide detailed instructions on the ordering of these > operations, is that sufficient for our user base? It sounds "highly complex". yikes. I would suggest that,for the sake of our users, you provide some sort of migration script, that first verifies everything is at the minimum level required (or does a "strings xyz" to see that the paths have changed), and then does the neccessary backflips. Or bombs out with appropriate error messages, if not up to date. You might provide the migration script, as part of the "highest level"(if there is one) package. possibly in the "docs" dir, along with an explaination there of why it is neccessary. From bwalton at opencsw.org Wed Sep 16 20:39:59 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 16 Sep 2009 14:39:59 -0400 Subject: [csw-maintainers] interdependent packages moving to /etc/opt/csw In-Reply-To: References: <1253118865-sup-4588@ntdws12.chass.utoronto.ca> Message-ID: <1253126281-sup-4486@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Sep 16 14:33:17 -0400 2009: > It sounds "highly complex". yikes. It's all the docbook junk which has packages register themselves, etc. Ordering is very important, which is the real fly in the ointment. > I would suggest that,for the sake of our users, you provide some sort > of migration script, that first verifies everything is at the minimum > level required (or does a "strings xyz" to see that the paths have > changed), and then does the neccessary backflips. Or bombs out with > appropriate error messages, if not up to date. This sounds reasonable. I'll put something together and make it available. I don't think it should go in any one ofhe packages though, since it's of limited future value. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Wed Sep 16 20:48:42 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Sep 2009 11:48:42 -0700 Subject: [csw-maintainers] interdependent packages moving to /etc/opt/csw In-Reply-To: <1253126281-sup-4486@ntdws12.chass.utoronto.ca> References: <1253118865-sup-4588@ntdws12.chass.utoronto.ca> <1253126281-sup-4486@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Sep 16, 2009 at 11:39 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Wed Sep 16 14:33:17 -0400 2009: > >> I would suggest that,for the sake of our users, you provide some sort >> of migration script, that first verifies everything is at the minimum >> level required (or does a "strings xyz" to see that the paths have >> changed), and then does the neccessary backflips. Or bombs out with >> appropriate error messages, if not up to date. > > This sounds reasonable. ?I'll put something together and make it > available. ?I don't think it should go in any one ofhe packages > though, since it's of limited future value. > well, consider keeping it in a package,for a year then? People do go a year without updates. and it's really nice to have it all there with the packages. From dam at opencsw.org Wed Sep 16 18:39:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 16 Sep 2009 18:39:02 +0200 Subject: [csw-maintainers] Minutes for the SummerCamp 2009 online now Message-ID: Hi, the minutes from the Summer Camp 2009 in Oslo are now available at and ready for discussion! Sorry for the delay -- Dago From maciej at opencsw.org Thu Sep 17 10:40:17 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 17 Sep 2009 09:40:17 +0100 Subject: [csw-maintainers] The source code of www.opencsw.org In-Reply-To: <20090726154345.GB28096@bolthole.com> References: <20090723220149.GB8541@bolthole.com> <20090724041722.GA50043@bolthole.com> <20090724042720.GB50043@bolthole.com> <4A6979F4.5050904@opencsw.org> <20090724160343.GC91227@bolthole.com> <4A6B4DFE.1050307@opencsw.org> <20090725203035.GA24170@bolthole.com> <4A6C2341.8060600@opencsw.org> <20090726154345.GB28096@bolthole.com> Message-ID: On Sun, Jul 26, 2009 at 4:43 PM, Philip Brown wrote: > On Sun, Jul 26, 2009 at 11:34:57AM +0200, Trygve Laugst?l wrote: >> Can you explain what the security reason for not putting it an SCM is? > > "a" source code control mechanism, I dont have much problem with. > putting it in a PUBLIC one, is where my concerns lay. > > Beyond that, I dont see the need to force everyone to use one particular > type of scm, just for small web page "code". > If the assorted people working on opencsw web stuff agree to standardize on > one internal-only scheme, i'd go along with it. But frankly, most of the > web related stuff is small enough that the old cycle of > > "make a save copy, tweak with the new stuff, publish it, forget about old > ?stuff" > > is perfectly adequate. Okay, so what's the process? I can't write to the htdocs directory, so what do I do? Make my own copy of everything and create a patch? When I have a patch ready, say, http://www.opencsw.org/~maciej/0001-Parseable-HTML-in-mirrors.shtml.patch -- what do I do with it next? Maciej From maciej at opencsw.org Thu Sep 17 12:24:15 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 17 Sep 2009 11:24:15 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> <4AAB32A6.5060305@opencsw.org> Message-ID: On Mon, Sep 14, 2009 at 8:37 PM, Maciej (Matchek) Blizinski wrote: > 3. The actual migration process involving shared/read-only /opt. > ("just move it" does not work) > > I'm mostly concerned with the discussion number 3, as it's blocking my > work with three pieces of software (cups, unixodbc and tightvnc). > Trygve, since you objected to putting my sample implementation into > testing, can you comment on the suggested solutions or suggest one of > your own? Trygve, ping? From skayser at opencsw.org Thu Sep 17 12:45:06 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 17 Sep 2009 12:45:06 +0200 (CEST) Subject: [csw-maintainers] GAR RFE: Variable(s) to tag files for classes instead of PROTOTYPE_FILTER In-Reply-To: <3E39F7BB-726B-4250-8388-43EEF3D24B3F@opencsw.org> References: <51363.194.246.122.22.1246478936.squirrel@ssl.skayser.de> <3E39F7BB-726B-4250-8388-43EEF3D24B3F@opencsw.org> Message-ID: <62623.194.246.122.22.1253184306.squirrel@ssl.skayser.de> Dagobert Michelsen wrote: > Am 01.07.2009 um 22:08 schrieb Sebastian Kayser: >> while working on postfix 2.6 i have noticed again that it is not quite >> straight-forward to assign files to classes. Instead of exposing the >> inner >> workings of the prototype stuff to the Makefile, could we maybe get >> some >> variables to assign files to classes (functions)? >> >> So instead of having: >> >> CONFIG_BASE = \/etc\/opt\/csw\/postfix\/ >> CONFIG_FILES = access aliases canonical generic header_checks >> CONFIG_FILES += main.cf master.cf >> CONFIG_FILES += relocated transport virtual >> >> PROTOTYPE_FILTER = awk '\ >> $(foreach C,$(prefix $(CONFIG_BASE),$(CONFIG_FILES)), \ >> $$$$3 ~ /^$(C)$$$$/ { $$$$2 = "cswcpsampleconf" }) \ >> .... >> >> just have something like: >> >> CONFIG_FILES = /etc/default/cswpostgrey >> CONFIG_FILES += /etc/opt/csw/postfix/access >> CONFIG_FILES += /etc/opt/csw/postfix/aliases >> CONFIG_FILES += /etc/opt/csw/postfix/canonical >> CONFIG_FILES += /etc/opt/csw/postfix/generic >> CONFIG_FILES += /etc/opt/csw/postfix/header_checks >> CONFIG_FILES += /etc/opt/csw/postfix/main.cf >> CONFIG_FILES += /etc/opt/csw/postfix/master.cf >> CONFIG_FILES += /etc/opt/csw/postfix/relocated >> CONFIG_FILES += /etc/opt/csw/postfix/transport >> CONFIG_FILES += /etc/opt/csw/postfix/virtual >> >> To me this would feel more declarative instead of the procedural way >> we do >> it with PROTOTYE_FILTER right now (note, it can be shortened with >> $(foreach and $(prefix, just like above). It would not only tag the >> class, >> but also wrap the other housekeeping, like moving the config files >> to .CSW >> during the build process. >> >> (Side note: Thinking ahead, it could also be an conceptual abstraction >> level WRT to IPS: Do IPS packages still have a prototype file?) >> >> This is only an example for config files, which i encounter most >> often. >> Other classes could be "wrapped" as well. One would just have to >> come up >> with the requirements, a proper naming scheme for the variables, >> and .... >> actually implement it in GAR. > > For CSWcswclassutils this is already in there :-) Just define > > SAMPLECONF > PRESERVECONF > INITSMF > > and everything else will be taken cared of. Heads up: There was a small bug in SAMPLECONF. Class assignment ended up in cswsampleconf instead of cswcpsampleconf. Fixed in r6329. Sebastian From skayser at opencsw.org Thu Sep 17 13:08:18 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 17 Sep 2009 13:08:18 +0200 (CEST) Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4A939902.3050808@opencsw.org> <4AAB32A6.5060305@opencsw.org> Message-ID: <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Maciej (Matchek) Blizinski wrote: > On Mon, Sep 14, 2009 at 8:37 PM, Maciej (Matchek) Blizinski > wrote: >> 3. The actual migration process involving shared/read-only /opt. >> ("just move it" does not work) >> >> I'm mostly concerned with the discussion number 3, as it's blocking my >> work with three pieces of software (cups, unixodbc and tightvnc). >> Trygve, since you objected to putting my sample implementation into >> testing, can you comment on the suggested solutions or suggest one of >> your own? > > Trygve, ping? My concern with simply placing symlinks in /etc is that it doesn't reduce the clutter that i feel we have today. Some files reside in /opt others in /etc. I know there is the definition about what has to go into /etc/opt/csw and what has to go into /opt/csw/etc, but i see how this confuses people (including me). My preference would be to have it all in /etc, i.e. move config files over. To not break with setup like yours, couldn't we introduce a csw.conf variable that would indicate such a setup? cswclassutils scripts running in such an environment would know that they need to behave different. This way we could focus on having a simple baseline that works with the traditional "one host" (or "full root zone") setup and treat special setups in a special way (i don't feel we can fully address all of them with one single approach). I haven't thought that through completely, but it might be an alternative approach. Might also turn out to be even more complex. Sebastian From maciej at opencsw.org Thu Sep 17 15:44:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 17 Sep 2009 14:44:46 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> References: <4A939902.3050808@opencsw.org> <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: On Thu, Sep 17, 2009 at 12:08 PM, Sebastian Kayser wrote: > My concern with simply placing symlinks in /etc is that it doesn't reduce > the clutter that i feel we have today. Some files reside in /opt others in > /etc. I support that, I agree that one place for configuration is better then two places. (One might argue that creating /opt/csw/etc was unnecessary, as there already was /etc. I'd be personally happier with everything sitting in /etc as nature intended.) > I know there is the definition about what has to go into > /etc/opt/csw and what has to go into /opt/csw/etc, but i see how this > confuses people (including me). It's one of the things that in practice you're always forced to "just learn" and get over. Eradicating /opt/csw/etc would be great, but I don't think it's happening in foreseeable future. But we can do a lot to ease the pain by installing signposts in appropriate places. > My preference would be to have it all in /etc, i.e. move config files over. Or, in the case of shared /opt, copy them or link them (to leave them shared). > To not break with setup like yours, couldn't we introduce a csw.conf > variable that would indicate such a setup? cswclassutils scripts running > in such an environment would know that they need to behave different. What would be the cases and how would they be handled? I guess the cases could be: shared /opt => link files local /opt => move files > This way we could focus on having a simple baseline that works with the > traditional "one host" (or "full root zone") setup and treat special > setups in a special way That's a possibility; it would be good to indicate during installation, that such configuration variable is needed. > (i don't feel we can fully address all of them > with one single approach). I haven't thought that through completely, but > it might be an alternative approach. Might also turn out to be even more > complex. Perhaps, it's good to have many eyeballs look at the issue. In the meantime, Sebastian and I have added a section on incentives to move to /etct/opt/csw: http://wiki.opencsw.org/configuration-directory-migration Maciej From daniel at opencsw.org Thu Sep 17 16:43:39 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 17 Sep 2009 15:43:39 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> Message-ID: <4AB24B1B.6020101@opencsw.org> Sebastian Kayser wrote: > Daniel Pocock schrieb: > > Sebastian Kayser wrote: > >> Daniel Pocock wrote: > >>> Thanks for all the assistance and feedback about the CSW packaging > >> process > >>> I've finally got the unofficial 3.1.3 code into testing now - feedback > >>> is welcome > >> your packages have the UNCOMMITED status (see their file names), which > >> means that you had uncommitted local changes when building the package. > >> UNCOMITTED packages won't be considered for the testing catalog. > >> > >> Issue 'svn status' to see which files are still uncomitted, take > care of > >> them (commit or branch if necessary), rebuild the packages and replace > >> the > >> current ones in /home/testing. > > That is because I don't want to commit the checksum for > > ganglia-3.1.3.tar.gz as it is not an official release > > > > There are a couple of Makefile changes that are safe to commit though. > > I'm planning to tag 3.1.3 upstream on Friday, but I would like to get > > feedback from OpenCSW users before I do that. > > You could simply create a branch to work on the upcoming release. > > ~/mgar/pkg/ganglia$ svn cp trunk/ branches/ganglia-3.1.3-rc > Thanks for the advice about this - I have done as you suggest, and now the new packages are in testing again From phil at bolthole.com Thu Sep 17 18:25:09 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 17 Sep 2009 09:25:09 -0700 Subject: [csw-maintainers] The source code of www.opencsw.org In-Reply-To: References: <20090723220149.GB8541@bolthole.com> <20090724042720.GB50043@bolthole.com> <4A6979F4.5050904@opencsw.org> <20090724160343.GC91227@bolthole.com> <4A6B4DFE.1050307@opencsw.org> <20090725203035.GA24170@bolthole.com> <4A6C2341.8060600@opencsw.org> <20090726154345.GB28096@bolthole.com> Message-ID: On Thu, Sep 17, 2009 at 1:40 AM, Maciej (Matchek) Blizinski wrote: > > Okay, so what's the process? I can't write to the htdocs directory, so > what do I do? Make my own copy of everything and create a patch? When > I have a patch ready, say, > http://www.opencsw.org/~maciej/0001-Parseable-HTML-in-mirrors.shtml.patch > -- what do I do with it next? > forget "patch". you have a "live" html directory for a reason :) get it working. then when it works well enough, it will either replace what is already there, or be put in its own appropriate place. and you get full read/write access to it there. BTW: i kinda lost contact for what you are aiming for now. I think I maybe already provided you with the code chunk you asked from me. but if you need anything else, please let me know, specifically, what you need from me. From phil at bolthole.com Thu Sep 17 18:31:53 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 17 Sep 2009 09:31:53 -0700 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: On Thu, Sep 17, 2009 at 6:44 AM, Maciej (Matchek) Blizinski wrote: > > > I support that, I agree that one place for configuration is better > then two places. (One might argue that creating /opt/csw/etc was > unnecessary, as there already was [/etc/opt/csw]. On the contrary; it is quite NECCESSARY. As our filesystem layout guide already mentions! Sometimes, you WANT global, shared, identical preferences for an application. Sometimes you DONT. For things that almost never change, or get site-modified once and then mostly left alone for eternity, it is best to have them in /opt/csw/etc, for cases where /opt/csw is NFS shared, or shared across multiple zones. It makes life much simpler for the sysadmin. From maciej at opencsw.org Fri Sep 18 06:00:55 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 18 Sep 2009 05:00:55 +0100 Subject: [csw-maintainers] The source code of www.opencsw.org In-Reply-To: References: <20090723220149.GB8541@bolthole.com> <4A6979F4.5050904@opencsw.org> <20090724160343.GC91227@bolthole.com> <4A6B4DFE.1050307@opencsw.org> <20090725203035.GA24170@bolthole.com> <4A6C2341.8060600@opencsw.org> <20090726154345.GB28096@bolthole.com> Message-ID: On Thu, Sep 17, 2009 at 5:25 PM, Philip Brown wrote: > On Thu, Sep 17, 2009 at 1:40 AM, Maciej (Matchek) Blizinski > wrote: >> >> Okay, so what's the process? I can't write to the htdocs directory, so >> what do I do? Make my own copy of everything and create a patch? When >> I have a patch ready, say, >> http://www.opencsw.org/~maciej/0001-Parseable-HTML-in-mirrors.shtml.patch >> -- what do I do with it next? >> > > forget "patch". you have a "live" html directory for a reason :) > get it working. It's working! Sure, I can send a whole updated file too. Where should I deliver it? > BTW: i kinda lost contact for what you are aiming for now. The sample patch is just a random change. It only deals with comment code, removing bits that make it difficult to parse this page with less forgiving HTML parsers. Maciej From bonivart at opencsw.org Fri Sep 18 09:58:13 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 18 Sep 2009 09:58:13 +0200 Subject: [csw-maintainers] 1. VM image of OpenSolaris with OpenCSW, 2. Custom streams Message-ID: <625385e30909180058n709f044at1ce9756bd56a1e5d@mail.gmail.com> I would like to make available an image (for VMWare/VirtualBox) of OpenSolaris with OpenCSW bootstrapped. I tried it in VirtualBox and exported it as OVF and it's about 1,3 GB which is not that much today. We could even publish it as a torrent on Pirate Bay. :-) VMWare can also publish it for us. Sure we can't do this for Solaris 8-10 but even Sun is moving towards OpenSolaris now providing official support for it and many people are curious about it, it's time that we show our presence on that platform. Maybe we could get our "distro" publish on the OpenSolaris web site? The second idea is to allow people to customize their downloads on our (new) web site. They could click any number of packages and a stream would be prepared for download with all dependencies included. What do you think? -- /peter From schwindt at dfki.uni-kl.de Fri Sep 18 10:30:47 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Fri, 18 Sep 2009 10:30:47 +0200 Subject: [csw-maintainers] Updated libiconv in testing, testing appreciated In-Reply-To: Your message of "Fri, 31 Jul 2009 09:22:43 +0200." <49274.217.227.42.13.1249024963.squirrel@ssl.skayser.de> Message-ID: <200909180830.n8I8Ulu1005821@dfki.uni-kl.de> [...] > > I will give your version a try, as I always did have a patched version of > > iconv > > around, and am using a self compiled version of 1.13.1 for quite some time > > now. > > I can state that this version generally functions well, troublemaker like > > subversion works perfect with it. > > > > I'll let you know how things worked out > > cool, thanks for the support. Note though: I recently pulled the iconv > packages from testing, because they were ones, aimed at the CSWiconv -> > CSWlibiconv package name change. With various bits and pieces of our stack > currently being under heavy change (gtk, pango, bdb) I would like to > postpone such a (purely cosmetical) change. > > I will put new iconv packages with the current naming scheme into testing > later this day. Will keep you updated. This has been around for quite some time now - I installed und succesfully used on all our machines. Subversion - being the most picky package about iconv utf8/646 conversion - still works like a charme. How aboout releasing it from testing ? Or did anybody have issues with this ? Nicolai. From dam at opencsw.org Fri Sep 18 16:57:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 18 Sep 2009 16:57:32 +0200 Subject: [csw-maintainers] 1. VM image of OpenSolaris with OpenCSW, 2. Custom streams In-Reply-To: <625385e30909180058n709f044at1ce9756bd56a1e5d@mail.gmail.com> References: <625385e30909180058n709f044at1ce9756bd56a1e5d@mail.gmail.com> Message-ID: <4AE6D0E2-9D74-4C37-A139-ACE7C2DA2E37@opencsw.org> Hi Peter, Am 18.09.2009 um 09:58 schrieb Peter Bonivart: > I would like to make available an image (for VMWare/VirtualBox) of > OpenSolaris with OpenCSW bootstrapped. I tried it in VirtualBox and > exported it as OVF and it's about 1,3 GB which is not that much today. > We could even publish it as a torrent on Pirate Bay. :-) VMWare can > also publish it for us. Sure we can't do this for Solaris 8-10 but > even Sun is moving towards OpenSolaris now providing official support > for it and many people are curious about it, it's time that we show > our presence on that platform. Maybe we could get our "distro" publish > on the OpenSolaris web site? Good idea. And a good start to verify things before going IPS. > The second idea is to allow people to customize their downloads on our > (new) web site. They could click any number of packages and a stream > would be prepared for download with all dependencies included. > > What do you think? Well, that's what I wanted the stream-flag for initially :-) Best regards -- Dago From phil at bolthole.com Fri Sep 18 17:08:47 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Sep 2009 08:08:47 -0700 Subject: [csw-maintainers] serf - how to correctly depend on libapr ? In-Reply-To: <4A0F6B37.9090703@opencsw.org> References: <6af4270905161141t16480a31u917bacc3a4c2a303@mail.gmail.com> <4A0F6B37.9090703@opencsw.org> Message-ID: Going back a ways... On Sat, May 16, 2009 at 6:41 PM, Mike Watters wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > rupert THURNER wrote: >> i tried to create a package for libserf, which should replace libneon >> in future, as it is able to multithread subversion calls to a server. >> >> as there is no libapr, .... FYI, we just had an explicit pkg request for a separate apr package. From bonivart at opencsw.org Fri Sep 18 17:11:27 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 18 Sep 2009 17:11:27 +0200 Subject: [csw-maintainers] 1. VM image of OpenSolaris with OpenCSW, 2. Custom streams In-Reply-To: <4AE6D0E2-9D74-4C37-A139-ACE7C2DA2E37@opencsw.org> References: <625385e30909180058n709f044at1ce9756bd56a1e5d@mail.gmail.com> <4AE6D0E2-9D74-4C37-A139-ACE7C2DA2E37@opencsw.org> Message-ID: <625385e30909180811k70bea2fbs1e964d97c4b4d445@mail.gmail.com> On Fri, Sep 18, 2009 at 4:57 PM, Dagobert Michelsen wrote: >> The second idea is to allow people to customize their downloads on our >> (new) web site. They could click any number of packages and a stream >> would be prepared for download with all dependencies included. >> >> What do you think? > > Well, that's what I wanted the stream-flag for initially :-) Yes, it's not really my idea, I admit that. :-) I think it should be integrated into the new package browser on the new web site. Just click checkboxes next to the packages in the list and click "Create stream". -- /peter From phil at bolthole.com Fri Sep 18 17:59:51 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Sep 2009 08:59:51 -0700 Subject: [csw-maintainers] 1. VM image of OpenSolaris with OpenCSW, 2. Custom streams In-Reply-To: <625385e30909180811k70bea2fbs1e964d97c4b4d445@mail.gmail.com> References: <625385e30909180058n709f044at1ce9756bd56a1e5d@mail.gmail.com> <4AE6D0E2-9D74-4C37-A139-ACE7C2DA2E37@opencsw.org> <625385e30909180811k70bea2fbs1e964d97c4b4d445@mail.gmail.com> Message-ID: On Fri, Sep 18, 2009 at 8:11 AM, Peter Bonivart wrote: > > > I think it should be integrated into the new package browser on the > new web site. Just click checkboxes next to the packages in the list > and click "Create stream". > its a nice idea.... but do we have the bandwidth for this?? I thought that we were at least somewhat constrained in that reguard. I think that the preconfigured OS+CSW images are a great idea. Maybe we should just standardize on two,though: "desktop" and "server" perhaps? oh: in addition to "virtual machine" images... methinks it would be a very useful thing to have actual "install to bare iron" images? piggyback on the standard opensolaris installer somehow? and/or a livecd. From schwindt at dfki.uni-kl.de Fri Sep 18 18:31:38 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Fri, 18 Sep 2009 18:31:38 +0200 Subject: [csw-maintainers] geany 0.18 in testing Message-ID: <200909181631.n8IGVca9015020@dfki.uni-kl.de> Geany is a text editor using the GTK2 toolkit with basic features of an integrated development environment. It was developed to provide a small and fast IDE, which has only a few dependencies from other packages. It supports many filetypes and has some nice features. Feedback welcome Nicolai From dam at opencsw.org Fri Sep 18 22:39:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 18 Sep 2009 22:39:17 +0200 Subject: [csw-maintainers] New catalog for farm managers Message-ID: <1D5696A4-2E60-46F2-BCE3-4B5292D20445@opencsw.org> Hi, to ease the setup of buildfarms I have set up an additional catalog for farm-manager-only packages. These currently include - JDK 5 - JDK 6 - Sun Studio 11 - Sun Studio 12 - Sun Studio 12u1 All software is packaged as one package for most easy install: http://mirror.opencsw.org/opencsw/farm/ The packages are not meant for redistribution. Best regards -- Dago From phil at bolthole.com Sat Sep 19 00:15:05 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Sep 2009 15:15:05 -0700 Subject: [csw-maintainers] New catalog for farm managers In-Reply-To: <1D5696A4-2E60-46F2-BCE3-4B5292D20445@opencsw.org> References: <1D5696A4-2E60-46F2-BCE3-4B5292D20445@opencsw.org> Message-ID: On Fri, Sep 18, 2009 at 1:39 PM, Dagobert Michelsen wrote: > > All software is packaged as one package for most easy install: > > ?http://mirror.opencsw.org/opencsw/farm/ > > The packages are not meant for redistribution. > I would suggest then, that you rename the package filenames to NOT match our usual standard naming conventions? From dam at opencsw.org Sat Sep 19 14:04:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 19 Sep 2009 14:04:26 +0200 Subject: [csw-maintainers] Detection of libstdc++ in pkgcheck Message-ID: <0A00EB96-0F7F-4E30-8E34-7213A0C51B5F@opencsw.org> Hi, I noticed that pkgcheck warns me about a missing dependency to CSWgcc3g ++ because of the library libstdc++.so.6. It looks like this: /opt/csw/gcc3/lib/libstdc++.so.6=./../../lib/libstdc++.so.6 s none CSWgcc3g++ /opt/csw/gcc3/lib/libstdc++.so.6.0.1=./../../lib/libstdc++.so.6.0.1 s none CSWgcc3g++ /opt/csw/gcc3/lib/libstdc++.so.6.0.2=./../../lib/libstdc++.so.6.0.2 s none CSWgcc3g++ /opt/csw/gcc3/lib/libstdc++.so.6.0.3=./../../lib/libstdc++.so.6.0.3 s none CSWgcc3g++ /opt/csw/lib/libstdc++.so=./libstdc++.so.6.0.3 s none CSWgcc3g++rt /opt/csw/lib/libstdc++.so.6=./libstdc++.so.6.0.3 s none CSWgcc3g++rt /opt/csw/lib/libstdc++.so.6.0.1 f none 0755 root bin 1318628 61448 1248201928 CSWgcc3g++rt Shouldn't /opt/csw/gcc3/lib/libstdc++.so.6 belong to CSWgcc4g++rt instead of CSWgcc3g++? Best regards -- Dago From dam at opencsw.org Sat Sep 19 16:34:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 19 Sep 2009 16:34:28 +0200 Subject: [csw-maintainers] C++ hell with Sun Studio and GCC Message-ID: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> Hi, I am currently compiling xapian, a probabilistic search engine. The software is written in C++ and compiles under Sun Studio 11, 12 and GCC 3 and 4. There exist bindings for Ruby, Python and other languages. As Ruby is compiled with GCC I need to compile xapian with GCC too, otherwise the mangling does not work. However, Python requires Sun Studio. Is there any kind of "mangling conversion" between Sun Studio and GCC or must I really provide two versions of the xapian libraries? Best regards -- Dago From bwalton at opencsw.org Sat Sep 19 20:38:16 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Sep 2009 14:38:16 -0400 Subject: [csw-maintainers] C++ hell with Sun Studio and GCC In-Reply-To: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> References: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> Message-ID: <1253385314-sup-8901@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sat Sep 19 10:34:28 -0400 2009: Hi Dago, > As Ruby is compiled with GCC I need to compile xapian with GCC > too, otherwise the mangling does not work. However, Python requires > Sun Studio. Is there any kind of "mangling conversion" between > Sun Studio and GCC or must I really provide two versions of the > xapian libraries? I don't have an answer to your question, but I'm thinking about providing a 'split' ruby package. On solaris 8, I'd build with gcc4 as it is now. On 9 (and thus the package for 10), I'd use SOS12, which can apparently build ruby cleanly. This would allow me to meet my need to have ruby packages for sol8 still[1] while providing you a cleaner target to build against for the officially supported platforms. Work for you? Thanks -Ben [1] My fingers are crossed that we'll be getting a new platform to run our RoR apps, so this personal need may disappear soon too. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton at opencsw.org Sun Sep 20 01:55:44 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 19 Sep 2009 19:55:44 -0400 Subject: [csw-maintainers] big package update in testing/ Message-ID: <1253403883-sup-5997@ntdws12.chass.utoronto.ca> Hi All, I've just stuffed the following packages into testing: asciidoc-8.4.5,REV=2009.09.18-SunOS5.8-all-CSW.pkg.gz docbookdsssl-1.79,REV=2009.09.15-SunOS5.8-all-CSW.pkg.gz docbookdtds-4.5,REV=2009.09.16-SunOS5.8-all-CSW.pkg.gz docbookxsl-1.74.3,REV=2009.09.11-SunOS5.8-all-CSW.pkg.gz docbookxsldoc-1.74.3,REV=2009.09.11-SunOS5.8-all-CSW.pkg.gz gitosis-0.2,REV=2009.09.19_rev=73a03-SunOS5.8-all-CSW.pkg.gz gnulinks-1.2,REV=2009.09.18-SunOS5.8-all-CSW.pkg.gz libxml2-2.7.3,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz libxml2-2.7.3,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz libxml2_devel-2.7.3,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz libxml2_devel-2.7.3,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz libxslt-1.1.24,REV=2009.09.08-SunOS5.8-i386-CSW.pkg.gz libxslt-1.1.24,REV=2009.09.08-SunOS5.8-sparc-CSW.pkg.gz libxslt_devel-1.1.24,REV=2009.09.08-SunOS5.8-i386-CSW.pkg.gz libxslt_devel-1.1.24,REV=2009.09.08-SunOS5.8-sparc-CSW.pkg.gz openjade-1.3.2,REV=2009.09.11-SunOS5.8-i386-CSW.pkg.gz openjade-1.3.2,REV=2009.09.11-SunOS5.8-sparc-CSW.pkg.gz py_libxml2-2.7.3,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz py_libxml2-2.7.3,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz py_libxslt-1.1.24,REV=2009.09.08-SunOS5.8-i386-CSW.pkg.gz py_libxslt-1.1.24,REV=2009.09.08-SunOS5.8-sparc-CSW.pkg.gz sgmlcommon-0.6.3,REV=2009.09.13-SunOS5.8-all-CSW.pkg.gz xmlcommon-0.6.3,REV=2009.09.13-SunOS5.8-all-CSW.pkg.gz xmlto-0.0.22,REV=2009.09.16-SunOS5.8-i386-CSW.pkg.gz xmlto-0.0.22,REV=2009.09.16-SunOS5.8-sparc-CSW.pkg.gz These are all somewhat interrelated/interdependent, so if you update one of these from testing, please update all of the others in use on your systems. The attached script (which I haven't tested on my own systems yet since I'm waiting for catalog updates) may ease this process. ...as you can see from the script, there is no good place to include this with any one of the packages. Please let me know of any issues you encounter. Also, if any of your packages depend on one of these and do xml/sgml catalog registration, let me know. I'll hold the release of these until you can provide an updated package too. Feedback is welcome. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: update_xml_pkgs.sh Type: application/x-sh Size: 912 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton at opencsw.org Sun Sep 20 16:12:18 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 20 Sep 2009 10:12:18 -0400 Subject: [csw-maintainers] mantis mail Message-ID: <1253455888-sup-7101@ntdws12.chass.utoronto.ca> Hi All, Is it possible to have mantis send only a single piece of mail per bug update? I seem to get 2 per update... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: not available URL: From bchill at opencsw.org Mon Sep 21 00:31:42 2009 From: bchill at opencsw.org (Brian Hill) Date: Sun, 20 Sep 2009 22:31:42 +0000 Subject: [csw-maintainers] librsync 0.9.7 uploaded to testing Message-ID: <20090920223142.GB24322@vm-1.bch.net> I have loaded librsync for testing. It isn't all that useful by itself, but it is needed for rdiff-backup, which is coming soon. Does the descriptions file update at regular intervals or is it done by hand? A pkg-get of librsync from testing doesn't work yet. Brian From bchill at opencsw.org Mon Sep 21 03:21:08 2009 From: bchill at opencsw.org (Brian Hill) Date: Mon, 21 Sep 2009 01:21:08 +0000 Subject: [csw-maintainers] rdiff-backup 1.2.8 uploaded to testing Message-ID: <20090921012108.GA5266@vm-1.bch.net> I have uploaded rdiff-backup for testing. Brian From bonivart at opencsw.org Mon Sep 21 10:04:07 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 21 Sep 2009 10:04:07 +0200 Subject: [csw-maintainers] librsync 0.9.7 uploaded to testing In-Reply-To: <20090920223142.GB24322@vm-1.bch.net> References: <20090920223142.GB24322@vm-1.bch.net> Message-ID: <625385e30909210104r3848006drfb465c3d3039644f@mail.gmail.com> On Mon, Sep 21, 2009 at 12:31 AM, Brian Hill wrote: > ? ? ? ?I have loaded librsync for testing. It isn't all that useful by > itself, but it is needed for rdiff-backup, which is coming soon. > > ? ? ? ?Does the descriptions file update at regular intervals or is it > done by hand? A pkg-get of librsync from testing doesn't work yet. I only saw Sparc packages there and those seem to work with pkgutil: New packages: CSWlibrsync-0.9.7,REV=2009.09.05 CSWpython-rt-2.6.2,REV=2009.08.12 CSWrdiff-backup-1.2.8,REV=2009.09.20 Updated packages: CSWcommon-1.4.7,REV=2009.09.20 CSWiconv-1.13.1,REV=2009.07.31 CSWzlib-1.2.3,REV=2009.04.05 Current packages: CSWbzip2-1.0.5,REV=2009.01.17 CSWggettextrt-0.17,REV=2009.02.13 CSWlibpopt-1.14,REV=2009.02.24 Total size: 4.7 MB 6 packages to fetch. Do you want to continue? [Y,n] -- /peter From skayser at opencsw.org Mon Sep 21 17:22:00 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 21 Sep 2009 17:22:00 +0200 (CEST) Subject: [csw-maintainers] Xlibs regression when building xterm (Xrender.h/Xft.h not found, ...) Message-ID: <65323.194.246.122.22.1253546520.squirrel@ssl.skayser.de> Hi, i just wanted to bump the xterm [1] version, ran into build issues, and noticed that i can't even build the version which i had released a few months ago any more (was r4246). ./configure fails to detect freetype support due to missing Xrender.h and Xft.h files [2]. What's the proper way to fix this? Or, rephrased, what's the canonical way to build X11 stuff in general, now that we have introduced our own X11 libs? For now i simply tried to point EXTRA_INC and EXTRA_LIB to /opt/csw/X11{include,lib} and EXTRA_PKG_CONFIG_PATH to /opt/csw/X11/lib/pkgconfig, which cures the Xrender.h/Xft.h issue, but raises another one. Now some Xutf8* symbols (which belong to /opt/csw/X11/lib/libX11.so) can't be resolved during linking. Excerpt below, for details see [3]. Undefined first referenced symbol in file Xutf8TextListToTextProperty button.o XA_UTF8_STRING button.o Xutf8TextPropertyToTextList button.o Xutf8LookupString input.o Help appreciated Sebastian [1] https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/xterm/trunk/Makefile [2] http://dpaste.com/96324/ [3] http://dpaste.com/96333/ From phil at bolthole.com Mon Sep 21 17:24:11 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Sep 2009 08:24:11 -0700 Subject: [csw-maintainers] Detection of libstdc++ in pkgcheck In-Reply-To: <0A00EB96-0F7F-4E30-8E34-7213A0C51B5F@opencsw.org> References: <0A00EB96-0F7F-4E30-8E34-7213A0C51B5F@opencsw.org> Message-ID: On Sat, Sep 19, 2009 at 5:04 AM, Dagobert Michelsen wrote: > Hi, > > I noticed that pkgcheck warns me about a missing dependency to CSWgcc3g++ > because of the library libstdc++.so.6. >[...] > Shouldn't /opt/csw/gcc3/lib/libstdc++.so.6 belong to CSWgcc4g++rt instead of > CSWgcc3g++? > yes. this is a long time known bug. If you have a suggested FIX for this bug, please feel free to contribute :-) however, I will say ahead of time, that you should consider the overall behaviour of how checkpkg works. your fix should not take away from functionality. (for example, it works as non-root user. One proposal to "fix" it, required running as root. So, I rejected that change) From phil at bolthole.com Mon Sep 21 17:28:04 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Sep 2009 08:28:04 -0700 Subject: [csw-maintainers] Xlibs regression when building xterm (Xrender.h/Xft.h not found, ...) In-Reply-To: <65323.194.246.122.22.1253546520.squirrel@ssl.skayser.de> References: <65323.194.246.122.22.1253546520.squirrel@ssl.skayser.de> Message-ID: On Mon, Sep 21, 2009 at 8:22 AM, Sebastian Kayser wrote: > Hi, > > i just wanted to bump the xterm [1] version, ran into build issues, and > noticed that i can't even build the version which i had released a few > months ago any more (was r4246). > > ./configure fails to detect freetype support due to missing Xrender.h and > Xft.h files [2]. What's the proper way to fix this? as a reminder to people who may not be familiar with things: previously, we provided an "Xrender" package, that provided the header files. The extension is somewhat odd, in that it only needs the header files to compile, not libraries. So, you could compile it on 8, even though it would not support xrender on 8. but it woudl automatically work right with later versions of solaris. (something like that, anyways). HOWEVER; our new xrender package, provides actual libs, which tie into the "new" X11. So, I think your choices are basically either A) grab the "old" headers and keep em around, and compile the old way or B) make xterm depend fully on our new, modern X11 libs from now on. But I'll let our new X11 lib maintainers chime in now. From skayser at opencsw.org Mon Sep 21 18:39:12 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 21 Sep 2009 18:39:12 +0200 (CEST) Subject: [csw-maintainers] Xlibs regression when building xterm (Xrender.h/Xft.h not found, ...) In-Reply-To: References: <65323.194.246.122.22.1253546520.squirrel@ssl.skayser.de> Message-ID: <65064.194.246.122.22.1253551152.squirrel@ssl.skayser.de> Philip Brown wrote: > On Mon, Sep 21, 2009 at 8:22 AM, Sebastian Kayser > wrote: >> i just wanted to bump the xterm [1] version, ran into build issues, and >> noticed that i can't even build the version which i had released a few >> months ago any more (was r4246). >> >> ./configure fails to detect freetype support due to missing Xrender.h >> and >> Xft.h files [2]. What's the proper way to fix this? > > > as a reminder to people who may not be familiar with things: > > previously, we provided an "Xrender" package, that provided the header > files. > The extension is somewhat odd, in that it only needs the header files > to compile, not libraries. > So, you could compile it on 8, even though it would not support > xrender on 8. but it woudl automatically work right with later > versions of solaris. > (something like that, anyways). > > HOWEVER; our new xrender package, provides actual libs, which tie into > the "new" X11. > > So, I think your choices are basically either > > A) grab the "old" headers and keep em around, and compile the old way > or > B) make xterm depend fully on our new, modern X11 libs from now on. > > But I'll let our new X11 lib maintainers chime in now. Thanks for the info, Phil. Update: i worked towards using the CSWlibx11 bits (xterm has --x-includes and --x-libraries ./configure flags, no need for EXTRA_INC or EXTRA_LIB) and now i am down to some remaining linkage errors. Undefined first referenced symbol in file FcCharSetHasChar fontutils.o (symbol belongs to implicit dependency /opt/csw/lib/libfontconfig.so.1) FcPatternBuild fontutils.o (symbol belongs to implicit dependency /opt/csw/lib/libfontconfig.so.1) FcPatternDestroy fontutils.o (symbol belongs to implicit dependency /opt/csw/lib/libfontconfig.so.1) XA_UTF8_STRING button.o ^^ Non-wrapped output and cc invocation available on dpaste [1]. Sebastian [1] http://dpaste.com/96366/ From bwalton at opencsw.org Mon Sep 21 19:11:34 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 21 Sep 2009 13:11:34 -0400 Subject: [csw-maintainers] C++ hell with Sun Studio and GCC In-Reply-To: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> References: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> Message-ID: <1253553057-sup-1892@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sat Sep 19 10:34:28 -0400 2009: Hi Dago, > As Ruby is compiled with GCC I need to compile xapian with GCC > too, otherwise the mangling does not work. However, Python requires > Sun Studio. Is there any kind of "mangling conversion" between > Sun Studio and GCC or must I really provide two versions of the > xapian libraries? I think moving ruby to SOS12 is the better long term solution, but could this be handled with modulations? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From glaw at opencsw.org Mon Sep 21 23:07:35 2009 From: glaw at opencsw.org (Gary Law) Date: Mon, 21 Sep 2009 22:07:35 +0100 Subject: [csw-maintainers] Owner/perms on /etc/opt{,/csw} In-Reply-To: References: Message-ID: 2009/9/15 Philip Brown : > I think that's going too far. > If a package wants to declare some of the same directories/perms as > what is in CSWcommon, it's a little redundant, but it's not "wrong". Well, I've put a new puppet package together that doesn't lay claim to those dirs anyway. It's in testing. Gary -- Gary Law Email: garylaw at garylaw.net Chat googletalk/messenger: gary.law at gmail.com iChat/jabber/AIM: gary.law at mac.com From glaw at opencsw.org Tue Sep 22 01:08:52 2009 From: glaw at opencsw.org (Gary Law) Date: Tue, 22 Sep 2009 00:08:52 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: 2009/9/17 Philip Brown : > On Thu, Sep 17, 2009 at 6:44 AM, Maciej (Matchek) Blizinski [snip] >> I support that, I agree that one place for configuration is better >> then two places. (One might argue that creating /opt/csw/etc was >> unnecessary, as there already was [/etc/opt/csw]. [snip] > Sometimes, you WANT global, shared, identical preferences for an application. > Sometimes you DONT. > > For things that almost never change, or get site-modified once and > then mostly left alone for eternity, it is best to have them in > /opt/csw/etc, for cases where /opt/csw is NFS shared, or shared across > multiple zones. It makes life much simpler for the sysadmin. I beg to differ. The increased complexity of two places outweighs any possible benefits. Everything in /etc/opt/csw please. -- Gary Law glaw at blastwave.org From dam at opencsw.org Tue Sep 22 07:45:33 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 07:45:33 +0200 Subject: [csw-maintainers] C++ hell with Sun Studio and GCC In-Reply-To: <1253553057-sup-1892@ntdws12.chass.utoronto.ca> References: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> <1253553057-sup-1892@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 21.09.2009 um 19:11 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Sat Sep 19 10:34:28 > -0400 2009: >> As Ruby is compiled with GCC I need to compile xapian with GCC >> too, otherwise the mangling does not work. However, Python requires >> Sun Studio. Is there any kind of "mangling conversion" between >> Sun Studio and GCC or must I really provide two versions of the >> xapian libraries? > > I think moving ruby to SOS12 is the better long term solution, but > could this be handled with modulations? Definitely. That would mean Ruby for Solaris 8 with GCC and starting with Solaris 9 with Sun Studio 12? That would make things of additional packages awfully hard as they would require modulations too. I like deprecation of Solaris 8 better here due to the massive complexities introduced with the splitted compilation. Anyway, an example for a compiler modulation is libtool. So I propose making a Solaris 8 Ruby with GCC if you really need it and starting with Solaris 9 and Sun Studio 12 for eveything else. BTW, are you interested in packaging up RubeEE and Phusion Passenger? I would need that also for my project, but as Ruby maintainer this would naturally be more on your side ;-) Best regards -- Dago From dam at opencsw.org Tue Sep 22 07:52:21 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 07:52:21 +0200 Subject: [csw-maintainers] Xlibs regression when building xterm (Xrender.h/Xft.h not found, ...) In-Reply-To: <65064.194.246.122.22.1253551152.squirrel@ssl.skayser.de> References: <65323.194.246.122.22.1253546520.squirrel@ssl.skayser.de> <65064.194.246.122.22.1253551152.squirrel@ssl.skayser.de> Message-ID: Hi Sebastian, Am 21.09.2009 um 18:39 schrieb Sebastian Kayser: > Philip Brown wrote: > Thanks for the info, Phil. Update: i worked towards using the > CSWlibx11 > bits (xterm has --x-includes and --x-libraries ./configure flags, no > need > for EXTRA_INC or EXTRA_LIB) and now i am down to some remaining > linkage > errors. > > Undefined first referenced > symbol in file > FcCharSetHasChar fontutils.o (symbol belongs to > implicit dependency /opt/csw/lib/libfontconfig.so.1) > FcPatternBuild fontutils.o (symbol belongs to > implicit dependency /opt/csw/lib/libfontconfig.so.1) > FcPatternDestroy fontutils.o (symbol belongs to > implicit dependency /opt/csw/lib/libfontconfig.so.1) > XA_UTF8_STRING button.o > > ^^ Non-wrapped output and cc invocation available on dpaste [1]. > > Sebastian > > [1] http://dpaste.com/96366/ I have not seen this before. Maybe a dependency has not been correctly compiled in there. Could you please verify where the symbols come from? Best regards -- Dago From maciej at opencsw.org Tue Sep 22 09:30:16 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 08:30:16 +0100 Subject: [csw-maintainers] GAR classes list variable name Message-ID: Is it CLASSES as described at [1] or SPKG_CLASSES as used in [2]? Maciej [1] http://wiki.opencsw.org/cswclassutils-package#toc6 [2] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gitosis/trunk/Makefile From bonivart at opencsw.org Tue Sep 22 09:38:31 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 22 Sep 2009 09:38:31 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: Message-ID: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> On Tue, Sep 22, 2009 at 9:30 AM, Maciej (Matchek) Blizinski wrote: > Is it CLASSES as described at [1] or SPKG_CLASSES as used in [2]? It's CLASSES when doing manual stuff in pkginfo and it's SPKG_CLASSES when using mGAR v2. But now it's even simpler to do when using GAR so you don't even have to bother with setting the classes. -- /peter From maciej at opencsw.org Tue Sep 22 10:02:22 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 09:02:22 +0100 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> Message-ID: On Tue, Sep 22, 2009 at 8:38 AM, Peter Bonivart wrote: > On Tue, Sep 22, 2009 at 9:30 AM, Maciej (Matchek) Blizinski > wrote: >> Is it CLASSES as described at [1] or SPKG_CLASSES as used in [2]? > > It's CLASSES when doing manual stuff in pkginfo and it's SPKG_CLASSES > when using mGAR v2. But now it's even simpler to do when using GAR so > you don't even have to bother with setting the classes. I've read the instructions on the and they don't seem complete to me. There are 2 things needed to set the file ownership: 1. A file defining users and groups (USERGROUP = ...) 2. A prototype with the ugfiles class The second bit needs to be done by filtering the prototype, is that right? A sample piece of code: USERGROUP = /opt/csw/etc/pkg/CSWmysql5/cswusergroup PROTOTYPE_FILTER = awk ' \ $$$$3 ~ /\/var\/opt\/csw\/mysql5$$$$/ { $$$$2 = "ugfiles"; \ $$$$4 = "0700"; \ $$$$5 = "mysql"; \ $$$$6 = "mysql" } \ { print }' SPKG_CLASSES = none ugfiles Without the last line (SPKG_CLASSES), my ugfiles-class file wasn't created on the disk during package installation. Maciej From dam at opencsw.org Tue Sep 22 10:09:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 10:09:49 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> Message-ID: <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> Hi Maciej, Am 22.09.2009 um 10:02 schrieb Maciej (Matchek) Blizinski: > On Tue, Sep 22, 2009 at 8:38 AM, Peter Bonivart > wrote: >> On Tue, Sep 22, 2009 at 9:30 AM, Maciej (Matchek) Blizinski >> wrote: >>> Is it CLASSES as described at [1] or SPKG_CLASSES as used in [2]? >> >> It's CLASSES when doing manual stuff in pkginfo and it's SPKG_CLASSES >> when using mGAR v2. But now it's even simpler to do when using GAR so >> you don't even have to bother with setting the classes. > > I've read the instructions on the and they don't seem complete to me. > There are 2 things needed to set the file ownership: > > 1. A file defining users and groups (USERGROUP = ...) > 2. A prototype with the ugfiles class > > The second bit needs to be done by filtering the prototype, is that > right? A sample piece of code: > > USERGROUP = /opt/csw/etc/pkg/CSWmysql5/cswusergroup > PROTOTYPE_FILTER = awk ' \ > $$$$3 ~ /\/var\/opt\/csw\/mysql5$$$$/ { $$$$2 = "ugfiles"; \ > $$$$4 = "0700"; \ > $$$$5 = "mysql"; \ > $$$$6 = "mysql" } \ > { print }' > SPKG_CLASSES = none ugfiles > > Without the last line (SPKG_CLASSES), my ugfiles-class file wasn't > created on the disk during package installation. What do you think about my proposal I sent some time ago? Am 06.09.2009 um 22:14 schrieb Dagobert Michelsen: > Am 05.09.2009 um 18:21 schrieb Maciej (Matchek) Blizinski: >> My day-to-day environment has umask set to 027; but many packages, >> when built with this umask, end up with binaries having permissions >> 0750. Perhaps it would be a good idea to do a GAR sanity check: bail >> out if umask is set to anything else than 022 when building a >> package? > > The standard user:group are already set in cswproto, as are the > permissions > for directories: > >> # Prototype defaults >> $StdOwn = 'root'; >> $StdGrp = 'bin'; >> $StdDirPerm = '0755'; > > I could imagine setting a default for files. Or changing the umask > to 022 > automatically on GAR invocation. BTW, we still a way of easily > tweaking > the prototype as PROTOTYPE_FILTERs are still too complex. > > Something like this could be useful: > > PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf > PROTOTYPE_PERMS_mytweaks = 0644 > PROTOTYPE_CLASS_mytweaks = cswconffile > > PROTOTYPE_MODIFIERS = mytweaks > > Here, PROTOTYPE_MODIFIERS is a list of modifiers to apply where for > each > modifier one or more fields can be changed. And PROTOTYPE_USER_mytweaks = myuser which would trigger the addition of 'ugfiles' to classes. Sounds good? Best regards -- Dago From bonivart at opencsw.org Tue Sep 22 10:16:34 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 22 Sep 2009 10:16:34 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> Message-ID: <625385e30909220116ya50f1d2i6bc611776efe5bd5@mail.gmail.com> On Tue, Sep 22, 2009 at 10:02 AM, Maciej (Matchek) Blizinski wrote: > I've read the instructions on the and they don't seem complete to me. > There are 2 things needed to set the file ownership: > > 1. A file defining users and groups (USERGROUP = ...) > 2. A prototype with the ugfiles class > > The second bit needs to be done by filtering the prototype, is that > right? A sample piece of code: > > USERGROUP = /opt/csw/etc/pkg/CSWmysql5/cswusergroup > PROTOTYPE_FILTER = awk ' \ > ? ?$$$$3 ~ /\/var\/opt\/csw\/mysql5$$$$/ { $$$$2 = "ugfiles"; \ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?$$$$4 = "0700"; \ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?$$$$5 = "mysql"; \ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?$$$$6 = "mysql" } \ > ? ?{ print }' > SPKG_CLASSES = none ugfiles > > Without the last line (SPKG_CLASSES), my ugfiles-class file wasn't > created on the disk during package installation. I haven't actually used the new GAR definitions since they arrived but I don't think there's a problem with the other ones, it's just the usergroup class that's a pain to explain. I've had lots of questions about it and tried to improve the documentation several times but now I don't think I can until I try the changes myself. I guess you still need the prototype filter in GAR after all just for this case. Maybe Dago and Sebastian can help simplifying this? -- /peter From maciej at opencsw.org Tue Sep 22 10:42:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 09:42:13 +0100 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> Message-ID: On Tue, Sep 22, 2009 at 9:09 AM, Dagobert Michelsen wrote: > What do you think about my proposal I sent some time ago? > > Am 06.09.2009 um 22:14 schrieb Dagobert Michelsen: >> >> Am 05.09.2009 um 18:21 schrieb Maciej (Matchek) Blizinski: >>> >>> My day-to-day environment has umask set to 027; but many packages, >>> when built with this umask, end up with binaries having permissions >>> 0750. Perhaps it would be a good idea to do a GAR sanity check: bail >>> out if umask is set to anything else than 022 when building a package? >> >> The standard user:group are already set in cswproto, as are the >> permissions >> for directories: >> >>> # Prototype defaults >>> $StdOwn = 'root'; >>> $StdGrp = 'bin'; >>> $StdDirPerm = '0755'; >> >> I could imagine setting a default for files. Or changing the umask to 022 >> automatically on GAR invocation. I would suggest having something like this in the ~/.garrc file: STOP_ON_WRONG_UMASK = 1 If the umask is not 022, the build would stop. >> BTW, we still a way of easily tweaking >> the prototype as PROTOTYPE_FILTERs are still too complex. >> >> Something like this could be useful: >> >> PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf >> PROTOTYPE_PERMS_mytweaks = 0644 >> PROTOTYPE_CLASS_mytweaks = cswconffile >> >> PROTOTYPE_MODIFIERS = mytweaks >> >> Here, PROTOTYPE_MODIFIERS is a list of modifiers to apply where for each >> modifier one or more fields can be changed. > > > And > PROTOTYPE_USER_mytweaks = myuser > which would trigger the addition of 'ugfiles' to classes. > > > Sounds good? >From the user's perspective, it's easier to think in terms of accomplishing a specific task. If I want to set user/group/permissions for a specific file, I'd find it more intuitive to use "USERGROUP" prefix rather than "PROTOTYPE", even though it's where the tweaking takes place under the hood. How about the following? USERGROUP_PASSWD = /etc/opt/csw/pkg/CSWfoo/cswusergroup USERGROUP_MODIFIERS = mytweaks USERGROUP_mytweaks_USER = mysql USERGROUP_mytweaks_GROUP = mysql USERGROUP_mytweaks_PERMS = 0700 USERGROUP_mytweaks_FILES = /var/opt/csw/mysql5 Maciej From skayser at opencsw.org Tue Sep 22 10:42:32 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 10:42:32 +0200 Subject: [csw-maintainers] Xlibs regression when building xterm (Xrender.h/Xft.h not found, ...) In-Reply-To: References: <65323.194.246.122.22.1253546520.squirrel@ssl.skayser.de> <65064.194.246.122.22.1253551152.squirrel@ssl.skayser.de> Message-ID: <4AB88DF8.5080301@opencsw.org> Dagobert Michelsen wrote on 22.09.2009 07:52: > Am 21.09.2009 um 18:39 schrieb Sebastian Kayser: >> Philip Brown wrote: >> Thanks for the info, Phil. Update: i worked towards using the >> CSWlibx11 >> bits (xterm has --x-includes and --x-libraries ./configure flags, no >> need >> for EXTRA_INC or EXTRA_LIB) and now i am down to some remaining >> linkage >> errors. >> >> Undefined first referenced >> symbol in file >> FcCharSetHasChar fontutils.o (symbol belongs to >> implicit dependency /opt/csw/lib/libfontconfig.so.1) >> FcPatternBuild fontutils.o (symbol belongs to >> implicit dependency /opt/csw/lib/libfontconfig.so.1) >> FcPatternDestroy fontutils.o (symbol belongs to >> implicit dependency /opt/csw/lib/libfontconfig.so.1) >> XA_UTF8_STRING button.o >> >> ^^ Non-wrapped output and cc invocation available on dpaste [1]. >> >> Sebastian >> >> [1] http://dpaste.com/96366/ > > I have not seen this before. Maybe a dependency has not been correctly > compiled > in there. Could you please verify where the symbols come from? Regarding the XA_UTF8_STRING symbol: it comes with a recent [1] libXmu library (X11 utility library) for which we don't yet have a CSW pkg. xterm _also_ ships with an implementation of XA_UTF8_STRING, but when it finds that X_HAVE_UTF8_STRING is defined (set by our Xlib.h), it assumes the system has an implementation of its own. In our case however, the system doesn't have have it, thus the build breaks. The stock Solaris Xlib.h which i used for the build a few months ago, doesn't set X_HAVE_UTF8_STRING. That's why the build was fine. Technically, xterm's assumption about the XA_UTF8_STRING presence might be wrong though, as it only checks for a Xlib UTF8 #define and then assumes the presence of a libXmu function. Guess i might have to talk to upstream. Still not sure about the Fc* symbol woes. Sebastian [1] Solaris 10 has a libXmu version that comes with XA_UTF8_STRING, Solaris 8 and 9 don't. From dam at opencsw.org Tue Sep 22 11:07:38 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 11:07:38 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> Message-ID: <8ACE4AB2-ACBB-4069-BC88-66BE92A2E586@opencsw.org> Hi Maciej, Am 22.09.2009 um 10:42 schrieb Maciej (Matchek) Blizinski: > On Tue, Sep 22, 2009 at 9:09 AM, Dagobert Michelsen > wrote: >> What do you think about my proposal I sent some time ago? >> >> Am 06.09.2009 um 22:14 schrieb Dagobert Michelsen: >>> >>> Am 05.09.2009 um 18:21 schrieb Maciej (Matchek) Blizinski: >>>> >>>> My day-to-day environment has umask set to 027; but many packages, >>>> when built with this umask, end up with binaries having permissions >>>> 0750. Perhaps it would be a good idea to do a GAR sanity check: >>>> bail >>>> out if umask is set to anything else than 022 when building a >>>> package? >>> >>> The standard user:group are already set in cswproto, as are the >>> permissions >>> for directories: >>> >>>> # Prototype defaults >>>> $StdOwn = 'root'; >>>> $StdGrp = 'bin'; >>>> $StdDirPerm = '0755'; >>> >>> I could imagine setting a default for files. Or changing the umask >>> to 022 >>> automatically on GAR invocation. > > I would suggest having something like this in the ~/.garrc file: > > STOP_ON_WRONG_UMASK = 1 > > If the umask is not 022, the build would stop. > >>> BTW, we still a way of easily tweaking >>> the prototype as PROTOTYPE_FILTERs are still too complex. >>> >>> Something like this could be useful: >>> >>> PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf >>> PROTOTYPE_PERMS_mytweaks = 0644 >>> PROTOTYPE_CLASS_mytweaks = cswconffile >>> >>> PROTOTYPE_MODIFIERS = mytweaks >>> >>> Here, PROTOTYPE_MODIFIERS is a list of modifiers to apply where >>> for each >>> modifier one or more fields can be changed. >> >> >> And >> PROTOTYPE_USER_mytweaks = myuser >> which would trigger the addition of 'ugfiles' to classes. >> >> >> Sounds good? > >> From the user's perspective, it's easier to think in terms of > accomplishing a specific task. If I want to set user/group/permissions > for a specific file, I'd find it more intuitive to use "USERGROUP" > prefix rather than "PROTOTYPE", even though it's where the tweaking > takes place under the hood. How about the following? > > USERGROUP_PASSWD = /etc/opt/csw/pkg/CSWfoo/cswusergroup > USERGROUP_MODIFIERS = mytweaks > USERGROUP_mytweaks_USER = mysql > USERGROUP_mytweaks_GROUP = mysql > USERGROUP_mytweaks_PERMS = 0700 > USERGROUP_mytweaks_FILES = /var/opt/csw/mysql5 The point is that you can modify all fields from the prototype here, ftype, class, major, minor, owner, mode, link-destinations, just everything. It is meant to replace the PROTOTYPE_FILTER, not just as a shortcut to cswusergroup. So fixating only on USERGROUP seems wrong to me. Best regards -- Dago From skayser at opencsw.org Tue Sep 22 11:08:54 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 11:08:54 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> Message-ID: <4AB89426.3090903@opencsw.org> Maciej (Matchek) Blizinski wrote on 22.09.2009 10:42: > On Tue, Sep 22, 2009 at 9:09 AM, Dagobert Michelsen wrote: >> What do you think about my proposal I sent some time ago? >> >> Am 06.09.2009 um 22:14 schrieb Dagobert Michelsen: >>> Am 05.09.2009 um 18:21 schrieb Maciej (Matchek) Blizinski: >>>> My day-to-day environment has umask set to 027; but many packages, >>>> when built with this umask, end up with binaries having permissions >>>> 0750. Perhaps it would be a good idea to do a GAR sanity check: bail >>>> out if umask is set to anything else than 022 when building a package? >>> The standard user:group are already set in cswproto, as are the >>> permissions >>> for directories: >>> >>>> # Prototype defaults >>>> $StdOwn = 'root'; >>>> $StdGrp = 'bin'; >>>> $StdDirPerm = '0755'; >>> I could imagine setting a default for files. Or changing the umask to 022 >>> automatically on GAR invocation. > > I would suggest having something like this in the ~/.garrc file: > > STOP_ON_WRONG_UMASK = 1 > > If the umask is not 022, the build would stop. > >>> BTW, we still a way of easily tweaking >>> the prototype as PROTOTYPE_FILTERs are still too complex. >>> >>> Something like this could be useful: >>> >>> PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf >>> PROTOTYPE_PERMS_mytweaks = 0644 >>> PROTOTYPE_CLASS_mytweaks = cswconffile >>> >>> PROTOTYPE_MODIFIERS = mytweaks >>> >>> Here, PROTOTYPE_MODIFIERS is a list of modifiers to apply where for each >>> modifier one or more fields can be changed. >> >> And >> PROTOTYPE_USER_mytweaks = myuser >> which would trigger the addition of 'ugfiles' to classes. >> >> Sounds good? +1 For the idea to introduce an easier interface to PROTOTYPE_FILTER. >>From the user's perspective, it's easier to think in terms of > accomplishing a specific task. If I want to set user/group/permissions > for a specific file, I'd find it more intuitive to use "USERGROUP" > prefix rather than "PROTOTYPE", even though it's where the tweaking > takes place under the hood. How about the following? > > USERGROUP_PASSWD = /etc/opt/csw/pkg/CSWfoo/cswusergroup > USERGROUP_MODIFIERS = mytweaks > USERGROUP_mytweaks_USER = mysql > USERGROUP_mytweaks_GROUP = mysql > USERGROUP_mytweaks_PERMS = 0700 > USERGROUP_mytweaks_FILES = /var/opt/csw/mysql5 I don't quite like the PROTOTYPE_ prefix from a user perspective when it comes to variable naming (it exposes internal details), but it feels a bit cleaner to me right now. 1) Generic: possible prototype adjustments are not restricted to USERGROUP related actions. You might only want to set the suid bit for example. 2) Consistent naming: GAR has a suffix way of declaring things right now (PKGFILES_, CATALOGNAME_, ...), which i think we should be consistent with when it comes to new features. Sebastian From skayser at opencsw.org Tue Sep 22 11:18:49 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 11:18:49 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> Message-ID: <4AB89679.1040007@opencsw.org> Maciej (Matchek) Blizinski wrote on 22.09.2009 10:02: > On Tue, Sep 22, 2009 at 8:38 AM, Peter Bonivart wrote: >> On Tue, Sep 22, 2009 at 9:30 AM, Maciej (Matchek) Blizinski >> wrote: >>> Is it CLASSES as described at [1] or SPKG_CLASSES as used in [2]? >> It's CLASSES when doing manual stuff in pkginfo and it's SPKG_CLASSES >> when using mGAR v2. But now it's even simpler to do when using GAR so >> you don't even have to bother with setting the classes. > > I've read the instructions on the and they don't seem complete to me. > There are 2 things needed to set the file ownership: > > 1. A file defining users and groups (USERGROUP = ...) > 2. A prototype with the ugfiles class > > The second bit needs to be done by filtering the prototype, is that > right? A sample piece of code: > > USERGROUP = /opt/csw/etc/pkg/CSWmysql5/cswusergroup > PROTOTYPE_FILTER = awk ' \ > $$$$3 ~ /\/var\/opt\/csw\/mysql5$$$$/ { $$$$2 = "ugfiles"; \ > $$$$4 = "0700"; \ > $$$$5 = "mysql"; \ > $$$$6 = "mysql" } \ > { print }' > SPKG_CLASSES = none ugfiles > > Without the last line (SPKG_CLASSES), my ugfiles-class file wasn't > created on the disk during package installation. Does everything works as desired with the above setup? I could see a possible problem as the USERGROUP related class which takes care of adding the user/group (cswusergroup) is automatically _appended_ to the SPKG_CLASSES variable by GAR. IIRC correctly however, it must be listed _before_ the class ugfiles class, which lists files that should have their ownership set to such newly created accounts. Sebastian From bonivart at opencsw.org Tue Sep 22 11:28:58 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 22 Sep 2009 11:28:58 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <4AB89679.1040007@opencsw.org> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <4AB89679.1040007@opencsw.org> Message-ID: <625385e30909220228oabd2ab2n3844e75489b2202b@mail.gmail.com> On Tue, Sep 22, 2009 at 11:18 AM, Sebastian Kayser wrote: > I could see a possible problem as the USERGROUP related class which > takes care of adding the user/group (cswusergroup) is automatically > _appended_ to the SPKG_CLASSES variable by GAR. > > IIRC correctly however, it must be listed _before_ the class ugfiles > class, which lists files that should have their ownership set to such > newly created accounts. Yes, you're right. The cswusergroup needs to create the user/groups before any files can be assigned to them (with ugfiles). -- /peter From skayser at opencsw.org Tue Sep 22 11:44:49 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 11:44:49 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <625385e30909220228oabd2ab2n3844e75489b2202b@mail.gmail.com> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <4AB89679.1040007@opencsw.org> <625385e30909220228oabd2ab2n3844e75489b2202b@mail.gmail.com> Message-ID: <4AB89C91.7040707@opencsw.org> Peter Bonivart wrote on 22.09.2009 11:28: > On Tue, Sep 22, 2009 at 11:18 AM, Sebastian Kayser wrote: >> I could see a possible problem as the USERGROUP related class which >> takes care of adding the user/group (cswusergroup) is automatically >> _appended_ to the SPKG_CLASSES variable by GAR. >> >> IIRC correctly however, it must be listed _before_ the class ugfiles >> class, which lists files that should have their ownership set to such >> newly created accounts. > > Yes, you're right. The cswusergroup needs to create the user/groups > before any files can be assigned to them (with ugfiles). Ok, while the ugfiles handling is not more tightly integrated into GAR (Dago, already hacking? ;), one needs to also explicitly add the cswusergroup class to SPKG_CLASSES. SPKG_CLASSES = none cswusergroup ugfiles Sebastian From dam at opencsw.org Tue Sep 22 11:58:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 11:58:45 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <4AB89C91.7040707@opencsw.org> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <4AB89679.1040007@opencsw.org> <625385e30909220228oabd2ab2n3844e75489b2202b@mail.gmail.com> <4AB89C91.7040707@opencsw.org> Message-ID: <2E8DDCE4-C585-4BD9-A627-1CAD070A48DA@opencsw.org> Hi Sebastian, Am 22.09.2009 um 11:44 schrieb Sebastian Kayser: > Peter Bonivart wrote on 22.09.2009 11:28: >> On Tue, Sep 22, 2009 at 11:18 AM, Sebastian Kayser > > wrote: >>> I could see a possible problem as the USERGROUP related class which >>> takes care of adding the user/group (cswusergroup) is automatically >>> _appended_ to the SPKG_CLASSES variable by GAR. >>> >>> IIRC correctly however, it must be listed _before_ the class ugfiles >>> class, which lists files that should have their ownership set to >>> such >>> newly created accounts. >> >> Yes, you're right. The cswusergroup needs to create the user/groups >> before any files can be assigned to them (with ugfiles). > > Ok, while the ugfiles handling is not more tightly integrated into GAR > one needs to also explicitly add the > cswusergroup class to SPKG_CLASSES. > > SPKG_CLASSES = none cswusergroup ugfiles This should be done automatically in the right order, yes. > Sebastian > (Dago, already hacking? ;) Yes, on your X11 stuff :-P From skayser at opencsw.org Tue Sep 22 12:13:22 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 12:13:22 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <2E8DDCE4-C585-4BD9-A627-1CAD070A48DA@opencsw.org> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <4AB89679.1040007@opencsw.org> <625385e30909220228oabd2ab2n3844e75489b2202b@mail.gmail.com> <4AB89C91.7040707@opencsw.org> <2E8DDCE4-C585-4BD9-A627-1CAD070A48DA@opencsw.org> Message-ID: <4AB8A342.8000905@opencsw.org> Dagobert Michelsen wrote on 22.09.2009 11:58: > Am 22.09.2009 um 11:44 schrieb Sebastian Kayser: >> Peter Bonivart wrote on 22.09.2009 11:28: >>> On Tue, Sep 22, 2009 at 11:18 AM, Sebastian Kayser >>> wrote: >>>> I could see a possible problem as the USERGROUP related class which >>>> takes care of adding the user/group (cswusergroup) is automatically >>>> _appended_ to the SPKG_CLASSES variable by GAR. >>>> >>>> IIRC correctly however, it must be listed _before_ the class ugfiles >>>> class, which lists files that should have their ownership set to >>>> such >>>> newly created accounts. >>> Yes, you're right. The cswusergroup needs to create the user/groups >>> before any files can be assigned to them (with ugfiles). >> Ok, while the ugfiles handling is not more tightly integrated into GAR >> one needs to also explicitly add the >> cswusergroup class to SPKG_CLASSES. >> >> SPKG_CLASSES = none cswusergroup ugfiles > > This should be done automatically in the right order, yes. > >> Sebastian > >> (Dago, already hacking? ;) > > Yes, on your X11 stuff :-P Hehe :) I just saw your commits, following the libXmu dependency chain, thanks alot. Very, very much appreciated. Sebastian From dam at opencsw.org Tue Sep 22 13:06:35 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 13:06:35 +0200 Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s Message-ID: Hi Sebastian, Am 22.09.2009 um 12:13 schrieb Sebastian Kayser: > Hehe :) I just saw your commits, following the libXmu dependency > chain, > thanks alot. Very, very much appreciated. You can try out libXmu on test8s now. Please let me know if it works, there are 5 packages in a row to be updated, so the full release will take some time. Best regards -- Dago From skayser at opencsw.org Tue Sep 22 14:02:49 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 14:02:49 +0200 (CEST) Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s In-Reply-To: References: Message-ID: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> Dagobert Michelsen wrote: > Am 22.09.2009 um 12:13 schrieb Sebastian Kayser: >> Hehe :) I just saw your commits, following the libXmu dependency >> chain, >> thanks alot. Very, very much appreciated. > > You can try out libXmu on test8s now. Please let me know if it > works, there are 5 packages in a row to be updated, so the full > release will take some time. Mhh, on test8s ./configure fails to find a libXaw checking for XawSimpleMenuAddGlobalActions in -lXaw -lXmu... no checking for XawSimpleMenuAddGlobalActions in -lXaw -lXpm -lXmu... no checking for XawSimpleMenuAddGlobalActions in -lXaw_s -lXmu_s... no checking for -lXaw -lXmu in /usr/contrib/X11R6... no checking for -lXaw -lXpm -lXmu in /usr/contrib/X11R6... no checking for -lXaw_s -lXmu_s in /usr/contrib/X11R6... no checking for -lXaw -lXmu in /usr/contrib/X11R5... no checking for -lXaw -lXpm -lXmu in /usr/contrib/X11R5... no checking for -lXaw_s -lXmu_s in /usr/contrib/X11R5... no checking for -lXaw -lXmu in /usr/lib/X11R5... no checking for -lXaw -lXpm -lXmu in /usr/lib/X11R5... no checking for -lXaw_s -lXmu_s in /usr/lib/X11R5... no checking for -lXaw -lXmu in /usr/local... no checking for -lXaw -lXpm -lXmu in /usr/local... no checking for -lXaw_s -lXmu_s in /usr/local... no configure: error: Unable to successfully link Athena library (-lXaw) with test program config.log holds many lines similar to configure:8632: checking for XawSimpleMenuAddGlobalActions in -lXaw -lXmu configure:8648: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 -xarch=v8 -I/opt/csw/include -I/opt/csw/include -D__EXTENSIONS__ -I/opt/csw/X11/include -L/opt/csw/X11/lib -R/opt/csw/X11/lib -xarch=v8 -L/opt/csw/lib conftest.c -lXaw -lXmu -lXext -lXt -lSM -lICE -lX11 -ltermcap -lsocket -lnsl >&5 "configure", line 8641: warning: implicit function declaration: XawSimpleMenuAddGlobalActions Undefined first referenced symbol in file XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 ld: fatal: Symbol referencing errors. No output written to conftest Why is trying to link with the stock libX11.so.4 at all (our CSW X11 doesn't have a reference to XSolarisIASetProcessInfo). Do we need a CSW libxaw also? XSolarisIASetProcessInfo is contained in the stock libXext, not in the CSW Xext for what it matters (although i don't think that makes a difference, -lXext is listed before -lX11 on the cc invocation line). skayser @ build8st ~/mgar/pkg/xterm/trunk$ nm -p /opt/csw/X11/lib/libXext.so* | grep XSolarisIASetProcessInfo skayser @ build8st ~/mgar/pkg/xterm/trunk$ nm -p /usr/openwin/lib/libXext.so* | grep XSolarisIASetProcessInfo 0000047132 T XSolarisIASetProcessInfo 0000047132 T XSolarisIASetProcessInfo Sebastian From dam at opencsw.org Tue Sep 22 15:58:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 15:58:22 +0200 Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s In-Reply-To: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> References: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> Message-ID: <288EC8C8-176E-4F74-84E2-F2D596AE86AD@opencsw.org> Hi Sebastian, Am 22.09.2009 um 14:02 schrieb Sebastian Kayser: > Mhh, on test8s ./configure fails to find a libXaw libXaw is packaged and installed on test8s. Please try again. Best regards -- Dago From daniel at opencsw.org Tue Sep 22 16:20:04 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Tue, 22 Sep 2009 15:20:04 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB24B1B.6020101@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> Message-ID: <4AB8DD14.4050606@opencsw.org> Daniel Pocock wrote: > Sebastian Kayser wrote: >> Daniel Pocock schrieb: >> > Sebastian Kayser wrote: >> >> Daniel Pocock wrote: >> >>> Thanks for all the assistance and feedback about the CSW packaging >> >> process >> >>> I've finally got the unofficial 3.1.3 code into testing now - >> feedback >> >>> is welcome >> >> your packages have the UNCOMMITED status (see their file names), which >> >> means that you had uncommitted local changes when building the >> package. >> >> UNCOMITTED packages won't be considered for the testing catalog. >> >> >> >> Issue 'svn status' to see which files are still uncomitted, take >> care of >> >> them (commit or branch if necessary), rebuild the packages and replace >> >> the >> >> current ones in /home/testing. >> > That is because I don't want to commit the checksum for >> > ganglia-3.1.3.tar.gz as it is not an official release >> > >> > There are a couple of Makefile changes that are safe to commit though. >> > I'm planning to tag 3.1.3 upstream on Friday, but I would like to get >> > feedback from OpenCSW users before I do that. >> >> You could simply create a branch to work on the upcoming release. >> >> ~/mgar/pkg/ganglia$ svn cp trunk/ branches/ganglia-3.1.3-rc >> > > Thanks for the advice about this - I have done as you suggest, and now > the new packages are in testing again > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers Ganglia 3.1.3 is now out on http://ganglia.info/testing and the version in OpenCSW testing has been updated. It is basically the same as the packages I built last week in OpenCSW testing, with two more minor patches added just before release. Has anyone tried these packages? I would appreciate some feedback before moving them to newpkgs Dago, are you happy to install them on the build farm? If so, please let me know the name of the server where ganglia_web is installed, so I can check the web interface. From dam at opencsw.org Tue Sep 22 16:26:23 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 16:26:23 +0200 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB8DD14.4050606@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> Message-ID: <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> Hi Daniel, Am 22.09.2009 um 16:20 schrieb Daniel Pocock: > Ganglia 3.1.3 is now out on http://ganglia.info/testing and the > version in OpenCSW testing has been updated. > > It is basically the same as the packages I built last week in > OpenCSW testing, with two more minor patches added just before > release. > > Has anyone tried these packages? I would appreciate some feedback > before moving them to newpkgs > > Dago, are you happy to install them on the build farm? If so, > please let me know the name of the server where ganglia_web is > installed, so I can check the web interface. Cool, would you mind writing up some mini-docs on what to install on which machine at so I can install it? Best regards -- Dago From skayser at opencsw.org Tue Sep 22 16:38:04 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 16:38:04 +0200 (CEST) Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s In-Reply-To: <288EC8C8-176E-4F74-84E2-F2D596AE86AD@opencsw.org> References: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> <288EC8C8-176E-4F74-84E2-F2D596AE86AD@opencsw.org> Message-ID: <51002.194.246.122.22.1253630284.squirrel@ssl.skayser.de> Dagobert Michelsen wrote: > Am 22.09.2009 um 14:02 schrieb Sebastian Kayser: >> Mhh, on test8s ./configure fails to find a libXaw > > libXaw is packaged and installed on test8s. Please try again. Thanks. xterm now builds without hickups on test8s. :D Would you mind placing the whole Xlibs stack that you produced today in testing/ so that i can install these pkgs on a test system and see whether they work fine with X applications that were compiled previously. Sebastian From daniel at opencsw.org Tue Sep 22 16:48:25 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Tue, 22 Sep 2009 15:48:25 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> Message-ID: <4AB8E3B9.9050302@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 22.09.2009 um 16:20 schrieb Daniel Pocock: > > Ganglia 3.1.3 is now out on http://ganglia.info/testing and the > > version in OpenCSW testing has been updated. > > > > It is basically the same as the packages I built last week in OpenCSW > > testing, with two more minor patches added just before release. > > > > Has anyone tried these packages? I would appreciate some feedback > > before moving them to newpkgs > > > > Dago, are you happy to install them on the build farm? If so, please > > let me know the name of the server where ganglia_web is installed, so > > I can check the web interface. > > Cool, would you mind writing up some mini-docs on what to install on which > machine at > > so I can install it? It's easier than that: - install ganglia_agent on every machine - install ganglia_web on the machine where you want to see the reports (it requires apache2) - probably a public web server - browse to http:///ganglia/ Everything should work automatically (after you restart apache2 perhaps, although you will see a message about that) From dam at opencsw.org Tue Sep 22 17:43:23 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 17:43:23 +0200 Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s In-Reply-To: <51002.194.246.122.22.1253630284.squirrel@ssl.skayser.de> References: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> <288EC8C8-176E-4F74-84E2-F2D596AE86AD@opencsw.org> <51002.194.246.122.22.1253630284.squirrel@ssl.skayser.de> Message-ID: <174F9942-4741-4EDA-BB7C-E4528909D62A@opencsw.org> Hi Sebastian, Am 22.09.2009 um 16:38 schrieb Sebastian Kayser: > Dagobert Michelsen wrote: >> Am 22.09.2009 um 14:02 schrieb Sebastian Kayser: >>> Mhh, on test8s ./configure fails to find a libXaw >> >> libXaw is packaged and installed on test8s. Please try again. > > Thanks. xterm now builds without hickups on test8s. :D > > Would you mind placing the whole Xlibs stack that you produced today > in > testing/ so that i can install these pkgs on a test system and see > whether > they work fine with X applications that were compiled previously. Here is a sparc-only subset, compiled on build8st, with custom-made catalog for overlay: Best regards -- Dago From dam at opencsw.org Tue Sep 22 17:50:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 17:50:32 +0200 Subject: [csw-maintainers] Fwd: X11 lib consolidation: libXmu on test8s References: <174F9942-4741-4EDA-BB7C-E4528909D62A@opencsw.org> Message-ID: <48E317B4-50CC-4E64-9C54-BC9ABFEC0288@opencsw.org> Hi Phil, Anfang der weitergeleiteten E-Mail: > Am 22.09.2009 um 16:38 schrieb Sebastian Kayser: >> Dagobert Michelsen wrote: >>> Am 22.09.2009 um 14:02 schrieb Sebastian Kayser: >>>> Mhh, on test8s ./configure fails to find a libXaw >>> >>> libXaw is packaged and installed on test8s. Please try again. >> >> Thanks. xterm now builds without hickups on test8s. :D >> >> Would you mind placing the whole Xlibs stack that you produced >> today in >> testing/ so that i can install these pkgs on a test system and see >> whether >> they work fine with X applications that were compiled previously. > > Here is a sparc-only subset, compiled on build8st, with custom-made > catalog > for overlay: > There is also an update of libxpm which you currently maintain. As it now belongs to X11 I have made a new package CSWlibxpm located in /opt/csw/X11 and a stub CSWxpm depending on it with links to the X11 libs. Additionally, it contains the pkgconfig .pc-files which are now mandatory for the depending libraries. Please take a look if this suits your needs. Best regards -- Dago From dam at opencsw.org Tue Sep 22 18:28:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 18:28:51 +0200 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB8E3B9.9050302@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> Message-ID: <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> Hi Daniel, Am 22.09.2009 um 16:48 schrieb Daniel Pocock: > Dagobert Michelsen wrote: >> Hi Daniel, >> >> Am 22.09.2009 um 16:20 schrieb Daniel Pocock: >> > Ganglia 3.1.3 is now out on http://ganglia.info/testing and the >> > version in OpenCSW testing has been updated. >> > >> > It is basically the same as the packages I built last week in >> OpenCSW >> > testing, with two more minor patches added just before release. >> > >> > Has anyone tried these packages? I would appreciate some feedback >> > before moving them to newpkgs >> > >> > Dago, are you happy to install them on the build farm? If so, >> please >> > let me know the name of the server where ganglia_web is >> installed, so >> > I can check the web interface. >> >> Cool, would you mind writing up some mini-docs on what to install >> on which >> machine at >> >> so I can install it? > > It's easier than that: > > - install ganglia_agent on every machine > > - install ganglia_web on the machine where you want to see the > reports (it requires apache2) - probably a public web server > > - browse to http:///ganglia/ > > Everything should work automatically (after you restart apache2 > perhaps, although you will see a message about that) You still have UNCOMMITTED in your package. Please commit all you have and make sure it has CSW instead in it. That way you can release the packages immediately after testing. Best regards -- Dago From daniel at opencsw.org Tue Sep 22 18:33:48 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Tue, 22 Sep 2009 17:33:48 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> Message-ID: <4AB8FC6C.9080701@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 22.09.2009 um 16:48 schrieb Daniel Pocock: >> Dagobert Michelsen wrote: >>> Hi Daniel, >>> >>> Am 22.09.2009 um 16:20 schrieb Daniel Pocock: >>> > Ganglia 3.1.3 is now out on http://ganglia.info/testing and the >>> > version in OpenCSW testing has been updated. >>> > >>> > It is basically the same as the packages I built last week in OpenCSW >>> > testing, with two more minor patches added just before release. >>> > >>> > Has anyone tried these packages? I would appreciate some feedback >>> > before moving them to newpkgs >>> > >>> > Dago, are you happy to install them on the build farm? If so, please >>> > let me know the name of the server where ganglia_web is installed, so >>> > I can check the web interface. >>> >>> Cool, would you mind writing up some mini-docs on what to install on >>> which >>> machine at >>> >>> so I can install it? >> >> It's easier than that: >> >> - install ganglia_agent on every machine >> >> - install ganglia_web on the machine where you want to see the reports >> (it requires apache2) - probably a public web server >> >> - browse to http:///ganglia/ >> >> Everything should work automatically (after you restart apache2 >> perhaps, although you will see a message about that) > > You still have UNCOMMITTED in your package. Please commit all you have > and make sure it has CSW instead in it. That way you can release the > packages immediately after testing. > It is still officially a beta until the Ganglia community endorses it as GA - usually 1-2 weeks after tagging, if no one has found a major fault. I saw a message earlier that said I can't release properly until it passes upstreams `beta' phase. Can we test it anyway, and then I will commit and put it in newpkgs when it is officially GA? From maciej at opencsw.org Tue Sep 22 18:38:04 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 17:38:04 +0100 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: <4AB89426.3090903@opencsw.org> References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> <4AB89426.3090903@opencsw.org> Message-ID: On Tue, Sep 22, 2009 at 10:08 AM, Sebastian Kayser wrote: > I don't quite like the PROTOTYPE_ prefix from a user perspective when it > comes to variable naming (it exposes internal details), but it feels a > bit cleaner to me right now. > > 1) Generic: possible prototype adjustments are not restricted to > USERGROUP related actions. You might only want to set the suid bit for > example. The values from USERGROUP_* can be passed along (aliases?) for PROTOTYPE_* variables. > 2) Consistent naming: GAR has a suffix way of declaring things right now > (PKGFILES_, CATALOGNAME_, ...), which i think we should be consistent > with when it comes to new features. The reason why I wrote USERGROUP_mytweaks_USER instead of USERGROUP_USER_mytweaks is because the latter suggests that there's "the" user for USERGROUP. Perhaps it's just me. I don't insist, anyway, I just think it's more intuitive, because it follows the logic of getting from the general to the specific: first, I know I'm going to do something with users and groups; second, I know I'm going to have a name for a specific tweak I'm doing; and third, I know what specifics is my tweak going to have. But I don't insist, if others think that suffix is better, I don't have a problem with it. It just has to be well-documented, and GAR stuff usually is well documented. (yey for the GAR Variable Reference page!) Maciej From dam at opencsw.org Tue Sep 22 18:57:21 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 18:57:21 +0200 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB8FC6C.9080701@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> <4AB8FC6C.9080701@opencsw.org> Message-ID: <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> Hi Daniel, Am 22.09.2009 um 18:33 schrieb Daniel Pocock: > It is still officially a beta until the Ganglia community endorses > it as GA - usually 1-2 weeks after tagging, if no one has found a > major fault. I saw a message earlier that said I can't release > properly until it passes upstreams `beta' phase. > > Can we test it anyway, and then I will commit and put it in newpkgs > when it is officially GA? I could if I would install the packages manually. But as we have the commit policy "commit early, commit often" there really is no need to have any package in testing with UNCOMMITTED in it as it only makes things harder. Additionally, if I want to look into your recipe I can't do that right now as you haven't committed everything. Best regards -- Dago From dam at opencsw.org Tue Sep 22 19:03:15 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 19:03:15 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> <4AB89426.3090903@opencsw.org> Message-ID: Hi Mcaiej, Am 22.09.2009 um 18:38 schrieb Maciej (Matchek) Blizinski: >> 2) Consistent naming: GAR has a suffix way of declaring things >> right now >> (PKGFILES_, CATALOGNAME_, ...), which i think we should be consistent >> with when it comes to new features. > > The reason why I wrote USERGROUP_mytweaks_USER instead of > USERGROUP_USER_mytweaks is because the latter suggests that there's > "the" user for USERGROUP. Perhaps it's just me. I don't insist, > anyway, I just think it's more intuitive, because it follows the logic > of getting from the general to the specific: first, I know I'm going > to do something with users and groups; second, I know I'm going to > have a name for a specific tweak I'm doing; and third, I know what > specifics is my tweak going to have. Right, but OTOH we currently have two types of variables with expansions in it: _ for most of them and _----... for modulations. Introducing in the middle makes it clearer in one thing and more irregular in another thing. I would prefer regularity over intuitivity. Best regards -- Dago From maciej at opencsw.org Tue Sep 22 19:55:20 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 18:55:20 +0100 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> <4AB89426.3090903@opencsw.org> Message-ID: On Tue, Sep 22, 2009 at 6:03 PM, Dagobert Michelsen wrote: > Hi Mcaiej, > > Am 22.09.2009 um 18:38 schrieb Maciej (Matchek) Blizinski: >>> >>> 2) Consistent naming: GAR has a suffix way of declaring things right now >>> (PKGFILES_, CATALOGNAME_, ...), which i think we should be consistent >>> with when it comes to new features. >> >> The reason why I wrote USERGROUP_mytweaks_USER instead of >> USERGROUP_USER_mytweaks is because the latter suggests that there's >> "the" user for USERGROUP. Perhaps it's just me. I don't insist, >> anyway, I just think it's more intuitive, because it follows the logic >> of getting from the general to the specific: first, I know I'm going >> to do something with users and groups; second, I know I'm going to >> have a name for a specific tweak I'm doing; and third, I know what >> specifics is my tweak going to have. > > Right, but OTOH we currently have two types of variables with > expansions in it: _ for most of them and > _----... for modulations. > Introducing in the middle makes it clearer in > one thing and more irregular in another thing. I would > prefer regularity over intuitivity. It would fit well with a German stereotype. ;-) Okay, so keeping it regular and subintuitive, we'd have: PROTOTYPE_MODIFIERS = mytweaks PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf PROTOTYPE_PERMS_mytweaks = 0644 PROTOTYPE_CLASS_mytweaks = cswconffile PROTOTYPE_USER_mytweaks = somebody PROTOTYPE_GROUP_mytweaks = somegroup I'm fine with the above. By the way, I'm having this problem: A line in the Makefile SAMPLECONF = $(sysconfdir)/cups/cupsd\.conf\.CSW The problem: The file in the prototype doesn't have the correct class: $ ggrep conf\\.CSW work/build-global/*prototype work/build-global/CSWcupsd.prototype:f none /etc/opt/csw/cups/cupsd.conf.CSW 0644 root bin work/build-global/prototype:f none /etc/opt/csw/cups/cupsd.conf.CSW 0644 root bin How to debug it? Maciej From skayser at opencsw.org Tue Sep 22 20:30:42 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Sep 2009 20:30:42 +0200 Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s In-Reply-To: <174F9942-4741-4EDA-BB7C-E4528909D62A@opencsw.org> References: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> <288EC8C8-176E-4F74-84E2-F2D596AE86AD@opencsw.org> <51002.194.246.122.22.1253630284.squirrel@ssl.skayser.de> <174F9942-4741-4EDA-BB7C-E4528909D62A@opencsw.org> Message-ID: <4AB917D2.7020200@opencsw.org> Dagobert Michelsen wrote on 22.09.2009 17:43: > Am 22.09.2009 um 16:38 schrieb Sebastian Kayser: >> Dagobert Michelsen wrote: >>> Am 22.09.2009 um 14:02 schrieb Sebastian Kayser: >>>> Mhh, on test8s ./configure fails to find a libXaw >>> libXaw is packaged and installed on test8s. Please try again. >> Thanks. xterm now builds without hickups on test8s. :D >> >> Would you mind placing the whole Xlibs stack that you produced today >> in >> testing/ so that i can install these pkgs on a test system and see >> whether >> they work fine with X applications that were compiled previously. > > Here is a sparc-only subset, compiled on build8st, with custom-made > catalog > for overlay: > Thanks, but my dedicated testing box at work is i386, unfortunately. Should have mentioned that earlier :/ Sebastian From maciej at opencsw.org Tue Sep 22 21:26:16 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 20:26:16 +0100 Subject: [csw-maintainers] Shared library search path with $ISALIST in the middle Message-ID: I'm working on packaging MySQL-5.0.x. I'm having a following problem: When making a 64-bit build, during the install phase, the following tree structure is being created: work/install-isa-amd64/opt/csw/mysql5/lib `-- 64 `-- mysql |-- libdbug.a |-- libheap.a |-- libmyisam.a |-- libmyisammrg.a |-- libmysqlclient.a |-- libmysqlclient.la |-- libmysqlclient.so -> libmysqlclient.so.15.0.0 |-- libmysqlclient.so.15 -> libmysqlclient.so.15.0.0 |-- libmysqlclient.so.15.0.0 |-- libmystrings.a |-- libmysys.a `-- libvio.a 2 directories, 12 files After building a package, the following files are in the package prototype: d none /opt/csw/mysql5/lib/amd64/mysql 0755 root bin s none /opt/csw/mysql5/lib/amd64/mysql/libmysqlclient.so=libmysqlclient.so.15.0.0 s none /opt/csw/mysql5/lib/amd64/mysql/libmysqlclient.so.15=libmysqlclient.so.15.0.0 f none /opt/csw/mysql5/lib/amd64/mysql/libmysqlclient.so.15.0.0 0755 root bin When running the 'mysql' binary, I'm getting an error: $ mysql ld.so.1: mysql: fatal: libmysqlclient.so.15: open failed: No such file or directory Killed The reason is that the binary is not looking into the directories containing the shared libraries. The difference is: the existing file: .../amd64/mysql/libmysqlclient.so the program is looking for: .../mysql/amd64/libmysqlclient.so Can set the runtime library path to .../amd64/mysql/libmysqlclient.so? Is the following line the right thing to do? EXTRA_LIB = /opt/csw/mysql5/lib/$$ISALIST/mysql Maciej From maciej at opencsw.org Tue Sep 22 21:50:49 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Sep 2009 20:50:49 +0100 Subject: [csw-maintainers] Shared library search path with $ISALIST in the middle In-Reply-To: References: Message-ID: On Tue, Sep 22, 2009 at 8:26 PM, Maciej (Matchek) Blizinski wrote: > Can set the runtime library path to .../amd64/mysql/libmysqlclient.so? > Is the following line the right thing to do? > > EXTRA_LIB = /opt/csw/mysql5/lib/$$ISALIST/mysql Okay, I figured that out. The answer is: yes. :-) Maciej From dam at opencsw.org Tue Sep 22 22:10:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 22:10:19 +0200 Subject: [csw-maintainers] X11 lib consolidation: libXmu on test8s In-Reply-To: <4AB917D2.7020200@opencsw.org> References: <49540.194.246.122.22.1253620969.squirrel@ssl.skayser.de> <288EC8C8-176E-4F74-84E2-F2D596AE86AD@opencsw.org> <51002.194.246.122.22.1253630284.squirrel@ssl.skayser.de> <174F9942-4741-4EDA-BB7C-E4528909D62A@opencsw.org> <4AB917D2.7020200@opencsw.org> Message-ID: <7218BE1B-147E-4F31-A5F6-05F1085B3A3B@opencsw.org> Hi Sebastian, Am 22.09.2009 um 20:30 schrieb Sebastian Kayser: > Dagobert Michelsen wrote on 22.09.2009 17:43: >> Am 22.09.2009 um 16:38 schrieb Sebastian Kayser: >>> Dagobert Michelsen wrote: >>>> Am 22.09.2009 um 14:02 schrieb Sebastian Kayser: >>>>> Mhh, on test8s ./configure fails to find a libXaw >>>> libXaw is packaged and installed on test8s. Please try again. >>> Thanks. xterm now builds without hickups on test8s. :D >>> >>> Would you mind placing the whole Xlibs stack that you produced today >>> in >>> testing/ so that i can install these pkgs on a test system and see >>> whether >>> they work fine with X applications that were compiled previously. >> >> Here is a sparc-only subset, compiled on build8st, with custom-made >> catalog >> for overlay: >> > > Thanks, but my dedicated testing box at work is i386, unfortunately. > Should have mentioned that earlier :/ I can't package that up as there currently is no test10x. Sorry. I'll package and release one-after-another then. Best regards -- Dago From dam at opencsw.org Tue Sep 22 22:20:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 22:20:55 +0200 Subject: [csw-maintainers] GAR classes list variable name In-Reply-To: References: <625385e30909220038w7789ce23tea014c4e8ee9d9a3@mail.gmail.com> <90DD6CA6-1409-4ECB-82E8-C6F9198719E3@opencsw.org> <4AB89426.3090903@opencsw.org> Message-ID: <80A6B044-67BE-4213-AD52-F20F88B9C02D@opencsw.org> Hi Maciej, Am 22.09.2009 um 19:55 schrieb Maciej (Matchek) Blizinski: > On Tue, Sep 22, 2009 at 6:03 PM, Dagobert Michelsen > wrote: >> Am 22.09.2009 um 18:38 schrieb Maciej (Matchek) Blizinski: >>>> 2) Consistent naming: GAR has a suffix way of declaring things >>>> right now >>>> (PKGFILES_, CATALOGNAME_, ...), which i think we should be >>>> consistent >>>> with when it comes to new features. >>> >>> The reason why I wrote USERGROUP_mytweaks_USER instead of >>> USERGROUP_USER_mytweaks is because the latter suggests that there's >>> "the" user for USERGROUP. Perhaps it's just me. I don't insist, >>> anyway, I just think it's more intuitive, because it follows the >>> logic >>> of getting from the general to the specific: first, I know I'm going >>> to do something with users and groups; second, I know I'm going to >>> have a name for a specific tweak I'm doing; and third, I know what >>> specifics is my tweak going to have. >> >> Right, but OTOH we currently have two types of variables with >> expansions in it: _ for most of them and >> _----... for modulations. >> Introducing in the middle makes it clearer in >> one thing and more irregular in another thing. I would >> prefer regularity over intuitivity. > > It would fit well with a German stereotype. ;-) I TEK DIS AS KOMPLIMENT, YES :-D > Okay, so keeping it regular and subintuitive, we'd have: > > PROTOTYPE_MODIFIERS = mytweaks > PROTOTYPE_FILES_mytweaks = $(bindir)/.*\.conf > PROTOTYPE_PERMS_mytweaks = 0644 > PROTOTYPE_CLASS_mytweaks = cswconffile > PROTOTYPE_USER_mytweaks = somebody > PROTOTYPE_GROUP_mytweaks = somegroup and possibly PROTOTYPE_FTYPE_mytweaks = e I guess we won't have many devices, so no need to bother. > I'm fine with the above. > > By the way, I'm having this problem: > > A line in the Makefile > SAMPLECONF = $(sysconfdir)/cups/cupsd\.conf\.CSW > > The problem: The file in the prototype doesn't have the correct class: > $ ggrep conf\\.CSW work/build-global/*prototype > work/build-global/CSWcupsd.prototype:f none > /etc/opt/csw/cups/cupsd.conf.CSW 0644 root bin > work/build-global/prototype:f none /etc/opt/csw/cups/cupsd.conf.CSW > 0644 root bin > > How to debug it? Try DEBUG_PACKAGING=1 gmake repackage and see what is executed during prototype filtering. Best regards -- Dago From dam at opencsw.org Tue Sep 22 22:21:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Sep 2009 22:21:49 +0200 Subject: [csw-maintainers] Shared library search path with $ISALIST in the middle In-Reply-To: References: Message-ID: <69FF07E5-B559-4702-9FCD-75DFF992ABA9@opencsw.org> Hi Maciej, Am 22.09.2009 um 21:50 schrieb Maciej (Matchek) Blizinski: > On Tue, Sep 22, 2009 at 8:26 PM, Maciej (Matchek) Blizinski > wrote: >> Can set the runtime library path to .../amd64/mysql/ >> libmysqlclient.so? >> Is the following line the right thing to do? >> >> EXTRA_LIB = /opt/csw/mysql5/lib/$$ISALIST/mysql > > Okay, I figured that out. The answer is: yes. :-) Yes. That is exactly what EXTRA_LIB is for :-) Best regards -- Dago From william at wbonnet.net Wed Sep 23 00:10:40 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 23 Sep 2009 00:10:40 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates Message-ID: <4AB94B60.7010704@wbonnet.net> Hi The following packages have been updated or added to testing New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-i386-CSW.pkg.gz New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-sparc-CSW.pkg.gz New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz Feedbacks are welcome cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From phil at bolthole.com Wed Sep 23 00:27:01 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 22 Sep 2009 15:27:01 -0700 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4AB94B60.7010704@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> Message-ID: Dago and I were just exchanging emails. We came to the agreement, that packages containing "Xorg/X11 prototypes", should get standardized by naming them x[software]proto rather than just [software]proto the idea being, that way they'll sort nicer,and be more obviously identifyable. On Tue, Sep 22, 2009 at 3:10 PM, William Bonnet wrote: > Hi > > The following packages have been updated or added to testing > > New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz > New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz > Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz > Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz > New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-i386-CSW.pkg.gz > New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-sparc-CSW.pkg.gz > New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz > New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz > Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz > Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz > From william at wbonnet.net Wed Sep 23 08:00:26 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 23 Sep 2009 08:00:26 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> Message-ID: <4AB9B97A.800@wbonnet.net> Hi > the idea being, that way they'll sort nicer,and be more obviously identifyable. > I was waiting for your confirmation :) I'll rename the packages tonight before cheers W. > > > On Tue, Sep 22, 2009 at 3:10 PM, William Bonnet wrote: > >> Hi >> >> The following packages have been updated or added to testing >> >> New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-i386-CSW.pkg.gz >> New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-sparc-CSW.pkg.gz >> New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> >> > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > > > -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From dam at opencsw.org Wed Sep 23 08:17:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 23 Sep 2009 08:17:31 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> Message-ID: <6CC4D56C-2812-4B65-87EE-45D7CE36A802@opencsw.org> Hi William, Am 23.09.2009 um 00:27 schrieb Philip Brown: > Dago and I were just exchanging emails. > > We came to the agreement, that packages containing "Xorg/X11 > prototypes", should get standardized by naming them > > x[software]proto > > rather than just > > [software]proto > > > the idea being, that way they'll sort nicer,and be more obviously > identifyable. > > > > On Tue, Sep 22, 2009 at 3:10 PM, William Bonnet > wrote: >> Hi >> >> The following packages have been updated or added to testing >> >> New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-i386-CSW.pkg.gz >> New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-sparc-CSW.pkg.gz >> New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >> Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >> Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz Yes, it would be more consistent to have a mapping like this to make clear that the packages are x-related: Am 22.09.2009 um 23:45 schrieb Philip Brown: > On Tue, Sep 22, 2009 at 1:09 PM, Dagobert Michelsen > wrote: >> >> That means >> >> glproto -> xglproto >> inputproto -> xinputproto >> kbproto -> xkbproto >> recordproto -> xrecordproto >> renderproto -> xrenderproto >> videoproto -> xvideoproto >> xcb-proto -> SAME >> xextproto -> SAME >> xproto -> SAME >> >> OK? > > Yeah. > > Please remind me when the renames come up. Best regards -- Dago From dam at opencsw.org Wed Sep 23 08:30:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 23 Sep 2009 08:30:02 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4AB9B97A.800@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> Message-ID: Hi William, Am 23.09.2009 um 08:00 schrieb William Bonnet: >> the idea being, that way they'll sort nicer,and be more obviously >> identifyable. >> > > I was waiting for your confirmation :) > > I'll rename the packages tonight before >> On Tue, Sep 22, 2009 at 3:10 PM, William Bonnet >> wrote: >>> The following packages have been updated or added to testing >>> >>> New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >>> New : fontsproto-2.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >>> Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >>> Update : inputproto-1.5.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >>> New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-i386-CSW.pkg.gz >>> New : printproto-1.0.4,REV=2009.09.23-SunOS5.8-sparc-CSW.pkg.gz >>> New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >>> New : resourceproto-1.1.0,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz >>> Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-i386-CSW.pkg.gz >>> Update : xextproto-7.1.1,REV=2009.09.22-SunOS5.8-sparc-CSW.pkg.gz Very nice. Please keep in mind to also update the requirements of the other packages to accomodate for the changed name. It may be best to rename all at once and release the whole stack with updated dependencies in one large block to avoid re-releases of the same package again and again if it is dependent on multiple protos. Best regards -- Dago From skayser at opencsw.org Wed Sep 23 10:37:28 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 23 Sep 2009 10:37:28 +0200 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> Message-ID: <4AB9DE48.8060006@opencsw.org> Philip Brown wrote on 24.08.2009 21:01: > On Mon, Aug 24, 2009 at 12:27 AM, Maciej (Matchek) Blizinski > > wrote: > > +1 > > pyantlrrt --> py_antlrrt > pyyaml --> py_yaml > > How do we go about the change? Modify catalogname without touching > pkgname? Will the usual pkg-get/pkgutil update do the right thing? > > dependancies are based on CSWname, not software name, so it should "do > the right thing". The places where it will break, are where admins may > have saved procedures, that do things like: > > machine1$ pkg-get -l >save-list > #time passes... > machine2$ pkg-get -i `cat save-list` > > Not to mention, changing softwarename is kinda a pain for me to deal > with. But if there are "only a few", then all right. > > WITH THE EXCEPTION that, as someone noted, things with actual recognized > name of "pyfoo", should REMAIN "pyfoo", not be artificially split to be > "py_foo" in that case. I was just about to file the bugs against packages which don't have the py_ prefix. Just wanted to make sure we have reached a consensus here so that i file the bugs against the right set of packages: - python programs with a recognized name can/should be left as is - python libraries will be prefixed with py_ Resuming the pyyaml example: pyyaml is a library (python modules only), thus the software name would be py_yaml. This is similar to Debian's policy [1], just that they prefix module packages with "python-". In their case, pyyaml is packaged as python-yaml [2]. Sebastian [1]http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names [2]http://packages.debian.org/lenny/python-yaml From maciej at opencsw.org Wed Sep 23 10:38:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 09:38:46 +0100 Subject: [csw-maintainers] SAMPLECONF = $(sysconfdir)/foo\.conf issues Message-ID: On Tue, Sep 22, 2009 at 9:20 PM, Dagobert Michelsen wrote: >> By the way, I'm having this problem: >> >> A line in the Makefile >> SAMPLECONF = $(sysconfdir)/cups/cupsd\.conf\.CSW >> >> The problem: The file in the prototype doesn't have the correct class: >> $ ggrep conf\\.CSW work/build-global/*prototype >> work/build-global/CSWcupsd.prototype:f none >> /etc/opt/csw/cups/cupsd.conf.CSW 0644 root bin >> work/build-global/prototype:f none /etc/opt/csw/cups/cupsd.conf.CSW >> 0644 root bin >> >> How to debug it? > > Try > DEBUG_PACKAGING=1 gmake repackage > and see what is executed during prototype filtering. I tried a few combinations of "." and "\."; I then took a look at the output. 1. SAMPLECONF = $(sysconfdir)/cupsd\.conf\.CSW | perl -ane ' $F[1] = "cswcpsampleconf" if ( $F[2] =~ m(^/etc/opt/csw/cupsd\.conf\\.CSW$) ); Doesn't work. 2. SAMPLECONF = $(sysconfdir)/cupsd.conf.CSW | perl -ane ' $F[1] = "cswcpsampleconf" if ( $F[2] =~ m(^/etc/opt/csw/cupsd.conf\.CSW$) ); Does work (the class is being set). It doesn't seem quite right. If the value of SAMPLECONF is a regex, there should be no later backslash additions. If it's not a regex, backslashes should be added to all the dots (or other special characters). Maciej From maciej at opencsw.org Wed Sep 23 11:23:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 10:23:01 +0100 Subject: [csw-maintainers] The source code of www.opencsw.org In-Reply-To: References: <20090723220149.GB8541@bolthole.com> <4A6979F4.5050904@opencsw.org> <20090724160343.GC91227@bolthole.com> <4A6B4DFE.1050307@opencsw.org> <20090725203035.GA24170@bolthole.com> <4A6C2341.8060600@opencsw.org> <20090726154345.GB28096@bolthole.com> Message-ID: Re: http://www.opencsw.org/mantis/view.php?id=3459#c6709 The irforceready mirrors from our mirrors subpage currently point at Blastwave mirrors. I'm not going to propose a change*, because the administrative overhead is going to by far surpass the amount of work needed to fix the issue, so I'm only mentioning it here. Maciej * See how careful I am not to say "send a patch"? From dam at opencsw.org Wed Sep 23 12:26:28 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 12:26:28 +0200 (CEST) Subject: [csw-maintainers] SAMPLECONF = $(sysconfdir)/foo\.conf issues In-Reply-To: References: Message-ID: Hi Maciej, > I tried a few combinations of "." and "\."; I then took a look at the > output. > > 1. > SAMPLECONF = $(sysconfdir)/cupsd\.conf\.CSW > | perl -ane ' $F[1] = "cswcpsampleconf" if ( $F[2] =~ > m(^/etc/opt/csw/cupsd\.conf\\.CSW$) ); > > Doesn't work. > > 2. > SAMPLECONF = $(sysconfdir)/cupsd.conf.CSW > | perl -ane ' $F[1] = "cswcpsampleconf" if ( $F[2] =~ > m(^/etc/opt/csw/cupsd.conf\.CSW$) ); > > Does work (the class is being set). > > It doesn't seem quite right. If the value of SAMPLECONF is a regex, > there should be no later backslash additions. If it's not a regex, > backslashes should be added to all the dots (or other special > characters). This was a bug. It should be regular expressions, so 1. is correct. The bug was introduced was I autodetected if the file has a .CSW-suffix or not. It is fixed now in r6425, please verify. Thanks for the report! -- Dago From daniel at opencsw.org Wed Sep 23 12:54:28 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 23 Sep 2009 11:54:28 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> <4AB8FC6C.9080701@opencsw.org> <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> Message-ID: <4AB9FE64.1040209@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 22.09.2009 um 18:33 schrieb Daniel Pocock: >> It is still officially a beta until the Ganglia community endorses it >> as GA - usually 1-2 weeks after tagging, if no one has found a major >> fault. I saw a message earlier that said I can't release properly >> until it passes upstreams `beta' phase. >> >> Can we test it anyway, and then I will commit and put it in newpkgs >> when it is officially GA? > > I could if I would install the packages manually. But as we have the > commit policy "commit early, commit often" there really is no need to > have any package in testing with UNCOMMITTED in it as it only makes > things harder. Additionally, if I want to look into your recipe I can't > do that right now as you haven't committed everything. > Ok, I have now committed them on a branch and put them in testing again - please let me know which host you put the web package on so I can check it From daniel at opencsw.org Wed Sep 23 13:06:02 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 23 Sep 2009 12:06:02 +0100 Subject: [csw-maintainers] Using a package from current on stable Message-ID: <4ABA011A.8070809@opencsw.org> The Ganglia package I've been working with works on a wide range of architectures. I thought I would try to install the package on a Solaris 8 system with OpenCSW stable instead of current Two issues arise: - cswclassutils is missing on stable - expat.so.0 on stable, expat.so.1 expected for current Therefore, I suspect I need to - copy some additional things, e.g. cswclassutils, to the system where I want Ganglia - rebuild my package for stable's library versions - how do I tell gar to do that? Given that my package is a new package and doesn't impact any other packages, are there any other steps I need to take to make it suitable for an upcoming stable release? Will the use of cswclassutils prevent me from having the package in stable? From maciej at opencsw.org Wed Sep 23 13:17:40 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 12:17:40 +0100 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: <1251678005-sup-226@ntdws12.chass.utoronto.ca> References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <9D015FAC-931C-4DD3-A4AB-CC1AB214E9A9@opencsw.org> <7F956EB7-8E18-4052-B985-D360956F8626@opencsw.org> <1251391060-sup-388@ntdws12.chass.utoronto.ca> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> Message-ID: The packages have been built and they've been sitting in testing/ for a while now. I'd like to have them released, but there's a problem with dependent applications. Shared libraries in the updated wxwidgets packages have different file names than the version currently present on the mirrors. http://www.opencsw.org/search/wxwidgets_gtk2 contains *.so.0.2.0 The newly built package contains *.so.0.6.0. It breaks dependent applications: xchm, rapidsvn, kicad, boincmanager. What's the strategy in such a case? Should I notify the maintainers of the dependent packages and release the updated packages simultaneously? It's a nice idea, but they won't be able to build updated packages until new wxwidgets is released (only released packages are installed on build{8,9,10}{s,x}). Maciej From dam at opencsw.org Wed Sep 23 13:22:12 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 13:22:12 +0200 (CEST) Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AB9FE64.1040209@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> <4AB8FC6C.9080701@opencsw.org> <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> <4AB9FE64.1040209@opencsw.org> Message-ID: <401706fb05cc9ff2d546e8853671259e.squirrel@mail.opencsw.org> Hi Daniel, > Dagobert Michelsen wrote: >> Am 22.09.2009 um 18:33 schrieb Daniel Pocock: >>> It is still officially a beta until the Ganglia community endorses it >>> as GA - usually 1-2 weeks after tagging, if no one has found a major >>> fault. I saw a message earlier that said I can't release properly >>> until it passes upstreams `beta' phase. >>> >>> Can we test it anyway, and then I will commit and put it in newpkgs >>> when it is officially GA? >> >> I could if I would install the packages manually. But as we have the >> commit policy "commit early, commit often" there really is no need to >> have any package in testing with UNCOMMITTED in it as it only makes >> things harder. Additionally, if I want to look into your recipe I can't >> do that right now as you haven't committed everything. > > Ok, I have now committed them on a branch and put them in testing again > - please let me know which host you put the web package on so I can check > it Great. However, I have some trouble activating it due to the vhost-configuration of buildfarm.opencsw.org. I'll have a deeper look later on... Best regards -- Dago From dam at opencsw.org Wed Sep 23 13:25:16 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 13:25:16 +0200 (CEST) Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <9D015FAC-931C-4DD3-A4AB-CC1AB214E9A9@opencsw.org> <7F956EB7-8E18-4052-B985-D360956F8626@opencsw.org> <1251391060-sup-388@ntdws12.chass.utoronto.ca> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> Message-ID: Hi Maciej, > The packages have been built and they've been sitting in testing/ for > a while now. I'd like to have them released, but there's a problem > with dependent applications. Shared libraries in the updated wxwidgets > packages have different file names than the version currently present > on the mirrors. > > http://www.opencsw.org/search/wxwidgets_gtk2 contains *.so.0.2.0 > The newly built package contains *.so.0.6.0. > > It breaks dependent applications: xchm, rapidsvn, kicad, boincmanager. > > What's the strategy in such a case? Should I notify the maintainers of > the dependent packages and release the updated packages > simultaneously? It's a nice idea, but they won't be able to build > updated packages until new wxwidgets is released (only released > packages are installed on build{8,9,10}{s,x}). You can either put the original legacy libraries in there "manually" during post-install (see curl for an example) or use version modulations to also build the old version and put only the libs in the package (see expat/flac/neon/readline for examples). Best regards -- Dago From james at opencsw.org Wed Sep 23 13:26:12 2009 From: james at opencsw.org (James Lee) Date: Wed, 23 Sep 2009 11:26:12 GMT Subject: [csw-maintainers] Using a package from current on stable In-Reply-To: <4ABA011A.8070809@opencsw.org> References: <4ABA011A.8070809@opencsw.org> Message-ID: <20090923.11261200.3107154672@gyor.oxdrove.co.uk> On 23/09/09, 12:06:02, Daniel Pocock wrote regarding [csw-maintainers] Using a package from current on stable: > Given that my package is a new package and doesn't impact any other > packages, are there any other steps I need to take to make it suitable > for an upcoming stable release? Will the use of cswclassutils prevent > me from having the package in stable? No. The supporting packages would also need to be stable but in this case that would happen. Stable is produced as a snapshot, mainly because it's too hard to do anything else, hence the supporting cast are also promoted. It is possible to prune unsuitable branches but where the interdependence is high the whole snapshot has to be ready (please will someone fix the BDB mess...). If your package is new it would be pruned from the stable snapshot anyway. It needs a "burn in" period in unstable. Interdependence and affidavits can affect the grace period. James. From daniel at opencsw.org Wed Sep 23 13:31:03 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 23 Sep 2009 12:31:03 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <401706fb05cc9ff2d546e8853671259e.squirrel@mail.opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> <4AB8FC6C.9080701@opencsw.org> <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> <4AB9FE64.1040209@opencsw.org> <401706fb05cc9ff2d546e8853671259e.squirrel@mail.opencsw.org> Message-ID: <4ABA06F7.404@opencsw.org> dam at opencsw.org wrote: > Hi Daniel, > >> Dagobert Michelsen wrote: >>> Am 22.09.2009 um 18:33 schrieb Daniel Pocock: >>>> It is still officially a beta until the Ganglia community endorses it >>>> as GA - usually 1-2 weeks after tagging, if no one has found a major >>>> fault. I saw a message earlier that said I can't release properly >>>> until it passes upstreams `beta' phase. >>>> >>>> Can we test it anyway, and then I will commit and put it in newpkgs >>>> when it is officially GA? >>> I could if I would install the packages manually. But as we have the >>> commit policy "commit early, commit often" there really is no need to >>> have any package in testing with UNCOMMITTED in it as it only makes >>> things harder. Additionally, if I want to look into your recipe I can't >>> do that right now as you haven't committed everything. >> Ok, I have now committed them on a branch and put them in testing again >> - please let me know which host you put the web package on so I can check >> it > > Great. However, I have some trouble activating it due to the > vhost-configuration of buildfarm.opencsw.org. I'll have a deeper look > later on... > Even without running the web interface, you can still install the ganglia_agent package on all the machines you want to watch, and test it with this command: nc localhost 8649 | grep ^.[CH] The output should be a list of those hosts sending metrics on the same multicast group as the agent on localhost. From dam at opencsw.org Wed Sep 23 13:31:07 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 13:31:07 +0200 (CEST) Subject: [csw-maintainers] Using a package from current on stable In-Reply-To: <4ABA011A.8070809@opencsw.org> References: <4ABA011A.8070809@opencsw.org> Message-ID: Hi Daniel, > The Ganglia package I've been working with works on a wide range of > architectures. I thought I would try to install the package on a > Solaris 8 system with OpenCSW stable instead of current FYI: Adding newer packages to stable is not supported and newer packages will not be added to stable. A stable release is made from current during a release-freeze with thourough package inspection. An update of stable is pending and there is no date for an update. James, out stable release manager, made some progress towards a new stable, but due to time constraints there is no timeframe. > Two issues arise: > - cswclassutils is missing on stable > - expat.so.0 on stable, expat.so.1 expected for current > > Therefore, I suspect I need to > > - copy some additional things, e.g. cswclassutils, to the system where I > want Ganglia If you want to poach your stable installation you can do that. > - rebuild my package for stable's library versions - how do I tell gar > to do that? You don't, as new packages are always build against current. > Given that my package is a new package and doesn't impact any other > packages, are there any other steps I need to take to make it suitable > for an upcoming stable release? Will the use of cswclassutils prevent > me from having the package in stable? If a new stable release is made and your package has been released to current at that time and has no open critical bugs it will go automatically into stable. The delay of a new stable release is painful, but we don't have that many people having the infrastrastructure, time and knowledge to do it. Best regards -- Dago From maciej at opencsw.org Wed Sep 23 13:38:15 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 12:38:15 +0100 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <7F956EB7-8E18-4052-B985-D360956F8626@opencsw.org> <1251391060-sup-388@ntdws12.chass.utoronto.ca> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Sep 23, 2009 at 12:25 PM, wrote: > You can either put the original legacy libraries in there "manually" > during post-install (see curl for an example) or use version modulations > to also build the old version and put only the libs in the package > (see expat/flac/neon/readline for examples). I see, version modulations. Is it a one-way process only? I mean, this way the list of package versions is going to be growing indefinitely, unless there's a process in place to phase out the old versions. One more question: If two versions of a library are installed on one system, which one is being used during linking? Maciej From dam at opencsw.org Wed Sep 23 13:40:02 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 13:40:02 +0200 (CEST) Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4ABA06F7.404@opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> <4AB8FC6C.9080701@opencsw.org> <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> <4AB9FE64.1040209@opencsw.org> <401706fb05cc9ff2d546e8853671259e.squirrel@mail.opencsw.org> <4ABA06F7.404@opencsw.org> Message-ID: <6980adcb9c4d857182877ed5d04a5617.squirrel@mail.opencsw.org> Hi Daniel, > Even without running the web interface, you can still install the > ganglia_agent package on all the machines you want to watch, and test it > with this command: > > nc localhost 8649 | grep ^.[CH] > > The output should be a list of those hosts sending metrics on the same > multicast group as the agent on localhost. At least on build8st it is not working: build8st# sh -x /etc/init.d/cswgmond start GANGLIA_BASEDIR=/opt/csw GMOND=/opt/csw/sbin/gmond GMOND_CONF=/etc/opt/csw/ganglia/gmond.conf + test -f /etc/default/gmond + [ ! -d /opt/csw ] + /opt/csw/sbin/gmond -c /etc/opt/csw/ganglia/gmond.conf ioctl error: No such device or address 19378: time() = 1253705957 19378: ioctl(3, KSTAT_IOC_CHAIN_ID, 0x00000000) = 46533 19378: so_socket(2, 1, 0, "", 1) = 4 19378: ioctl(4, 0xC0086914, 0xFFBFF9A8) = 0 19378: ioctl(4, 0xC0086914, 0xFFBFF9A8) = 0 19378: ioctl(4, 0xC0206911, 0xFFBFF974) Err#6 ENXIO ioctl error: No such device or address 19378: write(2, " i o c t l e r r o r :".., 39) = 39 19378: munmap(0xFECB0000, 24302) = 0 I have not configured anything apart from installing the package. Best regards -- Dago From dam at opencsw.org Wed Sep 23 13:43:17 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 13:43:17 +0200 (CEST) Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <7F956EB7-8E18-4052-B985-D360956F8626@opencsw.org> <1251391060-sup-388@ntdws12.chass.utoronto.ca> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> Message-ID: Hi Maciej, > On Wed, Sep 23, 2009 at 12:25 PM, wrote: >> You can either put the original legacy libraries in there "manually" >> during post-install (see curl for an example) or use version modulations >> to also build the old version and put only the libs in the package >> (see expat/flac/neon/readline for examples). > > I see, version modulations. Is it a one-way process only? I mean, this > way the list of package versions is going to be growing indefinitely, > unless there's a process in place to phase out the old versions. No. After the updated package has been released you file the bugs to the packages depending on the old libs :-) After the last one has been updated you remove them from your package. > One more question: If two versions of a library are installed on one > system, which one is being used during linking? Usually the latest as it is detected during autoconf/libtool/pkgconfig etc. I never had a problem with adding old libs for new compiles. Best regards -- Dago From daniel at opencsw.org Wed Sep 23 13:44:13 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 23 Sep 2009 12:44:13 +0100 Subject: [csw-maintainers] Using a package from current on stable In-Reply-To: References: <4ABA011A.8070809@opencsw.org> Message-ID: <4ABA0A0D.1040603@opencsw.org> dam at opencsw.org wrote: > Hi Daniel, > >> The Ganglia package I've been working with works on a wide range of >> architectures. I thought I would try to install the package on a >> Solaris 8 system with OpenCSW stable instead of current > > FYI: Adding newer packages to stable is not supported and newer packages > will not be added to stable. A stable release is made from current during > a release-freeze with thourough package inspection. An update of stable is > pending and there is no date for an update. > > James, out stable release manager, made some progress towards a new > stable, but due to time constraints there is no timeframe. > >> Two issues arise: >> - cswclassutils is missing on stable >> - expat.so.0 on stable, expat.so.1 expected for current >> >> Therefore, I suspect I need to >> >> - copy some additional things, e.g. cswclassutils, to the system where I >> want Ganglia > > If you want to poach your stable installation you can do that. > >> - rebuild my package for stable's library versions - how do I tell gar >> to do that? > > You don't, as new packages are always build against current. > >> Given that my package is a new package and doesn't impact any other >> packages, are there any other steps I need to take to make it suitable >> for an upcoming stable release? Will the use of cswclassutils prevent >> me from having the package in stable? > > If a new stable release is made and your package has been released to current > at that time and has no open critical bugs it will go automatically into > stable. > > The delay of a new stable release is painful, but we don't have that many > people having the infrastrastructure, time and knowledge to do it. > I understand that OpenCSW can't endorse a package and put it in stable without following the correct process - otherwise, there would just be anarchy However, if someone wants to distribute a package through a third party download site (e.g. the upstream download page on SF), and they want their package to just drop in to stable, is that permitted? Is there a convenient way to build such a package with gar on the build farm? From james at opencsw.org Wed Sep 23 13:44:16 2009 From: james at opencsw.org (James Lee) Date: Wed, 23 Sep 2009 11:44:16 GMT Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <7F956EB7-8E18-4052-B985-D360956F8626@opencsw.org> <1251391060-sup-388@ntdws12.chass.utoronto.ca> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> Message-ID: <20090923.11441600.3790365392@gyor.oxdrove.co.uk> On 23/09/09, 12:38:15, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] Anyone wants to update wxWidgets?: > One more question: If two versions of a library are installed on one > system, which one is being used during linking? The one pointed to by (or that is) .so /opt/csw/lib/libjpeg.so.62.0.0 /opt/csw/lib/libjpeg.so.62=libjpeg.so.62.0.0 /opt/csw/lib/libjpeg.so.7.0.0 /opt/csw/lib/libjpeg.so.7=libjpeg.so.7.0.0 /opt/csw/lib/libjpeg.so=libjpeg.so.7.0.0 at link libjpeg.so uses .so.7 not .62 SONAME is used at run time. James. From daniel at opencsw.org Wed Sep 23 13:49:56 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 23 Sep 2009 12:49:56 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <6980adcb9c4d857182877ed5d04a5617.squirrel@mail.opencsw.org> References: <4AB021F6.3050505@opencsw.org> <56219.194.246.122.22.1253116102.squirrel@ssl.skayser.de> <4AB10A8D.2040504@opencsw.org> <52051.194.246.122.22.1253117733.squirrel@ssl.skayser.de> <4AB24B1B.6020101@opencsw.org> <4AB8DD14.4050606@opencsw.org> <62AECFBB-F8B9-41CE-AE0D-2CC770183B9B@opencsw.org> <4AB8E3B9.9050302@opencsw.org> <33F0BBC5-14C1-4AFB-B1D7-91045685CF73@opencsw.org> <4AB8FC6C.9080701@opencsw.org> <8D6287B1-0C03-44C0-93F2-8DC4A0F3A025@opencsw.org> <4AB9FE64.1040209@opencsw.org> <401706fb05cc9ff2d546e8853671259e.squirrel@mail.opencsw.org> <4ABA06F7.404@opencsw.org> <6980adcb9c4d857182877ed5d04a5617.squirrel@mail.opencsw.org> Message-ID: <4ABA0B64.40202@opencsw.org> dam at opencsw.org wrote: > Hi Daniel, > >> Even without running the web interface, you can still install the >> ganglia_agent package on all the machines you want to watch, and test it >> with this command: >> >> nc localhost 8649 | grep ^.[CH] >> >> The output should be a list of those hosts sending metrics on the same >> multicast group as the agent on localhost. > > At least on build8st it is not working: > > build8st# sh -x /etc/init.d/cswgmond start > GANGLIA_BASEDIR=/opt/csw > GMOND=/opt/csw/sbin/gmond > GMOND_CONF=/etc/opt/csw/ganglia/gmond.conf > + test -f /etc/default/gmond > + [ ! -d /opt/csw ] > + /opt/csw/sbin/gmond -c /etc/opt/csw/ganglia/gmond.conf > ioctl error: No such device or address > > 19378: time() = 1253705957 > 19378: ioctl(3, KSTAT_IOC_CHAIN_ID, 0x00000000) = 46533 > 19378: so_socket(2, 1, 0, "", 1) = 4 > 19378: ioctl(4, 0xC0086914, 0xFFBFF9A8) = 0 > 19378: ioctl(4, 0xC0086914, 0xFFBFF9A8) = 0 > 19378: ioctl(4, 0xC0206911, 0xFFBFF974) Err#6 ENXIO > ioctl error: No such device or address > 19378: write(2, " i o c t l e r r o r :".., 39) = 39 > 19378: munmap(0xFECB0000, 24302) = 0 > > > I have not configured anything apart from installing the package. > Does the machine have a default route, or a route for 224.0.0.0/4? I've seen reports of problems on such machines. Can you try route add -host 239.2.11.71 dev ??? I can't ssh to build8st - it prompts me for a password, my key is not accepted - can you help me get on the machine? If that route command fixes it, do you think this is something that should be changed from preinstall, or just warn the user and let them fix it? From dam at opencsw.org Wed Sep 23 13:52:53 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 13:52:53 +0200 (CEST) Subject: [csw-maintainers] Using a package from current on stable In-Reply-To: <4ABA0A0D.1040603@opencsw.org> References: <4ABA011A.8070809@opencsw.org> <4ABA0A0D.1040603@opencsw.org> Message-ID: <8b097644ac93777fb96e2d225cf86c0a.squirrel@mail.opencsw.org> Hi Daniel, > However, if someone wants to distribute a package through a third party > download site (e.g. the upstream download page on SF), and they want > their package to just drop in to stable, is that permitted? Is there a > convenient way to build such a package with gar on the build farm? Difficult. The package will not be added to stable, but will become a part of stable in the next release. If you want to offer a binary package I would offer it for current. Because there is nothing added directly to stable there is no point in building a package against stable. It would require having at least Solaris 8 Sparc, Solaris 8 x86 and Solaris 10 x86 on stable/, which we don't have on the farm. But if you insist you can make your own farm and use your GAR build description to do it, but I wouldn't that consider a good idea. The best thing I can propose if you want your package in stable is test it good, release it to current and help in the next release of stable. That way everyone can gain from the work put into it. Best regards -- Dago From william at wbonnet.net Wed Sep 23 12:43:53 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 23 Sep 2009 12:43:53 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> Message-ID: <4AB9FBE9.8000908@wbonnet.net> Hi After having some talk with Sebastian, i have the folowwing proposition. Since we are renaming some of the X11 packages to add a prefix, and about to do some mass change. What about adding a more explicit prefix ? For instance fooproto could be renamed to : a/ xfooxproto b/ x11-fooproto c/ x11proto-foo d/ x11proto-foo-devel Current proposition is a. My choice goes to d. I would like to also add the -devel suffix since it is a true devel package cheers W. From william at wbonnet.net Wed Sep 23 13:07:02 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 23 Sep 2009 13:07:02 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4AB9FBE9.8000908@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4AB9FBE9.8000908@wbonnet.net> Message-ID: <4ABA0156.2000303@wbonnet.net> Hi I resend it since it seems it was not correctly transmitted cheers W. > After having some talk with Sebastian, i have the folowwing > proposition. Since we are renaming some of the X11 packages to add a > prefix, and about to do some mass change. What about adding a more > explicit prefix ? > > For instance fooproto could be renamed to : > > a/ xfooxproto > b/ x11-fooproto > c/ x11proto-foo > d/ x11proto-foo-devel > > Current proposition is a. My choice goes to d. I would like to also > add the -devel suffix since it is a true devel package > > cheers > W. > > From dam at opencsw.org Wed Sep 23 14:07:07 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Wed, 23 Sep 2009 14:07:07 +0200 (CEST) Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4AB9FBE9.8000908@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4AB9FBE9.8000908@wbonnet.net> Message-ID: <5a783a504774d077b080a509285dce93.squirrel@mail.opencsw.org> Hi William, > After having some talk with Sebastian, i have the folowwing proposition. > Since we are renaming some of the X11 packages to add a prefix, and > about to do some mass change. What about adding a more explicit prefix ? > > For instance fooproto could be renamed to : > > a/ xfooxproto > b/ x11-fooproto > c/ x11proto-foo > d/ x11proto-foo-devel > > Current proposition is a. My choice goes to d. I would like to also add > the -devel suffix since it is a true devel package Are these catalog- or package-names? catalogname usually contain _ instead of -, and the current standard uses CSWfoodevel instead of CSWfoo-devel. That would mean a/ xfooxproto CSWxfooxproto b/ x11_fooproto CSWx11fooproto c/ x11proto_foo CSWx11protofoo d/ x11proto_foo_devel CSWx11protofoodevel Best regards -- Dago From james at opencsw.org Wed Sep 23 15:12:49 2009 From: james at opencsw.org (James Lee) Date: Wed, 23 Sep 2009 13:12:49 GMT Subject: [csw-maintainers] Using a package from current on stable In-Reply-To: <4ABA0A0D.1040603@opencsw.org> References: <4ABA011A.8070809@opencsw.org> <4ABA0A0D.1040603@opencsw.org> Message-ID: <20090923.13124900.4175345103@gyor.oxdrove.co.uk> On 23/09/09, 12:44:13, Daniel Pocock wrote regarding Re: [csw-maintainers] Using a package from current on stable: > However, if someone wants to distribute a package through a third party > download site (e.g. the upstream download page on SF), and they want > their package to just drop in to stable, is that permitted? Who's going to stop it? We are not underworked copyright lawyers. The OCSW official line is going to be that you distribute the package as an official CSW package. A problem is OCSW don't know to support your package so, e.g., if it needs a particular library (expat.so.0 vs expat.so.1) you leave yourself exposed to that library being dropped. To avoid branding issues and potential file clashes you can use /opt/$YOURNAME and use /opt/csw RPATHs. > Is there a > convenient way to build such a package with gar on the build farm? No. Build against stable. Either set up a stable build environment or force it with the paths, that is use $ELSEWHERE/$STABLE/opt/csw and set PATH, -I, -L appropriately. James. From maciej at opencsw.org Wed Sep 23 15:52:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 14:52:39 +0100 Subject: [csw-maintainers] Upgrading shared libraries Message-ID: I'm splitting this thread, to talk a bit more about library updates. On Wed, Sep 23, 2009 at 12:43 PM, wrote: > Hi Maciej, > >> On Wed, Sep 23, 2009 at 12:25 PM, ? wrote: >>> You can either put the original legacy libraries in there "manually" >>> during post-install (see curl for an example) or use version modulations >>> to also build the old version and put only the libs in the package >>> (see expat/flac/neon/readline for examples). >> >> I see, version modulations. Is it a one-way process only? I mean, this >> way the list of package versions is going to be growing indefinitely, >> unless there's a process in place to phase out the old versions. > > No. After the updated package has been released you file the bugs > to the packages depending on the old libs :-) After the last one has > been updated you remove them from your package. I'll drill the topic some more. What if a dependent package becomes orphaned? Suppose there's CSWlibfoo, which has been updated, but package CSWbar depends on it, the maintainer vanished inside a black hole and nobody is willing to pick the package up. Are there any deadlines? Does the importance of CSWbar matter? Ideally, I'd like it to be there a page which describes how to deal with library updates, along with the process of phasing out old library versions. Can one of the elders write it? If not, I'm going to do it myself, and Trygve is going to start telling me why what I wrote is wrong... ;-) Maciej From daniel at opencsw.org Wed Sep 23 16:34:53 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 23 Sep 2009 15:34:53 +0100 Subject: [csw-maintainers] etc issues Message-ID: <4ABA320D.108@opencsw.org> I'm putting my config under /etc/opt/csw/ganglia, as suggested in an earlier email from Dago However, I notice that gar configures my application to use /opt/csw/etc Is some extra effort required to override this? My Makefile is here: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/ganglia/branches/ganglia-3.1.3-rc/ and this is what I found in the build dir: bash-2.03$ ls -l work/build-isa-sparcv8/ganglia-3.1.3/config.log -rw-r--r-- 1 daniel csw 119978 Sep 23 12:28 work/build-isa-sparcv8/ganglia-3.1.3/config.log bash-2.03$ bash-2.03$ grep sysconfdir work/build-isa-sparcv8/ganglia-3.1.3/config.log $ ./configure --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share --sysconfdir=/opt/csw/etc --sharedstatedir=/opt/csw/share --localstatedir=/opt/csw/var --libdir=/opt/csw/lib --infodir=/opt/csw/share/info --includedir=/opt/csw/include --mandir=/opt/csw/share/man --with-gmetad --disable-nls --with-libapr=/opt/csw/apache2/bin/apr-1-config --with-status --disable-python sysconfdir='/opt/csw/etc' From bwalton at opencsw.org Wed Sep 23 16:40:47 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Sep 2009 10:40:47 -0400 Subject: [csw-maintainers] etc issues In-Reply-To: <4ABA320D.108@opencsw.org> References: <4ABA320D.108@opencsw.org> Message-ID: <1253716785-sup-3583@ntdws12.chass.utoronto.ca> Excerpts from Daniel Pocock's message of Wed Sep 23 10:34:53 -0400 2009: > I'm putting my config under /etc/opt/csw/ganglia, as suggested in an > earlier email from Dago > > However, I notice that gar configures my application to use > /opt/csw/etc For now, you need to set 'sysconfdir = /etc/opt/csw' manually in your makefile to override the gar default. I'm planning to update this but haven't had the time to update the default and alter all makefiles to prevent surprises for maintainers yet. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Wed Sep 23 16:42:43 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 15:42:43 +0100 Subject: [csw-maintainers] etc issues In-Reply-To: <1253716785-sup-3583@ntdws12.chass.utoronto.ca> References: <4ABA320D.108@opencsw.org> <1253716785-sup-3583@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Sep 23, 2009 at 3:40 PM, Ben Walton wrote: > Excerpts from Daniel Pocock's message of Wed Sep 23 10:34:53 -0400 2009: > >> I'm putting my config under /etc/opt/csw/ganglia, as suggested in an >> earlier email from Dago >> >> However, I notice that gar configures my application to use >> /opt/csw/etc > > For now, you need to set 'sysconfdir = /etc/opt/csw' manually in your > makefile to override the gar default. ?I'm planning to update this but > haven't had the time to update the default and alter all makefiles to > prevent surprises for maintainers yet. Yes, what Ben said. Two directories need to be altered. On Wed, Sep 23, 2009 at 3:34 PM, Daniel Pocock wrote: > --sysconfdir=/opt/csw/etc > --localstatedir=/opt/csw/var Add these two lines to the Makefile: sysconfdir = /etc/opt/csw localstatedir = /var/opt/csw Maciej From phil at bolthole.com Wed Sep 23 18:13:51 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 09:13:51 -0700 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4AB9FBE9.8000908@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4AB9FBE9.8000908@wbonnet.net> Message-ID: On Wed, Sep 23, 2009 at 3:43 AM, William Bonnet wrote: > Hi > > > After having some talk with Sebastian, i have the folowwing proposition. > Since we are renaming some of the X11 packages to add a prefix, and about to > do some mass change. What about adding a more explicit prefix ? > > For instance fooproto could be renamed to : > > a/ xfooxproto > b/ x11-fooproto > c/ x11proto-foo > d/ x11proto-foo-devel > > Current proposition is a. My choice goes to d. I would like to also add the > -devel suffix since it is a true devel package d isnt a bad choice... the one issue being that it would look a little silly for stuff that already has "x" in it. x11proto_xext_devel vs x11proto_input_devel people will probably gripe about "well how come Xexp, but no Xinput...?" From phil at bolthole.com Wed Sep 23 18:19:08 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 09:19:08 -0700 Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: Message-ID: On Wed, Sep 23, 2009 at 6:52 AM, Maciej (Matchek) Blizinski wrote: > I'm splitting this thread, to talk a bit more about library updates. > > On Wed, Sep 23, 2009 at 12:43 PM, ? wrote: >> Hi Maciej, >> >> >>> I see, version modulations. Is it a one-way process only? I mean, this >>> way the list of package versions is going to be growing indefinitely, >>> unless there's a process in place to phase out the old versions. >> >> No. After the updated package has been released you file the bugs >> to the packages depending on the old libs :-) After the last one has >> been updated you remove them from your package. > > I'll drill the topic some more. What if a dependent package becomes > orphaned? Suppose there's CSWlibfoo, which has been updated, but > package CSWbar depends on it, the maintainer vanished inside a black > hole and nobody is willing to pick the package up. Are there any > deadlines? I dont see how this "changes" anything. every package that is "current"ly being distributed, needs to actually WORK. for so long as CSWbar is present, CSWlibfoo must ensure that it does not break, by supplying the older library that CSWbar requires. > Ideally, I'd like it to be there a page which describes how to deal > with library updates, I believe there already is such a page, and it mentions what dago says: Provide the older versions of the shared libs for so long as other packages we distribute, require them. From william at wbonnet.net Wed Sep 23 18:19:40 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 23 Sep 2009 18:19:40 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4AB9FBE9.8000908@wbonnet.net> Message-ID: <4ABA4A9C.4090704@wbonnet.net> Hi > d isnt a bad choice... the one issue being that it would look a little > silly for stuff that already has "x" in it. > > x11proto_xext_devel > > vs > > x11proto_input_devel > > people will probably gripe about "well how come Xexp, but no Xinput...?" > I agree but this is how the upstream project choosed to name its package... BTW you cannot be sure that in the futur someone will not add an ext package. In this case how would you name it if xext already exist and you kept its name instead of naming it xxext ? ;) This should not happen... but it may... so it will :) I do prefer to always keep original upstream name if possible. cheers W. From maciej at opencsw.org Wed Sep 23 19:05:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Sep 2009 18:05:01 +0100 Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: Message-ID: On Wed, Sep 23, 2009 at 5:19 PM, Philip Brown wrote: > On Wed, Sep 23, 2009 at 6:52 AM, Maciej (Matchek) Blizinski > wrote: >> I'm splitting this thread, to talk a bit more about library updates. >> >> On Wed, Sep 23, 2009 at 12:43 PM, ? wrote: >>> Hi Maciej, >>> >>> >>>> I see, version modulations. Is it a one-way process only? I mean, this >>>> way the list of package versions is going to be growing indefinitely, >>>> unless there's a process in place to phase out the old versions. >>> >>> No. After the updated package has been released you file the bugs >>> to the packages depending on the old libs :-) After the last one has >>> been updated you remove them from your package. >> >> I'll drill the topic some more. What if a dependent package becomes >> orphaned? Suppose there's CSWlibfoo, which has been updated, but >> package CSWbar depends on it, the maintainer vanished inside a black >> hole and nobody is willing to pick the package up. Are there any >> deadlines? > > > I dont see how this "changes" anything. > > every package that is "current"ly being distributed, needs to actually WORK. > for so long as CSWbar is present, CSWlibfoo must ensure that it does > not break, by supplying the older library that CSWbar requires. That's clear. What I had in mind is: how do we prevent our libraries from growing indefinitely in size due to stale dependent packages? >> Ideally, I'd like it to be there a page which describes how to deal >> with library updates, > > I believe there already is such a page, and it mentions what dago > says: Provide the older versions of the shared libs for so long as > other packages we distribute, require them. I think it would be the one with the following URL: http://www.opencsw.org/standards/libraries It's a narrative describing it from a high level. It's a good start, but not really what I had in mind. I was thinking of having it documented: - what are the possible strategies (Dago mentioned two of them) - how to achieve that in GAR - what is the process of phasing out old library versions - what are the deadlines for phasing out old libraries (say, there's a bug to update a package, but doesn't get fixed for X amount of time. What's happening with the dependent package, does it need a new maintainer, or does it get killed?) Maciej From phil at bolthole.com Wed Sep 23 19:23:25 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 10:23:25 -0700 Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: Message-ID: On Wed, Sep 23, 2009 at 10:05 AM, Maciej (Matchek) Blizinski wrote: > >> every package that is "current"ly being distributed, needs to actually WORK. >> for so long as CSWbar is present, CSWlibfoo must ensure that it does >> not break, by supplying the older library that CSWbar requires. > > That's clear. What I had in mind is: how do we prevent our libraries > from growing indefinitely in size due to stale dependent packages? It's worked pretty well for 6 years now. All the questions you are asking, are dealt with on a case-by-base basis. There really isnt a need to spell out every single possible contingency. [and there's a need to NOT spell it out.. documents that are too long, get ignored.] Bottom line is, progress happens by people willing to do work. not by documenting things to the Nth degree. From phil at bolthole.com Wed Sep 23 19:25:58 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 10:25:58 -0700 Subject: [csw-maintainers] The source code of www.opencsw.org In-Reply-To: References: <20090723220149.GB8541@bolthole.com> <20090724160343.GC91227@bolthole.com> <4A6B4DFE.1050307@opencsw.org> <20090725203035.GA24170@bolthole.com> <4A6C2341.8060600@opencsw.org> <20090726154345.GB28096@bolthole.com> Message-ID: On Wed, Sep 23, 2009 at 2:23 AM, Maciej (Matchek) Blizinski wrote: > Re: http://www.opencsw.org/mantis/view.php?id=3459#c6709 > > The irforceready mirrors from our mirrors subpage currently point at > Blastwave mirrors. I'm not going to propose a change*, because the > administrative overhead is going to by far surpass the amount of work > needed to fix the issue, so I'm only mentioning it here. > > Maciej > > * See how careful I am not to say "send a patch"? Odd way of putting things. BTW, there's a difference between "sugest a change", and "send a patch". Thanks for pointing out the stray site. I have "changed" things. (that wasnt too hard now, was it? :-) From phil at bolthole.com Wed Sep 23 22:35:22 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 13:35:22 -0700 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <4AB9DE48.8060006@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> Message-ID: On Wed, Sep 23, 2009 at 1:37 AM, Sebastian Kayser wrote: > > I was just about to file the bugs against packages which don't have the > py_ prefix. Just wanted to make sure we have reached a consensus here so > that i file the bugs against the right set of packages: > > - python programs with a recognized name can/should be left as is > - python libraries will be prefixed with py_ > > Resuming the pyyaml example: pyyaml is a library (python modules only), > thus the software name would be py_yaml. This is similar to Debian's > policy [1], just that they prefix module packages with "python-". In > their case, pyyaml is packaged as python-yaml [2]. > except that "pyyaml" is in the "recognized name so should be left as is" category :-) it is "recognized" both in the sense that we have an existing package, AND, even MORE importantly, there is the actual specific name of the software. hosted from "pyyaml.org" From phil at bolthole.com Wed Sep 23 22:37:09 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 13:37:09 -0700 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: On Mon, Sep 21, 2009 at 4:08 PM, Gary Law wrote: > > I beg to differ. The increased complexity of two places outweighs any > possible benefits. Everything in /etc/opt/csw please. Gary for the progams that YOU maintain, that is fine. > -- > Gary Law > glaw at blastwave.org Uhuh. interesting. From phil at bolthole.com Wed Sep 23 22:43:08 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Sep 2009 13:43:08 -0700 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> Message-ID: On Wed, Sep 23, 2009 at 1:35 PM, Philip Brown wrote: > On Wed, Sep 23, 2009 at 1:37 AM, Sebastian Kayser wrote: >> >> Resuming the pyyaml example: pyyaml is a library (python modules only), >> thus the software name would be py_yaml. This is similar to Debian's >> policy [1], just that they prefix module packages with "python-". In >> their case, pyyaml is packaged as python-yaml [2]. As an interesting contrast,both Gentoo and Ubuntu seem to package it as "pyyaml" :-) Eerm.. and debian does too? or at least.. it has a "source package" named "pyyaml".. but a "binary package" named "python-yaml" ?!!! http://packages.debian.org/source/lenny/pyyaml that's just insane. Stop the insanity please :-) pyyaml is a well-known exception to the usual py_ convention From skayser at opencsw.org Thu Sep 24 00:51:00 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 24 Sep 2009 00:51:00 +0200 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> Message-ID: <4ABAA654.1000706@opencsw.org> Philip Brown wrote on 23.09.2009 22:43: > On Wed, Sep 23, 2009 at 1:35 PM, Philip Brown wrote: >> On Wed, Sep 23, 2009 at 1:37 AM, Sebastian Kayser wrote: >>> Resuming the pyyaml example: pyyaml is a library (python modules only), >>> thus the software name would be py_yaml. This is similar to Debian's >>> policy [1], just that they prefix module packages with "python-". In >>> their case, pyyaml is packaged as python-yaml [2]. > > As an interesting contrast,both Gentoo and Ubuntu seem to package it > as "pyyaml" :-) > > Eerm.. and debian does too? > > or at least.. it has a "source package" named "pyyaml".. but a "binary > package" named "python-yaml" ?!!! > http://packages.debian.org/source/lenny/pyyaml The source package name corresponds to the upstream name. The binary package name is where (i imagine) the distribution tries to create a consistent user experience. Plus, one source package can result in multiple binary packages, but that's another topic. You are right, Gentoo simply passes the upstream name pyyaml [1]. Ubuntu (like Debian) renames it to python-yaml [2] though. > pyyaml is a well-known exception to the usual py_ convention If we follow that road we leave it up to every maintainer to decide what is "well-known". Plus there might be as many "well-known" (pygtk, pysqlite, pyxml, etc. [3,4,5]) module packages as non-"well-known" packages, which gets us half py* and half py_* packages. Not to mention, packages like SOAPy/SOAPpy where you wouldn't even have the common py prefix. I should have detailed Debian's python policy WRT module packages a bit more, because it leaves pleasant little room for interpretation. A module package name is constructed according to py_ Here, is absolutely non-ambiguous; one refers to this name when importing a python module. Would a general policy like this (also applied to pyyaml, modulename: yaml) hurt? I don't think so. Sebastian [1] http://gentoo-portage.com/dev-python/pyyaml [2] http://packages.ubuntu.com/karmic/python-yaml [3] http://www.pygtk.org/ [4] http://oss.itsystementwicklung.de/trac/pysqlite/ [5] http://sourceforge.net/projects/pyxml/ From bwalton at opencsw.org Thu Sep 24 03:50:39 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Sep 2009 21:50:39 -0400 Subject: [csw-maintainers] gar_devel Message-ID: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> So I was having a look at www-mockup tonight and I followed the link to preparing a working build environment. That page lists the packages required by GAR to get up and running. I thought 'why not make this easier'... I put together a dummy package called gar_devel (CSWgardevel) that simply depends on all of the listed packages. It's in testing/ now. If it's useful, I'll release it and the reference page can be updated. Otherwise, I'll squash it and forget about the 5 wasted minutes. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Thu Sep 24 09:41:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 24 Sep 2009 09:41:19 +0200 Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: Message-ID: <86E3FB84-4E6D-48DC-9F5B-DAFED4EE7F3E@opencsw.org> Hi Maciej, Am 23.09.2009 um 19:23 schrieb Philip Brown: > On Wed, Sep 23, 2009 at 10:05 AM, Maciej (Matchek) Blizinski > wrote: >> >>> every package that is "current"ly being distributed, needs to >>> actually WORK. >>> for so long as CSWbar is present, CSWlibfoo must ensure that it does >>> not break, by supplying the older library that CSWbar requires. >> >> That's clear. What I had in mind is: how do we prevent our libraries >> from growing indefinitely in size due to stale dependent packages? If an orphaned package depends on a legacy lib you have to keep it. Or update the orphaned package yourself or find somebody. Best regards -- Dago From maciej at opencsw.org Thu Sep 24 11:49:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 24 Sep 2009 10:49:54 +0100 Subject: [csw-maintainers] gar_devel In-Reply-To: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> References: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Sep 24, 2009 at 2:50 AM, Ben Walton wrote: > > So I was having a look at www-mockup tonight and I followed the link > to preparing a working build environment. ?That page lists the > packages required by GAR to get up and running. ?I thought 'why not > make this easier'... > > I put together a dummy package called gar_devel (CSWgardevel) that > simply depends on all of the listed packages. ?It's in testing/ now. > > If it's useful, I'll release it and the reference page can be > updated. ?Otherwise, I'll squash it and forget about the 5 wasted > minutes. I like the idea. Especially, when a somebody is taking first steps at building packages. Less hoops is better! Maciej From maciej at opencsw.org Thu Sep 24 13:37:22 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 24 Sep 2009 12:37:22 +0100 Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: <86E3FB84-4E6D-48DC-9F5B-DAFED4EE7F3E@opencsw.org> References: <86E3FB84-4E6D-48DC-9F5B-DAFED4EE7F3E@opencsw.org> Message-ID: On Thu, Sep 24, 2009 at 8:41 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 23.09.2009 um 19:23 schrieb Philip Brown: >> >> On Wed, Sep 23, 2009 at 10:05 AM, Maciej (Matchek) Blizinski >> wrote: >>> >>>> every package that is "current"ly being distributed, needs to actually >>>> WORK. >>>> for so long as CSWbar is present, CSWlibfoo must ensure that it does >>>> not break, by supplying the older library that CSWbar requires. >>> >>> That's clear. What I had in mind is: how do we prevent our libraries >>> from growing indefinitely in size due to stale dependent packages? > > If an orphaned package depends on a legacy lib you have to keep it. > Or update the orphaned package yourself or find somebody. I see. Too bad, that's a complication I had hoped was possible to avoid. I revisited the modulation presentation from Oslo, it looks like I need to learn more on how to do create multi-version library packages. I'll try to find time this weekend to see if I get this to work. I'm thinking of creating a mgar/pkg/examples directory and putting there a few minimal examples, similar to minimalsmf. Maciej From dam at opencsw.org Thu Sep 24 13:52:37 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Thu, 24 Sep 2009 13:52:37 +0200 (CEST) Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: <86E3FB84-4E6D-48DC-9F5B-DAFED4EE7F3E@opencsw.org> Message-ID: Hi Maciej, > I revisited the modulation presentation from Oslo, it looks like I > need to learn more on how to do create multi-version library packages. > I'll try to find time this weekend to see if I get this to work. I'm > thinking of creating a mgar/pkg/examples directory and putting there a > few minimal examples, similar to minimalsmf. Sure. You can also do cd mgar/pkg grep EXTRA_MODULATORS */trunk/Makefile | grep GARVERSION for examples, some easy ones, some advanced. Feel free to link on them if you are writing up docs as real-world examples. And of course ask any time if you have troubles with modulations :-) Best regards -- Dago From maciej at opencsw.org Thu Sep 24 18:33:43 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 24 Sep 2009 17:33:43 +0100 Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: <86E3FB84-4E6D-48DC-9F5B-DAFED4EE7F3E@opencsw.org> Message-ID: On Thu, Sep 24, 2009 at 12:52 PM, wrote: > Hi Maciej, > >> I revisited the modulation presentation from Oslo, it looks like I >> need to learn more on how to do create multi-version library packages. >> I'll try to find time this weekend to see if I get this to work. I'm >> thinking of creating a mgar/pkg/examples directory and putting there a >> few minimal examples, similar to minimalsmf. > > Sure. You can also do > ?cd mgar/pkg > ?grep EXTRA_MODULATORS */trunk/Makefile | grep GARVERSION > for examples, some easy ones, some advanced. Feel free to link on them > if you are writing up docs as real-world examples. And of course ask > any time if you have troubles with modulations :-) You can always count on me coming up with troubles! ;-) (I'm serious, I'm doing in such a way that I am going to get errors, I'm interested in the kinds of errors I'm going to get and what the fixes are going to be.) Here's a short version-modulated package example: http://dpaste.com/97707/ It's telling me this: gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/examples/modulations/trunk' [merge-license] complete for modulatedpkg. [merge] complete for modulatedpkg. pkgproto: ERROR: unable to stat Failed to generate prototype at /home/maciej/src/opencsw/pkg/examples/modulations/trunk/gar/bin/cswproto line 129. gmake: *** [work/build-global/prototype] Error 1 What is it missing? The destination directories surely get created: maciej at build10s [build10s]:~/src/opencsw/pkg/examples/modulations/trunk > tree work/install-isa-sparcv8-garversion-* work/install-isa-sparcv8-garversion-1.0 `-- opt `-- csw `-- share `-- example-1.0.txt work/install-isa-sparcv8-garversion-1.1 `-- opt `-- csw `-- share `-- example-1.1.txt work/install-isa-sparcv8-garversion-2.0 `-- opt `-- csw `-- share `-- example-2.0.txt 9 directories, 3 files Is it because of the missing merge targets? Maciej From dam at opencsw.org Thu Sep 24 18:53:38 2009 From: dam at opencsw.org (dam at opencsw.org) Date: Thu, 24 Sep 2009 18:53:38 +0200 (CEST) Subject: [csw-maintainers] Upgrading shared libraries In-Reply-To: References: <86E3FB84-4E6D-48DC-9F5B-DAFED4EE7F3E@opencsw.org> Message-ID: <6ed6bc150f2ccd2345d02d5dac826789.squirrel@mail.opencsw.org> Hi Maciej, > On Thu, Sep 24, 2009 at 12:52 PM, wrote: >> Hi Maciej, >> >>> I revisited the modulation presentation from Oslo, it looks like I >>> need to learn more on how to do create multi-version library packages. >>> I'll try to find time this weekend to see if I get this to work. I'm >>> thinking of creating a mgar/pkg/examples directory and putting there a >>> few minimal examples, similar to minimalsmf. >> >> Sure. You can also do >> ??cd mgar/pkg >> ??grep EXTRA_MODULATORS */trunk/Makefile | grep GARVERSION >> for examples, some easy ones, some advanced. Feel free to link on them >> if you are writing up docs as real-world examples. And of course ask >> any time if you have troubles with modulations :-) > > You can always count on me coming up with troubles! ;-) > > (I'm serious, I'm doing in such a way that I am going to get errors, > I'm interested in the kinds of errors I'm going to get and what the > fixes are going to be.) > > Here's a short version-modulated package example: > > http://dpaste.com/97707/ > > It's telling me this: > > gmake[1]: Leaving directory > `/home/maciej/src/opencsw/pkg/examples/modulations/trunk' > [merge-license] complete for modulatedpkg. > [merge] complete for modulatedpkg. > pkgproto: ERROR: unable to stat > > Failed to generate prototype at > /home/maciej/src/opencsw/pkg/examples/modulations/trunk/gar/bin/cswproto > line 129. > gmake: *** [work/build-global/prototype] Error 1 > > What is it missing? The destination directories surely get created: > > maciej at build10s > [build10s]:~/src/opencsw/pkg/examples/modulations/trunk > tree > work/install-isa-sparcv8-garversion-* > work/install-isa-sparcv8-garversion-1.0 > `-- opt > `-- csw > `-- share > `-- example-1.0.txt > work/install-isa-sparcv8-garversion-1.1 > `-- opt > `-- csw > `-- share > `-- example-1.1.txt > work/install-isa-sparcv8-garversion-2.0 > `-- opt > `-- csw > `-- share > `-- example-2.0.txt > > 9 directories, 3 files > > Is it because of the missing merge targets? Yes. If you are using EXTRA_MODULATORS you must have custom merge rules. I may add version modulations as default some time. Just see any of the examples. Best regards -- Dago From phil at bolthole.com Thu Sep 24 18:57:14 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Sep 2009 09:57:14 -0700 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <4ABAA654.1000706@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> Message-ID: On Wed, Sep 23, 2009 at 3:51 PM, Sebastian Kayser wrote: >.... > You are right, Gentoo simply passes the upstream name pyyaml [1]. Ubuntu > (like Debian) renames it to python-yaml [2] though. > >> pyyaml is a well-known exception to the usual py_ convention > > If we follow that road we leave it up to every maintainer to decide what > is "well-known". Plus there might be as many "well-known" (pygtk, > pysqlite, pyxml, etc. [3,4,5]) module packages as non-"well-known" > packages, which gets us half py* and half py_* packages. well I think that "half" is an exaggeration. Or if it is, it's only because we are falling behind in the number of python modules we have packaged, compared to what is out there! > Not to mention, > packages like SOAPy/SOAPpy where you wouldn't even have the common py > prefix. Hmm. that one is a bit hairy. (But then, SOAP stuff has always been disgusting anyway ;-) You do bring up good points though. This might be an issue to bring up for a general vote. From phil at bolthole.com Thu Sep 24 18:59:00 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Sep 2009 09:59:00 -0700 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <4ABAA654.1000706@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> Message-ID: On Wed, Sep 23, 2009 at 3:51 PM, Sebastian Kayser wrote: > > ?py_ > > Here, is absolutely non-ambiguous; one refers to this name > when importing a python module. Would a general policy like this (also > applied to pyyaml, modulename: yaml) hurt? I don't think so. > PS: I forgot to mention my thoughts, that for PURE "modules" only, this makes a good idea of sense to me. But what about python "applications"? or what about things that are part module, and part application? From skayser at opencsw.org Thu Sep 24 19:02:23 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 24 Sep 2009 19:02:23 +0200 (CEST) Subject: [csw-maintainers] OpenCSW Winter Camp 2009, when/where? Feedback needed. Message-ID: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> Hi guys, before we head to Toronto next year in summer :D, i would like to kick off this year's winter camp preparations for Munich. Two votes need your input. - Which weekend can you participate? http://doodle.com/p3rvwqkx542cu4rx - Which venue would you prefer (city/nature)? http://doodle.com/xwnhvxp274i8b3iv Please participate so that we can proceed with the plannings. If you have any questions or feedback, please let me know. Similar to the past camps, i have created a wiki page on http://wiki.opencsw.org/wintercamp-2009 which we can use for planning purposes and for gathering ideas. Thanks Sebastian From phil at bolthole.com Thu Sep 24 22:36:20 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Sep 2009 13:36:20 -0700 Subject: [csw-maintainers] gar_devel In-Reply-To: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> References: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Sep 23, 2009 at 6:50 PM, Ben Walton wrote: > > So I was having a look at www-mockup tonight and I followed the link > to preparing a working build environment. ?That page lists the > packages required by GAR to get up and running. ?I thought 'why not > make this easier'... > > I put together a dummy package called gar_devel (CSWgardevel) that > simply depends on all of the listed packages. ?It's in testing/ now. > > If it's useful, I'll release it and the reference page can be > updated. ?Otherwise, I'll squash it and forget about the 5 wasted > minutes. > Could you describe more precisely what you mean by "get up and running" please? From william at wbonnet.net Thu Sep 24 22:36:32 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 24 Sep 2009 22:36:32 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4AB9B97A.800@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> Message-ID: <4ABBD850.40603@wbonnet.net> Hi There was no more replies, so may be when can finalize the choice. Do we keep the x prefix, or are we moving to something more detailled. I would like us to make a decision before too much work has been done. And i know that Dago already did some renaming before i asked the question. Proposition are listed in this poll : http://doodle.com/huc5w789f4gmft79 cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From bwalton at opencsw.org Thu Sep 24 22:39:53 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 24 Sep 2009 16:39:53 -0400 Subject: [csw-maintainers] gar_devel In-Reply-To: References: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> Message-ID: <1253824699-sup-7197@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Sep 24 16:36:20 -0400 2009: > Could you describe more precisely what you mean by "get up and > running" please? Suck in all the packages required by GAR. Instead of: pkgutil -i CSWautoconf CSWgtar CSWgmake CSW... ... it would become: pkgutil -i CSWgardevel Easier to type and can be updated to reflect any future changes to GAR requirements. It doesn't bring a GAR package itself, but it makes getting started easier. It's a 'lazy web' kind of thing. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Thu Sep 24 22:51:48 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Sep 2009 13:51:48 -0700 Subject: [csw-maintainers] gar_devel In-Reply-To: <1253824699-sup-7197@ntdws12.chass.utoronto.ca> References: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> <1253824699-sup-7197@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Sep 24, 2009 at 1:39 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Sep 24 16:36:20 -0400 2009: > >> Could you describe more precisely what you mean by "get up and >> running" please? > > Suck in all the packages required by GAR. sorry for being dense.. but what definition of "by GAR" do you mean? - to USE gar, to build something from a gar spec, that the user happens to have already laying around? - to use **CSW gar**, to specifically check something out from *our* subversion tree, and build it? - to possibly modify [csw gar] codebase or something, but not neccessarily to DO any work "using gar"? (that's what the name "gardevel" implies. to ME, at least) > Easier to type and can be updated to reflect any future changes to GAR > requirements. ?It doesn't bring a GAR package itself, but it makes > getting started easier. ?It's a 'lazy web' kind of thing. Why not "make a gar package" straight up, instead of going halfway? We badly need it. and Dago is too busy to do it :) A suggestion: I personally think a package layout that makes sense for that would be: 1. CSWgar - a package of "the gar build system/utilities", independant of anything else 2. CSWcswgar - a layer on top of CSWgar, that adds in all the OpenCSW specific stuff, to generic GAR, plus adds in a subversion dependancy, etc. From dam at opencsw.org Thu Sep 24 23:06:06 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 24 Sep 2009 23:06:06 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4ABBD850.40603@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: <59946DCE-F172-4832-82A1-3D7D34D3942E@opencsw.org> Hi, Am 24.09.2009 um 22:36 schrieb William Bonnet: > There was no more replies, so may be when can finalize the choice. > Do we keep the x prefix, or are we moving to something more > detailled. I would like us to make a decision before too much work > has been done. And i know that Dago already did some renaming before > i asked the question. > > Proposition are listed in this poll : > > http://doodle.com/huc5w789f4gmft79 Are you really thinking the proposed naming is good? The original names are fontsproto glproto inputproto kbproto recordproto renderproto videoproto xcb-proto xextproto xproto Having x11proto_fonts_devel is so much different from the original name fontsproto that I wouldn't know what to install. Best regards -- Dago From dam at opencsw.org Thu Sep 24 23:10:36 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 24 Sep 2009 23:10:36 +0200 Subject: [csw-maintainers] gar_devel In-Reply-To: References: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> <1253824699-sup-7197@ntdws12.chass.utoronto.ca> Message-ID: Hi Phil, Am 24.09.2009 um 22:51 schrieb Philip Brown: > On Thu, Sep 24, 2009 at 1:39 PM, Ben Walton > wrote: >> Excerpts from Philip Brown's message of Thu Sep 24 16:36:20 -0400 >> 2009: >> >>> Could you describe more precisely what you mean by "get up and >>> running" please? >> >> Suck in all the packages required by GAR. > > sorry for being dense.. but what definition of "by GAR" do you mean? The base packages from CSW needed to build packages with GAR. >> Easier to type and can be updated to reflect any future changes to >> GAR >> requirements. It doesn't bring a GAR package itself, but it makes >> getting started easier. It's a 'lazy web' kind of thing. > > Why not "make a gar package" straight up, instead of going halfway? > We badly need it. and Dago is too busy to do it :) Partly, yes. But we already have it in mgar/pkg/gar. However, this would only be useful if every commit to GAR would trigger a rebuild (buildbot?) And source packages. > A suggestion: I personally think a package layout that makes sense for > that would be: > > 1. CSWgar - a package of "the gar build system/utilities", > independant of anything else > 2. CSWcswgar - a layer on top of CSWgar, that adds in all the OpenCSW > specific stuff, to generic GAR, plus adds in a subversion dependancy, > etc. I disagree here. Either you choose source packages with a packaged GAR or "developer mode" with Bens base and GAR and build descriptions from the repository. Mixed mode calls for trouble. Best regards -- Dago From william at wbonnet.net Thu Sep 24 23:18:36 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 24 Sep 2009 23:18:36 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <59946DCE-F172-4832-82A1-3D7D34D3942E@opencsw.org> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> <59946DCE-F172-4832-82A1-3D7D34D3942E@opencsw.org> Message-ID: <4ABBE22C.1060802@wbonnet.net> Hi > Having x11proto_fonts_devel is so much different from the original > name fontsproto that I wouldn't know what to install. This naming is based on the debian way of naming. I agree that may be confusing if you compare to the original name. But this make sense to me to add the _devel suffix since it is a real devel package. If you look to its content, same kind of content for other libs are devel packages. x11_fontsproto_devel is maybe closer to the original. BTW, you will certainly never have to install it by yourself since it is mostly a depend file (i personnaly never installed this one on a linux box). Using this scheme or another, is not the major issue for me. I would only like we all agree on the same naming, and be sure to have a conclusion (i asked another question after the discussion between you and Phil...). I'm asking this to be sure there is no more pending question about this before more work is done. cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From phil at bolthole.com Thu Sep 24 23:25:56 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Sep 2009 14:25:56 -0700 Subject: [csw-maintainers] gar_devel In-Reply-To: References: <1253756840-sup-4245@ntdws12.chass.utoronto.ca> <1253824699-sup-7197@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Sep 24, 2009 at 2:10 PM, Dagobert Michelsen wrote: > >> >> Why not "make a gar package" straight up, instead of going halfway? >> We badly need it. and Dago is too busy to do it :) > > Partly, yes. But we already have it in mgar/pkg/gar. However, this would > only be useful if every commit to GAR would trigger a rebuild (buildbot?) > And source packages. I wouldnt say "only be useful". It is still useful. Consider that most projects dont do "releases" every time someone changes something in subversion. Creating a new package, would be equivalent to "doing a release". > >> A suggestion: I personally think a package layout that makes sense for >> that would be: >> >> 1. CSWgar ?- a package of "the gar build system/utilities", >> independant of anything else >> 2. CSWcswgar - a layer on top of CSWgar, that adds in all the OpenCSW >> specific stuff, to generic GAR, plus adds in a subversion dependancy, >> etc. > > I disagree here. Either you choose source packages with a packaged > GAR or "developer mode" with Bens base and GAR and build descriptions > from the repository. Mixed mode calls for trouble. You seem to be discounting the notion of "get GAR accepted as a good build system in its own right". If you dont provide a "separate", generic package of GAR, that will never happen. It should not be much more effort, so why not do it? It would probably keep GAR design cleaner that way too. Consider Apache, and Ant. (not that I LIKE ant... but its the general principle of separation that I respect there :-) From skayser at opencsw.org Thu Sep 24 23:38:12 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 24 Sep 2009 23:38:12 +0200 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> Message-ID: <4ABBE6C4.3040600@opencsw.org> Philip Brown wrote on 24.09.2009 18:59: > On Wed, Sep 23, 2009 at 3:51 PM, Sebastian Kayser wrote: >> py_ >> >> Here, is absolutely non-ambiguous; one refers to this name >> when importing a python module. Would a general policy like this (also >> applied to pyyaml, modulename: yaml) hurt? I don't think so. > > PS: I forgot to mention my thoughts, that for PURE "modules" only, > this makes a good idea of sense to me. > But what about python "applications"? or what about things that are > part module, and part application? I just went through our packages to get a feeling of what we have. In the "part module, part application" or "python application" section, i would see people being interested in the application, not in the modules. The contained modules most likely only support the application after all. Examples: - mercurial - buildbot - trac - fetchmailconf - gitosis - ... Makes sense to keep the upstream name here. There are some corner cases like "twisted" [1] or "pil" [2], where i wouldn't know offhand what to do best (they are mainly libs, but also have some stuff in /opt/csw/bin). So how about 1) If it's a pure module, py_. 2) If it's main use is as application, . 3) In case of doubt, cross-check with other distributions?. With step 1) un-ambiguously catching alot and step 2) then being an easy call mostly, we will have covered the majority of packages. The few remaining ones might as well be decided on a case-by-case basis. Sebastian [1] http://www.opencsw.org/packages/twisted [2] http://www.opencsw.org/packages/pil From william at wbonnet.net Thu Sep 24 23:40:20 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 24 Sep 2009 23:40:20 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4ABBE22C.1060802@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> <59946DCE-F172-4832-82A1-3D7D34D3942E@opencsw.org> <4ABBE22C.1060802@wbonnet.net> Message-ID: <4ABBE744.2040102@wbonnet.net> Hi all I've added a few more proto packages in testing. Please notice that the renaming is not yet done ! These packages are built "ok" but have to be renamed, they are here only to be able to build some libs... I'll rename all these this week end then submit the proto to current. cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From bwalton at opencsw.org Fri Sep 25 00:41:30 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 24 Sep 2009 18:41:30 -0400 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <4ABBE6C4.3040600@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> Message-ID: <1253832055-sup-9675@ntdws12.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Thu Sep 24 17:38:12 -0400 2009: > So how about > 1) If it's a pure module, py_. > 2) If it's main use is as application, . > 3) In case of doubt, cross-check with other distributions?. Logical and concise. +1. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Sep 25 00:55:29 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Sep 2009 15:55:29 -0700 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <1253832055-sup-9675@ntdws12.chass.utoronto.ca> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Sep 24, 2009 at 3:41 PM, Ben Walton wrote: > Excerpts from Sebastian Kayser's message of Thu Sep 24 17:38:12 -0400 2009: >> So how about >> 1) If it's a pure module, py_. >> 2) If it's main use is as application, . >> 3) In case of doubt, cross-check with other distributions?. > > Logical and concise. ?+1. > > -Ben > -- works for me. only thing left to do is pick a place to officially document this, unless there are objections. traditionally, the person in charge of [language], has primarily been in charge of [stuff to do with that language]. Since Mike Watters is our current python maintainer: Mike, how about I give you perms to edit http://www.opencsw.org/standards/python, and you fill in that, and anything else you think appropriate? From bwalton at opencsw.org Fri Sep 25 04:20:37 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 24 Sep 2009 22:20:37 -0400 Subject: [csw-maintainers] C++ hell with Sun Studio and GCC In-Reply-To: References: <4E706AFA-93B0-40F3-9450-0BB3D6A794A7@opencsw.org> <1253553057-sup-1892@ntdws12.chass.utoronto.ca> Message-ID: <1253845097-sup-1817@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Sep 22 01:45:33 -0400 2009: > So I propose making a Solaris 8 Ruby with GCC if you really need it > and starting with Solaris 9 and Sun Studio 12 for eveything else. Ok. That's what I'll do. > BTW, are you interested in packaging up RubeEE and Phusion Passenger? > > I would need that also for my project, but as Ruby maintainer this > would naturally be more on your side ;-) I don't use either of these, although Phusion might be interesting. We're about to order replacement hardware for the box running our RoR site though and the new setup won't be running solaris at all...My requirement of keeping solaris 8 support will soon be gone. I'll only need ruby for non-web stuff on our other solaris boxen. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Fri Sep 25 08:38:07 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Sep 2009 08:38:07 +0200 Subject: [csw-maintainers] Problem compiling Python files Message-ID: <0227CF3D-4B4B-4617-AAE8-E23BF480F934@opencsw.org> Hi Ben, hi Mike, when I updated some packages this morning I got these errors: > ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > dtdparser.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/dtdparser.py', 500, 33, '\t elif self.now_at("#FIXED"): > \n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > errors.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > namespace.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > utils.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xcatalog.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlapp.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmldtd.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/xmldtd.py', 318, 37, '\t"True if \'state\' is a final > state."\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlproc.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/xmlproc.py', 341, 6, '\ttry:\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlutils.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlval.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/xmlval.py', 174, 38, '\tdecl_root = self.dtd.get_root_elem() > \n')) > Listing /opt/csw/lib/python/site-packages/_xmlplus/sax ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/sax/ > __init__.py ... > ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/schema ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/schema/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/schema/ > trex.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/schema/ > trex.py', 1464, 38, '\tfor remainder in match_1.remainders:\n')) > Listing /opt/csw/lib/python/site-packages/_xmlplus/unicode ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/unicode/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/unicode/ > iso8859.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/unicode/ > utf8_iso.py ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/utils ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > characters.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > iso8601.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > qp_xml.py ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/xpath ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > BuiltInExtFunctions.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/xpath/ > BuiltInExtFunctions.py', 22, 37, '\tfrom Ft.__init__ import > __version__\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > Context.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > Conversions.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > CoreFunctions.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ExpandedNameWrapper.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > MessageSource.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > NamespaceNode.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAbbreviatedAbsoluteLocationPath.py ... > SyntaxError: ('invalid syntax', ('/opt/csw/lib/python/site-packages/ > _xmlplus/xpath/ParsedAbbreviatedAbsoluteLocationPath.py', 27, 10, > " as = ParsedAxisSpecifier.ParsedAxisSpecifier('descendant-or- > self')\n")) > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAbbreviatedRelativeLocationPath.py ... > SyntaxError: ('invalid syntax', ('/opt/csw/lib/python/site-packages/ > _xmlplus/xpath/ParsedAbbreviatedRelativeLocationPath.py', 31, 10, > " as = ParsedAxisSpecifier.ParsedAxisSpecifier('descendant-or- > self')\n")) > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAbsoluteLocationPath.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAxisSpecifier.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedExpr.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedNodeTest.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedPredicateList.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedRelativeLocationPath.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedStep.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/Set.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/Util.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > XPathGrammar.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > XPathParser.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > XPathParserBase.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > pyxpath.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/xpath/ > pyxpath.py', 264, 46, '\tyappsrt.SyntaxError.__init__(self, pos, msg) > \n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > yappsrt.py ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/xslt ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ApplyTemplatesElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > AttributeElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > AttributeSetElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > AttributeValueTemplate.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > BuiltInExtElements.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CallTemplateElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ChooseElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CommentElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CopyElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CopyOfElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ElementElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ForEachElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > HtmlWriter.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > IfElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > LiteralElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > LiteralText.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > MessageElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > MessageSource.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > NullWriter.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/xslt/ > NullWriter.py', 36, 8, '\treturn\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > NumberElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > OtherXslElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > OtherwiseElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > OutputHandler.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParamElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedLocationPathPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedRelativePathPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedStepPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > PlainTextWriter.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ProcessingInstructionElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > Processor.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/Roman.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > RtfWriter.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > SortElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > Stylesheet.py ... > SyntaxError: ('invalid syntax', ('/opt/csw/lib/python/site-packages/ > _xmlplus/xslt/Stylesheet.py', 376, 14, ' for as in > attribute_sets:\n')) > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > StylesheetReader.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > TemplateElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > TextElement.py ... > ... Do you mind having a look? Best regards -- Dago From dam at opencsw.org Fri Sep 25 08:40:46 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Sep 2009 08:40:46 +0200 Subject: [csw-maintainers] Problem compiling Python files Message-ID: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> Hi Ben, hi Mike, when I updated some packages this morning I got these errors: > ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > dtdparser.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/dtdparser.py', 500, 33, '\t elif self.now_at("#FIXED"): > \n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > errors.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > namespace.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > utils.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xcatalog.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlapp.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmldtd.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/xmldtd.py', 318, 37, '\t"True if \'state\' is a final > state."\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlproc.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/xmlproc.py', 341, 6, '\ttry:\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlutils.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > xmlval.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > xmlproc/xmlval.py', 174, 38, '\tdecl_root = self.dtd.get_root_elem() > \n')) > Listing /opt/csw/lib/python/site-packages/_xmlplus/sax ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/sax/ > __init__.py ... > ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/schema ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/schema/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/schema/ > trex.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/schema/ > trex.py', 1464, 38, '\tfor remainder in match_1.remainders:\n')) > Listing /opt/csw/lib/python/site-packages/_xmlplus/unicode ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/unicode/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/unicode/ > iso8859.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/unicode/ > utf8_iso.py ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/utils ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > characters.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > iso8601.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/utils/ > qp_xml.py ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/xpath ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > BuiltInExtFunctions.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/xpath/ > BuiltInExtFunctions.py', 22, 37, '\tfrom Ft.__init__ import > __version__\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > Context.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > Conversions.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > CoreFunctions.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ExpandedNameWrapper.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > MessageSource.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > NamespaceNode.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAbbreviatedAbsoluteLocationPath.py ... > SyntaxError: ('invalid syntax', ('/opt/csw/lib/python/site-packages/ > _xmlplus/xpath/ParsedAbbreviatedAbsoluteLocationPath.py', 27, 10, > " as = ParsedAxisSpecifier.ParsedAxisSpecifier('descendant-or- > self')\n")) > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAbbreviatedRelativeLocationPath.py ... > SyntaxError: ('invalid syntax', ('/opt/csw/lib/python/site-packages/ > _xmlplus/xpath/ParsedAbbreviatedRelativeLocationPath.py', 31, 10, > " as = ParsedAxisSpecifier.ParsedAxisSpecifier('descendant-or- > self')\n")) > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAbsoluteLocationPath.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedAxisSpecifier.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedExpr.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedNodeTest.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedPredicateList.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedRelativeLocationPath.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > ParsedStep.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/Set.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/Util.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > XPathGrammar.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > XPathParser.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > XPathParserBase.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > __init__.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > pyxpath.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/xpath/ > pyxpath.py', 264, 46, '\tyappsrt.SyntaxError.__init__(self, pos, msg) > \n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xpath/ > yappsrt.py ... > Listing /opt/csw/lib/python/site-packages/_xmlplus/xslt ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ApplyTemplatesElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > AttributeElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > AttributeSetElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > AttributeValueTemplate.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > BuiltInExtElements.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CallTemplateElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ChooseElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CommentElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CopyElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > CopyOfElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ElementElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ForEachElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > HtmlWriter.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > IfElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > LiteralElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > LiteralText.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > MessageElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > MessageSource.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > NullWriter.py ... > Sorry: TabError: ('inconsistent use of tabs and spaces in > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/xslt/ > NullWriter.py', 36, 8, '\treturn\n')) > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > NumberElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > OtherXslElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > OtherwiseElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > OutputHandler.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParamElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedLocationPathPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedRelativePathPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ParsedStepPattern.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > PlainTextWriter.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > ProcessingInstructionElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > Processor.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/Roman.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > RtfWriter.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > SortElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > Stylesheet.py ... > SyntaxError: ('invalid syntax', ('/opt/csw/lib/python/site-packages/ > _xmlplus/xslt/Stylesheet.py', 376, 14, ' for as in > attribute_sets:\n')) > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > StylesheetReader.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > TemplateElement.py ... > Compiling /opt/csw/lib/python/site-packages/_xmlplus/xslt/ > TextElement.py ... > ... Do you mind having a look? Best regards -- Dago From maciej at opencsw.org Fri Sep 25 10:11:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 25 Sep 2009 09:11:39 +0100 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> Message-ID: On Fri, Sep 25, 2009 at 7:40 AM, Dagobert Michelsen wrote: > Hi Ben, hi Mike, > > when I updated some packages this morning I got these errors: Was it an update from current or from testing? How to reproduce this problem? Maciej From dam at opencsw.org Fri Sep 25 12:00:04 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Sep 2009 12:00:04 +0200 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> Message-ID: <94334879-8269-43B0-9995-7ACDCE124BF8@opencsw.org> Hi Maciej, Am 25.09.2009 um 10:11 schrieb Maciej (Matchek) Blizinski: > On Fri, Sep 25, 2009 at 7:40 AM, Dagobert Michelsen > wrote: >> Hi Ben, hi Mike, >> >> when I updated some packages this morning I got these errors: > > Was it an update from current or from testing? How to reproduce this > problem? From current/, I just installed some stuff that pulled in the updates. Best regards -- Dago From maciej at opencsw.org Fri Sep 25 12:59:51 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 25 Sep 2009 11:59:51 +0100 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: <94334879-8269-43B0-9995-7ACDCE124BF8@opencsw.org> References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> <94334879-8269-43B0-9995-7ACDCE124BF8@opencsw.org> Message-ID: On Fri, Sep 25, 2009 at 11:00 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 25.09.2009 um 10:11 schrieb Maciej (Matchek) Blizinski: >> >> On Fri, Sep 25, 2009 at 7:40 AM, Dagobert Michelsen >> wrote: >>> >>> Hi Ben, hi Mike, >>> >>> when I updated some packages this morning I got these errors: >> >> Was it an update from current or from testing? How to reproduce this >> problem? > > From current/, I just installed some stuff that pulled in the updates. I couldn't reproduce that. Perhaps there were old .py files lying around? I'm guessing one of the guilty packages was py_libxml2, right? Maciej From bwalton at opencsw.org Fri Sep 25 14:27:20 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Sep 2009 08:27:20 -0400 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> Message-ID: <1253881445-sup-3063@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Sep 25 02:40:46 -0400 2009: Hi Dago, > > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ > > dtdparser.py ... > > Sorry: TabError: ('inconsistent use of tabs and spaces in > > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ > > xmlproc/dtdparser.py', 500, 33, '\t elif self.now_at("#FIXED"): > > \n')) That file seems to be part of CSWpyxml, which has a REV stamp of 2008.03.17, which is well before cswpycompile came about. I don't see a version of it in testing/, either. It _shouldn't_, as far as I can tell, even be compiling its files at install time. I pulled it onto a machine here and didn't get the errors. Am I missing something? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Fri Sep 25 14:39:09 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 25 Sep 2009 13:39:09 +0100 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: <1253881445-sup-3063@ntdws12.chass.utoronto.ca> References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> <1253881445-sup-3063@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Sep 25, 2009 at 1:27 PM, Ben Walton wrote: > Excerpts from Dagobert Michelsen's message of Fri Sep 25 02:40:46 -0400 2009: > > Hi Dago, > >> > Compiling /opt/csw/lib/python/site-packages/_xmlplus/parsers/xmlproc/ >> > dtdparser.py ... >> > Sorry: TabError: ('inconsistent use of tabs and spaces in >> > indentation', ('/opt/csw/lib/python/site-packages/_xmlplus/parsers/ >> > xmlproc/dtdparser.py', 500, 33, '\t ? ?elif self.now_at("#FIXED"): >> > \n')) > > That file seems to be part of CSWpyxml, which has a REV stamp of > 2008.03.17, which is well before cswpycompile came about. ?I don't see > a version of it in testing/, either. ?It _shouldn't_, as far as I can > tell, even be compiling its files at install time. > > I pulled it onto a machine here and didn't get the errors. > > Am I missing something? I kept on seeing that each time I installed a Python package using cswpycompile, it could (re)compile all the existing .py files, not just the ones being installed. Perhaps there were .py files lying around? Try to put a broken .py file in site-packages and reinstall the package. When I do that and install any package which uses cswpycompile, I'm getting: Compiling /opt/csw/lib/python/site-packages/broken.py ... Sorry: IndentationError: ('unexpected indent', ('/opt/csw/lib/python/site-packages/broken.py', 3, 2, '\t\t"is"\n')) Maciej From bwalton at opencsw.org Fri Sep 25 15:24:28 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Sep 2009 09:24:28 -0400 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> <1253881445-sup-3063@ntdws12.chass.utoronto.ca> Message-ID: <1253884984-sup-3102@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Sep 25 08:39:09 -0400 2009: > I kept on seeing that each time I installed a Python package using > cswpycompile, it could (re)compile all the existing .py files, not > just the ones being installed. Perhaps there were .py files lying > around? Try to put a broken .py file in site-packages and reinstall > the package. Ok, so you're saying the cswpycompile is slurping up too much when it runs? I haven't looked (recently) at this... To trigger this bug then, you'd need to update a package that uses cswpycompile and any another python package regardless of cswpycompile use? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Fri Sep 25 15:43:34 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 25 Sep 2009 14:43:34 +0100 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: <1253884984-sup-3102@ntdws12.chass.utoronto.ca> References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> <1253881445-sup-3063@ntdws12.chass.utoronto.ca> <1253884984-sup-3102@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Sep 25, 2009 at 2:24 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Fri Sep 25 08:39:09 -0400 2009: > >> I kept on seeing that each time I installed a Python package using >> cswpycompile, it could (re)compile all the existing .py files, not >> just the ones being installed. Perhaps there were .py files lying >> around? Try to put a broken .py file in site-packages and reinstall >> the package. > > Ok, so you're saying the cswpycompile is slurping up too much when it > runs? ?I haven't looked (recently) at this... > > To trigger this bug then, you'd need to update a package that uses > cswpycompile and any another python package regardless of cswpycompile > use? Yes. In other words, to reproduce: echo '"' > /opt/csw/lib/python/site-packages/broken.py pkgutil -i py_fpconst | less From bwalton at opencsw.org Fri Sep 25 19:05:47 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Sep 2009 13:05:47 -0400 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> <1253881445-sup-3063@ntdws12.chass.utoronto.ca> <1253884984-sup-3102@ntdws12.chass.utoronto.ca> Message-ID: <1253898268-sup-3010@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Sep 25 09:43:34 -0400 2009: > > To trigger this bug then, you'd need to update a package that uses > > cswpycompile and any another python package regardless of cswpycompile > > use? > > Yes. In other words, to reproduce: > > echo '"' > /opt/csw/lib/python/site-packages/broken.py > pkgutil -i py_fpconst | less Ok, looking at the script, this is exactly what happens. It would only get tripped when there is a package supplying bad files though, which is why it didn't show up until now. I seem to recall Mike saying that executing the compilations per-file instead of as a batch like this was too slow. Mike, can you corroborate with my memory on this? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Sep 25 19:23:25 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 25 Sep 2009 10:23:25 -0700 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <59946DCE-F172-4832-82A1-3D7D34D3942E@opencsw.org> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> <59946DCE-F172-4832-82A1-3D7D34D3942E@opencsw.org> Message-ID: On Thu, Sep 24, 2009 at 2:06 PM, Dagobert Michelsen wrote: > > > Are you really thinking the proposed naming is good? >.... > > Having x11proto_fonts_devel is so much different from the original > name fontsproto that I wouldn't know what to install. yes. plus to me, its just too durn long :-} From phil at bolthole.com Fri Sep 25 19:27:58 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 25 Sep 2009 10:27:58 -0700 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4ABBD850.40603@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: On Thu, Sep 24, 2009 at 1:36 PM, William Bonnet wrote: > > Proposition are listed in this poll : > > http://doodle.com/huc5w789f4gmft79 > i finally got around to looking at this... and seems like an option is missing. you were comparing what happens to something called "fooproto". you give "xfooxproto" as an option (which is very confusing to me, sticking something in the MIDDLE). But you dont have "xfooproto" as an option. I guess I personally like x11_fooproto even more anyways. but just saying that the choices seem a little short. From maciej at opencsw.org Fri Sep 25 20:48:29 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 25 Sep 2009 19:48:29 +0100 Subject: [csw-maintainers] Problem compiling Python files In-Reply-To: <1253898268-sup-3010@ntdws12.chass.utoronto.ca> References: <22CCF44D-6DC9-46CA-A30F-3BBB079E01C1@opencsw.org> <1253881445-sup-3063@ntdws12.chass.utoronto.ca> <1253884984-sup-3102@ntdws12.chass.utoronto.ca> <1253898268-sup-3010@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Sep 25, 2009 at 6:05 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Fri Sep 25 09:43:34 -0400 2009: >> > To trigger this bug then, you'd need to update a package that uses >> > cswpycompile and any another python package regardless of cswpycompile >> > use? >> >> Yes. In other words, to reproduce: >> >> echo '"' > /opt/csw/lib/python/site-packages/broken.py >> pkgutil -i py_fpconst | less > > Ok, looking at the script, this is exactly what happens. ?It would > only get tripped when there is a package supplying bad files though, > which is why it didn't show up until now. Perhaps Python update? There were things that Python 2.5 would turn a blind eye to, but Python 2.6 would not. It'd be nice to have a check for this problem. I'm sure it can be caught during package creation stage. Maciej From trygvis at opencsw.org Fri Sep 25 21:34:56 2009 From: trygvis at opencsw.org (=?UTF-8?B?VHJ5Z3ZlIExhdWdzdMO4bA==?=) Date: Fri, 25 Sep 2009 21:34:56 +0200 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <1253832055-sup-9675@ntdws12.chass.utoronto.ca> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> Message-ID: <4ABD1B60.5060700@opencsw.org> Ben Walton wrote: > Excerpts from Sebastian Kayser's message of Thu Sep 24 17:38:12 -0400 2009: >> So how about >> 1) If it's a pure module, py_. >> 2) If it's main use is as application, . >> 3) In case of doubt, cross-check with other distributions?. > > Logical and concise. +1. Ditto. +1. -- Trygve From dam at opencsw.org Sat Sep 26 10:59:25 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 26 Sep 2009 10:59:25 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: Hi, Am 25.09.2009 um 19:27 schrieb Philip Brown: > On Thu, Sep 24, 2009 at 1:36 PM, William Bonnet > wrote: >> >> Proposition are listed in this poll : >> >> http://doodle.com/huc5w789f4gmft79 >> > > i finally got around to looking at this... and seems like an option > is missing. > > you were comparing what happens to something called "fooproto". > > you give "xfooxproto" as an option (which is very confusing to me, > sticking something in the MIDDLE). But you dont have "xfooproto" as > an option. William, Sebastian, Maciej: Why do you think it is a good idea to reorder the naming parts of the software? Like inputproto -> x11proto_input And I don't want to hear "for consistency", Maciej ;-) Best regards -- Dago From maciej at opencsw.org Sat Sep 26 12:03:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 26 Sep 2009 11:03:30 +0100 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: On Sat, Sep 26, 2009 at 9:59 AM, Dagobert Michelsen wrote: > Hi, > > Am 25.09.2009 um 19:27 schrieb Philip Brown: > >> On Thu, Sep 24, 2009 at 1:36 PM, William Bonnet >> wrote: >>> >>> Proposition are listed in this poll : >>> >>> http://doodle.com/huc5w789f4gmft79 >>> >> >> i finally got around to looking at this... and seems like an option is >> missing. >> >> you were comparing what happens to something called "fooproto". >> >> you give "xfooxproto" as an option (which is very confusing to me, >> sticking something in the MIDDLE). But you dont have "xfooproto" as >> an option. > > William, Sebastian, Maciej: Why do you think it is a good idea to > reorder the naming parts of the software? Like > inputproto -> x11proto_input > > And I don't want to hear "for consistency", Maciej ;-) Actually, I thought about suggesting compressing the prefix even more. We've got pm_* and py_*, right? If there's a whole category of X11 protocols, why not have xp_*? A counterargument could be that xp_* is not self explanatory. Well, neither is pm_*. If anyone is interested in what those packages are (that xp stands for X11 protocol), descriptions will help. What do you think? Maciej From maciej at opencsw.org Sat Sep 26 18:06:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 26 Sep 2009 17:06:13 +0100 Subject: [csw-maintainers] Package comparator Message-ID: Today's shameless plug: I hacked together a small (200 lines of code) tool to compare prototypes of packages. It's especially useful when GAR-ifying packages and making sure that whatever was in the old packages is also present in the new one. It's also useful if one wants to find out whether the new package version contains files with higher major library version. I've submitted the code to the opencsw (!= gar) repository. To get it: $ svn co https://opencsw.svn.sourceforge.net/svnroot/opencsw opencsw To run it: $ opencsw/utilities/compare_pkgs.py -h Usage: compare_pkgs.py [options] Options: -h, --help show this help message and exit -d, --debug -a PACKAGE_DIR_A, --package-dir-a=PACKAGE_DIR_A Package directory A -b PACKAGE_DIR_B, --package-dir-b=PACKAGE_DIR_B Package directory B -c CATALOG_NAME, --catalog-name=CATALOG_NAME Catalog name, for example 'cups' -p, --permissions Whether to analyze permission bits My typical usage scenario would be: $ compare_pkgs.py -a ./old-packages -b ~/staging/build-2009-09-26 -c mysql5 It's a quickly hacked tool and might have rough edges; but I think even now it can be useful for other people. Feel free to flame me now. ;-) Maciej From skayser at opencsw.org Sat Sep 26 19:58:36 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sat, 26 Sep 2009 19:58:36 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: <4ABE564C.6070502@opencsw.org> Dagobert Michelsen wrote on 26.09.2009 10:59: > Am 25.09.2009 um 19:27 schrieb Philip Brown: > >> On Thu, Sep 24, 2009 at 1:36 PM, William Bonnet >> wrote: >>> Proposition are listed in this poll : >>> >>> http://doodle.com/huc5w789f4gmft79 >>> >> i finally got around to looking at this... and seems like an option >> is missing. >> >> you were comparing what happens to something called "fooproto". >> >> you give "xfooxproto" as an option (which is very confusing to me, >> sticking something in the MIDDLE). But you dont have "xfooproto" as >> an option. > > William, Sebastian, Maciej: Why do you think it is a good idea to > reorder the naming parts of the software? Like > inputproto -> x11proto_input Simply as a way to group them via a common prefix. But honestly, i don't mind having a shorter one either. We will hit the 20 chars limit with x11proto_ and that in turn will drag a whole other discussion with it. One that we need to have some time, but maybe not this time. Sebastian From william at wbonnet.net Sun Sep 27 22:11:37 2009 From: william at wbonnet.net (William Bonnet) Date: Sun, 27 Sep 2009 22:11:37 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4ABE564C.6070502@opencsw.org> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> <4ABE564C.6070502@opencsw.org> Message-ID: <4ABFC6F9.7030600@wbonnet.net> Hi > Simply as a way to group them via a common prefix. But honestly, i don't > mind having a shorter one either. > > We will hit the 20 chars limit with x11proto_ and that in turn will drag > a whole other discussion with it. One that we need to have some time, > but maybe not this time. > So do we agree that : For proto packages We add a x11_ prefix to all proto files We keep the name of the package unchanged after the prefix Proto packages that are not named like fooproto, are also unchanged and prefix by x11_ Devel suffix will not be used for these files (even if the contains the same kind of files as _devel packages) Example : fooproto -> x11_fooproto xbarproto -> x11_xbarproto muf -> x11_muf For X11/libs We don't change anything I have commited almost all the proto and libs that were pending on my side. I still have a few options to add to be consistent with Dago's modifications (i am thinking of some extra merge steps). But before doing it i have to release and thus rename a few proto packages. Cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From dam at opencsw.org Sun Sep 27 23:23:05 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 27 Sep 2009 23:23:05 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4ABFC6F9.7030600@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> <4ABE564C.6070502@opencsw.org> <4ABFC6F9.7030600@wbonnet.net> Message-ID: Hi William, Am 27.09.2009 um 22:11 schrieb William Bonnet: >> Simply as a way to group them via a common prefix. But honestly, i >> don't >> mind having a shorter one either. >> >> We will hit the 20 chars limit with x11proto_ and that in turn will >> drag >> a whole other discussion with it. One that we need to have some time, >> but maybe not this time. >> > So do we agree that : > For proto packages > We add a x11_ prefix to all proto files > We keep the name of the package unchanged after the prefix > Proto packages that are not named like fooproto, are also unchanged > and prefix by x11_ > Devel suffix will not be used for these files (even if the contains > the same kind of files as _devel packages) > > Example : fooproto -> x11_fooproto > xbarproto -> x11_xbarproto > muf -> x11_muf > > For X11/libs > We don't change anything > > I have commited almost all the proto and libs that were pending on > my side. I still have a few options to add to be consistent with > Dago's modifications (i am thinking of some extra merge steps). But > before doing it i have to release and thus rename a few proto > packages. This sounds like a good solution :-) Feel free to release any proto you see missing. Best regards -- Dago From rupert at opencsw.org Sun Sep 27 23:37:36 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 27 Sep 2009 23:37:36 +0200 Subject: [csw-maintainers] svn-1.6.5 in testing Message-ID: <6af4270909271437u15d3abbajec081df8fb57d9c@mail.gmail.com> hi, i upgraded svn to 1.6.5 and put it into testing, will test it in our environment this week. the packages are writeable for everybody, so you can overwrite them. rupert. From dam at opencsw.org Mon Sep 28 10:57:20 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 28 Sep 2009 10:57:20 +0200 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: Hi Maciej, Am 26.09.2009 um 12:03 schrieb Maciej (Matchek) Blizinski: > On Sat, Sep 26, 2009 at 9:59 AM, Dagobert Michelsen > wrote: >> Hi, >> >> Am 25.09.2009 um 19:27 schrieb Philip Brown: >> >>> On Thu, Sep 24, 2009 at 1:36 PM, William Bonnet >>> >>> wrote: >>>> >>>> Proposition are listed in this poll : >>>> >>>> http://doodle.com/huc5w789f4gmft79 >>>> >>> >>> i finally got around to looking at this... and seems like an >>> option is >>> missing. >>> >>> you were comparing what happens to something called "fooproto". >>> >>> you give "xfooxproto" as an option (which is very confusing to me, >>> sticking something in the MIDDLE). But you dont have "xfooproto" as >>> an option. >> >> William, Sebastian, Maciej: Why do you think it is a good idea to >> reorder the naming parts of the software? Like >> inputproto -> x11proto_input >> >> And I don't want to hear "for consistency", Maciej ;-) > > Actually, I thought about suggesting compressing the prefix even more. > We've got pm_* and py_*, right? If there's a whole category of X11 > protocols, why not have xp_*? A counterargument could be that xp_* is > not self explanatory. Well, neither is pm_*. It is, because the files end in .pm :-) > If anyone is interested > in what those packages are (that xp stands for X11 protocol), > descriptions will help. What do you think? The proposed solution from William with a simple prefix and leaving the rest as defined by upstream sounds very reasonable to me. Best regards -- Dago From maciej at opencsw.org Mon Sep 28 16:31:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 28 Sep 2009 15:31:30 +0100 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> Message-ID: On Mon, Sep 28, 2009 at 9:57 AM, Dagobert Michelsen wrote: >> Actually, I thought about suggesting compressing the prefix even more. >> We've got pm_* and py_*, right? If there's a whole category of X11 >> protocols, why not have xp_*? A counterargument could be that xp_* is >> not self explanatory. Well, neither is pm_*. > > It is, because the files end in .pm :-) That's an excellent ignotum per ignotious right there! ;-) >> If anyone is interested >> in what those packages are (that xp stands for X11 protocol), >> descriptions will help. What do you think? > > The proposed solution from William with a simple prefix and leaving the > rest as defined by upstream sounds very reasonable to me. The x11_foo, where foo is an upstream name which might be ending in 'proto'? It sounds reasonable too, I just wanted to put the shortest possible option out there, so that it can get considered. Maciej From phil at bolthole.com Mon Sep 28 17:18:50 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Sep 2009 08:18:50 -0700 Subject: [csw-maintainers] /testing Some X11 proto updates In-Reply-To: <4ABFC6F9.7030600@wbonnet.net> References: <4AB94B60.7010704@wbonnet.net> <4AB9B97A.800@wbonnet.net> <4ABBD850.40603@wbonnet.net> <4ABE564C.6070502@opencsw.org> <4ABFC6F9.7030600@wbonnet.net> Message-ID: On Sun, Sep 27, 2009 at 1:11 PM, William Bonnet wrote: > > So do we agree that : > For proto packages > ? ? ? ?We add a x11_ prefix to all proto files > ? ? ? ?We keep the name of the package unchanged after the prefix > ? ? ? ?Proto packages that are not named like fooproto, are also unchanged > and prefix by x11_ > ? ? ? ?Devel suffix will not be used for these files (even if the contains > the same kind of files as _devel packages) > > ? ? ? ?Example : fooproto ?-> x11_fooproto > ? ? ? ? ? ? ? ? ?xbarproto -> x11_xbarproto > ? ? ? ? ? ? ? ? ?muf ? ? ? -> x11_muf > with the additional, explicit understanding, that at this time, this ONLY applies to x11 related prototype packages, and NOTHING else... yes I am ok with this also From phil at bolthole.com Mon Sep 28 17:25:47 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Sep 2009 08:25:47 -0700 Subject: [csw-maintainers] Package comparator In-Reply-To: References: Message-ID: On Sat, Sep 26, 2009 at 9:06 AM, Maciej (Matchek) Blizinski wrote: > Today's shameless plug: I hacked together a small (200 lines of code) > tool to compare prototypes of packages. It's especially useful when > GAR-ifying packages and making sure that whatever was in the old > packages is also present in the new one. excellent! we've been needing this for a long time. > $ opencsw/utilities/compare_pkgs.py -h Please rename it to be just "compare_pkgs", though? there's no need to have a .py "extention". we're not dealing with web server cgi interpreters here :-) From maciej at opencsw.org Mon Sep 28 17:37:26 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 28 Sep 2009 16:37:26 +0100 Subject: [csw-maintainers] Package comparator In-Reply-To: References: Message-ID: On Mon, Sep 28, 2009 at 4:25 PM, Philip Brown wrote: > On Sat, Sep 26, 2009 at 9:06 AM, Maciej (Matchek) Blizinski > wrote: >> Today's shameless plug: I hacked together a small (200 lines of code) >> tool to compare prototypes of packages. It's especially useful when >> GAR-ifying packages and making sure that whatever was in the old >> packages is also present in the new one. > > excellent! we've been needing this for a long time. > > >> $ opencsw/utilities/compare_pkgs.py -h > > Please rename it to be just "compare_pkgs", though? > there's no need to have a .py "extention". we're not dealing with web > server cgi interpreters here :-) Yes, that's the plan. The actual binary when deployed will probably be /opt/csw/bin/compare-pkgs; It's going to be a wrapper calling out to /opt/csw/lib/csw/python (or something similar), which is going to contain the compare_pkgs.py file. There's also the opencsw_lib.py with common functions, shared by more Python scripts from the utilities directory. I was thinking that this script could be added to the CSWcswutils package. Maciej From phil at bolthole.com Mon Sep 28 18:20:53 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Sep 2009 09:20:53 -0700 Subject: [csw-maintainers] Package comparator In-Reply-To: References: Message-ID: On Mon, Sep 28, 2009 at 8:37 AM, Maciej (Matchek) Blizinski wrote: > > I was thinking that this script could be added to the CSWcswutils package. > I think that is a good idea... I just wasnt sure if it was gar-specific. Is it? will it be useful if someone is not using gar? From skayser at opencsw.org Mon Sep 28 21:12:07 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 28 Sep 2009 21:12:07 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? Message-ID: <4AC10A87.1090205@opencsw.org> Hi, pkgutil was placed straight at the mirror root a while ago to facilitate downloading, but it doesn't seem to get updates. The version floating around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please be fixed (and be kept in sync in the future pleeeaase :). Furthermore, could pkgutil be made an ARCH=all package, so that there is just _one_ direct link that one can point new users to and not a platform specific one (i know about uname -p, still it just makes things more straightforward)? I see, the package contains a wget which is platform specific. Couldn't we just include two wgets (wget.i386, wget.sparc)? From what i remember, that is the same approach Sun uses for its explorer package. Sebastian [1]http://www.ibiblio.org/pub/packages/solaris/opencsw/pkgutil-i386.pkg [2]http://www.ibiblio.org/pub/packages/solaris/opencsw/pkgutil-sparc.pkg From dam at opencsw.org Mon Sep 28 21:16:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 28 Sep 2009 21:16:43 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <4AC10A87.1090205@opencsw.org> References: <4AC10A87.1090205@opencsw.org> Message-ID: <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> Hi Sebastian, Am 28.09.2009 um 21:12 schrieb Sebastian Kayser: > pkgutil was placed straight at the mirror root a while ago to > facilitate > downloading, but it doesn't seem to get updates. The version floating > around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please be > fixed (and be kept in sync in the future pleeeaase :). > > Furthermore, could pkgutil be made an ARCH=all package, so that > there is > just _one_ direct link that one can point new users to and not a > platform specific one (i know about uname -p, still it just makes > things > more straightforward)? > > I see, the package contains a wget which is platform specific. > Couldn't > we just include two wgets (wget.i386, wget.sparc)? From what i > remember, > that is the same approach Sun uses for its explorer package. This was Peters intent, but Phil argued strongly against having ARCHALL=1 packages with arch-specific binaries. See the thread for details: Best regards -- Dago From maciej at opencsw.org Mon Sep 28 21:36:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 28 Sep 2009 20:36:54 +0100 Subject: [csw-maintainers] Package comparator In-Reply-To: References: Message-ID: On Mon, Sep 28, 2009 at 5:20 PM, Philip Brown wrote: > On Mon, Sep 28, 2009 at 8:37 AM, Maciej (Matchek) Blizinski > wrote: >> >> I was thinking that this script could be added to the CSWcswutils package. >> > > > I think that is a good idea... I just wasnt sure if it was gar-specific. > Is it? > will it be useful if someone is not using gar? Yes it will; it only requires Python, gunzip and pkgtrans to run. Maciej From dam at opencsw.org Mon Sep 28 21:43:52 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 28 Sep 2009 21:43:52 +0200 Subject: [csw-maintainers] Package comparator In-Reply-To: References: Message-ID: <62B51B99-0D5D-4546-90F6-70E1A06C5E69@opencsw.org> Hi Phil, Am 28.09.2009 um 18:20 schrieb Philip Brown: > On Mon, Sep 28, 2009 at 8:37 AM, Maciej (Matchek) Blizinski > wrote: >> >> I was thinking that this script could be added to the CSWcswutils >> package. > > I think that is a good idea... I just wasnt sure if it was gar- > specific. > Is it? > will it be useful if someone is not using gar? It has nothing to do with GAR, it works on .pkg-files. Best regards -- Dago From phil at bolthole.com Mon Sep 28 22:12:46 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Sep 2009 13:12:46 -0700 Subject: [csw-maintainers] Package comparator In-Reply-To: <62B51B99-0D5D-4546-90F6-70E1A06C5E69@opencsw.org> References: <62B51B99-0D5D-4546-90F6-70E1A06C5E69@opencsw.org> Message-ID: On Mon, Sep 28, 2009 at 12:43 PM, Dagobert Michelsen wrote: > > It has nothing to do with GAR, it works on .pkg-files. > > great! well lets see it added then :) From skayser at opencsw.org Mon Sep 28 22:15:06 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 28 Sep 2009 22:15:06 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <6DA71489-7F5F-4007-8B3F-D0CC1B5DFD19@opencsw.org> Message-ID: <4AC1194A.3040308@opencsw.org> Dagobert Michelsen wrote on 28.09.2009 21:16: > Am 28.09.2009 um 21:12 schrieb Sebastian Kayser: >> pkgutil was placed straight at the mirror root a while ago to >> facilitate >> downloading, but it doesn't seem to get updates. The version floating >> around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please be >> fixed (and be kept in sync in the future pleeeaase :). >> >> Furthermore, could pkgutil be made an ARCH=all package, so that >> there is >> just _one_ direct link that one can point new users to and not a >> platform specific one (i know about uname -p, still it just makes >> things >> more straightforward)? >> >> I see, the package contains a wget which is platform specific. >> Couldn't >> we just include two wgets (wget.i386, wget.sparc)? From what i >> remember, >> that is the same approach Sun uses for its explorer package. > > This was Peters intent, but Phil argued strongly against having > ARCHALL=1 > packages with arch-specific binaries. See the thread for details: > > Wow, that's a huge discussion. I couldn't resist thinking about our motto (while reading): "to provide a straightforward, easy-to-use experience for the user" pkgutil is one out of two possible packages of ours that a user comes across first. While i see that there is a need to decide about what should be an ARCH=all package, i don't really see the need to make an example of pkgutil (considering that one could argue both ways). :/ Sebastian From phil at bolthole.com Mon Sep 28 22:15:13 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Sep 2009 13:15:13 -0700 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <4AC10A87.1090205@opencsw.org> References: <4AC10A87.1090205@opencsw.org> Message-ID: On Mon, Sep 28, 2009 at 12:12 PM, Sebastian Kayser wrote: > Hi, > > pkgutil was placed straight at the mirror root a while ago to facilitate > downloading, but it doesn't seem to get updates. The version floating > around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please be > fixed (and be kept in sync in the future pleeeaase :). >.... > > I see, the package contains a wget which is platform specific. Couldn't > we just include two wgets (wget.i386, wget.sparc)? for the record, that's exactly we provide "two wgets" binaries, in the mirror root itself, directly. Kinda silly to include yet another wget binary wrapped in a package at that level, isnt it? From dam at opencsw.org Mon Sep 28 22:20:58 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 28 Sep 2009 22:20:58 +0200 Subject: [csw-maintainers] Package comparator In-Reply-To: References: <62B51B99-0D5D-4546-90F6-70E1A06C5E69@opencsw.org> Message-ID: <71CDDB93-A1E1-41E2-8F97-45C61CFD910C@opencsw.org> Hi, Am 28.09.2009 um 22:12 schrieb Philip Brown: > On Mon, Sep 28, 2009 at 12:43 PM, Dagobert Michelsen > wrote: >> >> It has nothing to do with GAR, it works on .pkg-files. > > great! > well lets see it added then :) Maciej, the files for cswutils directly live in Would you mind putting it there so I can make an update release? Best regards -- Dago From skayser at opencsw.org Mon Sep 28 22:23:54 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 28 Sep 2009 22:23:54 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: References: <4AC10A87.1090205@opencsw.org> Message-ID: <4AC11B5A.7030409@opencsw.org> Philip Brown wrote on 28.09.2009 22:15: > On Mon, Sep 28, 2009 at 12:12 PM, Sebastian Kayser wrote: >> Hi, >> >> pkgutil was placed straight at the mirror root a while ago to facilitate >> downloading, but it doesn't seem to get updates. The version floating >> around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please be >> fixed (and be kept in sync in the future pleeeaase :). >> .... >> >> I see, the package contains a wget which is platform specific. Couldn't >> we just include two wgets (wget.i386, wget.sparc)? > > for the record, that's exactly we provide "two wgets" binaries, in the > mirror root itself, directly. > Kinda silly to include yet another wget binary wrapped in a package at > that level, isnt it? As a user, i never cared about those wgets in particular. What i cared about and still do care about is a working and easily distributable package utility. Sebastian From maciej at opencsw.org Tue Sep 29 09:50:43 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 29 Sep 2009 08:50:43 +0100 Subject: [csw-maintainers] Package comparator In-Reply-To: <71CDDB93-A1E1-41E2-8F97-45C61CFD910C@opencsw.org> References: <62B51B99-0D5D-4546-90F6-70E1A06C5E69@opencsw.org> <71CDDB93-A1E1-41E2-8F97-45C61CFD910C@opencsw.org> Message-ID: On Mon, Sep 28, 2009 at 9:20 PM, Dagobert Michelsen wrote: > Maciej, the files for cswutils directly live in > > Would you mind putting it there so I can make an update release? I've updated the build file. I implemented pulling a specific revision from subversion, with checksums checking: http://sourceforge.net/apps/trac/gar/changeset/6601 Maciej From dam at opencsw.org Tue Sep 29 11:36:25 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 29 Sep 2009 11:36:25 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <4AC11B5A.7030409@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC11B5A.7030409@opencsw.org> Message-ID: <4D1296B1-F7A4-4479-B27F-F29F86A97450@opencsw.org> Hi Sebastian, Am 28.09.2009 um 22:23 schrieb Sebastian Kayser: > Philip Brown wrote on 28.09.2009 22:15: >> On Mon, Sep 28, 2009 at 12:12 PM, Sebastian Kayser > > wrote: >>> Hi, >>> >>> pkgutil was placed straight at the mirror root a while ago to >>> facilitate >>> downloading, but it doesn't seem to get updates. The version >>> floating >>> around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please >>> be >>> fixed (and be kept in sync in the future pleeeaase :). >>> .... >>> >>> I see, the package contains a wget which is platform specific. >>> Couldn't >>> we just include two wgets (wget.i386, wget.sparc)? >> >> for the record, that's exactly we provide "two wgets" binaries, in >> the >> mirror root itself, directly. >> Kinda silly to include yet another wget binary wrapped in a package >> at >> that level, isnt it? > > As a user, i never cared about those wgets in particular. What i cared > about and still do care about is a working and easily distributable > package utility. I am in favor of making an exception here for ARCHALL too. If it helps making the user experience easier wgets should be included, for pkg-get and pkgutil. Best regards -- Dago From bwalton at opencsw.org Tue Sep 29 14:48:26 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 29 Sep 2009 08:48:26 -0400 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <4D1296B1-F7A4-4479-B27F-F29F86A97450@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC11B5A.7030409@opencsw.org> <4D1296B1-F7A4-4479-B27F-F29F86A97450@opencsw.org> Message-ID: <1254228339-sup-3541@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Sep 29 05:36:25 -0400 2009: > I am in favor of making an exception here for ARCHALL too. If it helps > making the user experience easier wgets should be included, for pkg-get > and pkgutil. Things have changed since the last discussion too. Solaris 8 is best effort only now. Does 9 include LWP::FTP (or whatever) such that wget isn't required as part of the bootstrapping process? I'm not saying that pkgutil should abandon solaris 8, but it may at least be an option. Given the above, I was and still am in favour of the exception in this case. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Tue Sep 29 22:23:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 29 Sep 2009 21:23:58 +0100 Subject: [csw-maintainers] Links from mantis to the 'processing bugs' wiki page Message-ID: Some time ago Dago has written the following page on the wiki: http://wiki.opencsw.org/processing-bugs Would it be hard to include links to this page in Mantis? I was thinking about two places: 1. The header at Mantis, somewhere in the white area to the right of the big blue "OpenCSW Bug Tracker" at the top. 2. The weekly nagging e-mail. What do you think about this? Maciej From glaw at opencsw.org Tue Sep 29 23:17:08 2009 From: glaw at opencsw.org (Gary Law) Date: Tue, 29 Sep 2009 22:17:08 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: 2009/9/23 Philip Brown : >> -- >> Gary Law >> glaw at blastwave.org LOL .... slip of the keyboard ;) -- Gary Law glaw at opencsw.org From bonivart at opencsw.org Wed Sep 30 09:33:19 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 30 Sep 2009 09:33:19 +0200 Subject: [csw-maintainers] Get zero deps with GAR? Message-ID: <625385e30909300033n4a413c46v2c648b90907b72d7@mail.gmail.com> How do I create a package with no dependencies at all with GAR? It always adds common (and perl if it's cpan), how can I override that? -- /peter From dam at opencsw.org Wed Sep 30 10:27:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 30 Sep 2009 10:27:02 +0200 Subject: [csw-maintainers] Get zero deps with GAR? In-Reply-To: <625385e30909300033n4a413c46v2c648b90907b72d7@mail.gmail.com> References: <625385e30909300033n4a413c46v2c648b90907b72d7@mail.gmail.com> Message-ID: <616A3ABB-CAA2-4191-BA65-C25C192D7317@opencsw.org> Hi Peter, Am 30.09.2009 um 09:33 schrieb Peter Bonivart: > How do I create a package with no dependencies at all with GAR? It > always adds common (and perl if it's cpan), how can I override that? The easiest way is to use a custom gspec file. In the dynamic gspec section there is a line %include url file://csw_dyngspec.gspec which includes the file %include url file://%{PKGLIB}/csw_vars.gspec %include url file://%{PKGLIB}/csw_prototype.gspec %pkginfo url file://%{WORKSRC}/csw/pkginfo %depend:merge url file://%{PKGLIB}/csw/depend %include url file://%{PKGLIB}/std_depend.gspec The file pkglib/csw/depend contains the dependency to CSWcommon. All gspecs include that one. So, add something like this to files/CSWpkgutil.gspec: %var bitname pkgutil %var pkgname CSWpkgutil %include url file://%{PKGLIB}/csw_vars.gspec %include url file://%{PKGLIB}/csw_prototype.gspec %pkginfo url file://%{WORKSRC}/csw/pkginfo %include url file://%{PKGLIB}/std_depend.gspec That is, put in the lines from the include with the depend line skipped. It may be good to do more of this inside the GAR Makefile in the future. Best regards -- Dago From dam at opencsw.org Wed Sep 30 15:28:07 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 30 Sep 2009 15:28:07 +0200 Subject: [csw-maintainers] Berkeley DB pending final resolution Message-ID: Hi, due to the involved complexities I am currently rebuilding Berkeley DB in a defined way, where each version gets its own very separate directories. That means there is /opt/csw/bdb43 /opt/csw/bdb44 /opt/csw/bdb... for all relevant versions. The legacy link for /opt/csw/bdb4 will be linked to the contents of /opt/csw/bdb42 making the contained 4.2 version explicit. The generic bdb will be deprecated, the newly build packages should instead be recompiled against bdb47. The existing bdb3 will stay at 3.3.11, updated are neither required nor intended. Linking in the future will always be against specific versions like /opt/csw/bdbXY If we can't unify it let's make it as clean and separate as possible. Feedback? Best regards -- Dago From james at opencsw.org Wed Sep 30 16:55:18 2009 From: james at opencsw.org (James Lee) Date: Wed, 30 Sep 2009 14:55:18 GMT Subject: [csw-maintainers] Berkeley DB pending final resolution In-Reply-To: References: Message-ID: <20090930.14551800.454845078@gyor.oxdrove.co.uk> On 30/09/09, 14:28:07, Dagobert Michelsen wrote regarding [csw-maintainers] Berkeley DB pending final resolution: > due to the involved complexities I am currently rebuilding Berkeley DB > in a defined way, where each version gets its own very separate > directories. > That means there is > /opt/csw/bdb43 > /opt/csw/bdb44 > /opt/csw/bdb... > for all relevant versions. The legacy link for > /opt/csw/bdb4 > will be linked to the contents of /opt/csw/bdb42 making the contained > 4.2 version explicit. The generic bdb will be deprecated, the newly > build > packages should instead be recompiled against bdb47. This is basically back to what it was before in recognition of Berkley DB versions being mutual incompatible. Until existing packages are recompiled your new final solution will break recently built packages that expect 4.7 in /opt/csw/lib. You will have to arrange for atomic release with rebuilds or legacy 4.7 links in the legacy CSWbdb and CSWbdb4 packages. Affected packages: CSWooocore uses 4.7 from CSWbdb4 (CSWbdb4 uses CSWbdb) CSWperl uses 4.7 from CSWbdb CSWpmberkeleydb uses 4.7 from CSWbdb CSWruby uses 4.7 from CSWbdb James. From bonivart at opencsw.org Wed Sep 30 16:55:31 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 30 Sep 2009 16:55:31 +0200 Subject: [csw-maintainers] Get zero deps with GAR? In-Reply-To: <616A3ABB-CAA2-4191-BA65-C25C192D7317@opencsw.org> References: <625385e30909300033n4a413c46v2c648b90907b72d7@mail.gmail.com> <616A3ABB-CAA2-4191-BA65-C25C192D7317@opencsw.org> Message-ID: <625385e30909300755p73e0fae9wc9d750612842510e@mail.gmail.com> On Wed, Sep 30, 2009 at 10:27 AM, Dagobert Michelsen wrote: > The easiest way is to use a custom gspec file. That's how I do it now. I can't get rid of the gspec then. For now... :-) -- /peter From dam at opencsw.org Wed Sep 30 17:06:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 30 Sep 2009 17:06:19 +0200 Subject: [csw-maintainers] Berkeley DB pending final resolution In-Reply-To: <20090930.14551800.454845078@gyor.oxdrove.co.uk> References: <20090930.14551800.454845078@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 30.09.2009 um 16:55 schrieb James Lee: > On 30/09/09, 14:28:07, Dagobert Michelsen wrote > regarding > [csw-maintainers] Berkeley DB pending final resolution: > >> due to the involved complexities I am currently rebuilding Berkeley >> DB >> in a defined way, where each version gets its own very separate >> directories. >> That means there is >> /opt/csw/bdb43 >> /opt/csw/bdb44 >> /opt/csw/bdb... >> for all relevant versions. The legacy link for >> /opt/csw/bdb4 >> will be linked to the contents of /opt/csw/bdb42 making the contained >> 4.2 version explicit. The generic bdb will be deprecated, the newly >> build >> packages should instead be recompiled against bdb47. > > This is basically back to what it was before in recognition of > Berkley DB versions being mutual incompatible. > > Until existing packages are recompiled your new final solution will > break recently built packages that expect 4.7 in /opt/csw/lib. > You will have to arrange for atomic release with rebuilds or legacy > 4.7 links in the legacy CSWbdb and CSWbdb4 packages. I am thinking of legacy links. Fortunately the newly released packages are well maintained and could be rebuild in a reasonable timeframe making the legacy links obsolete soon. Long-term I would want to get rid of the generic CSWbdb and CSWbdb4 and the libs in /opt/csw/lib. > Affected packages: > CSWooocore uses 4.7 from CSWbdb4 (CSWbdb4 uses CSWbdb) > CSWperl uses 4.7 from CSWbdb > CSWpmberkeleydb uses 4.7 from CSWbdb > CSWruby uses 4.7 from CSWbdb Best regards -- Dago From daniel at pocock.com.au Fri Sep 11 18:28:01 2009 From: daniel at pocock.com.au (Daniel Pocock) Date: Fri, 11 Sep 2009 16:28:01 -0000 Subject: [csw-maintainers] libconfuse and Solaris 10 version In-Reply-To: References: Message-ID: <4AAA7A92.5020801@pocock.com.au> Dagobert Michelsen wrote: > Hi Daniel, > > there are two versions of libconfuse in testing, one for Solaris 8+9 and > one for Solaris 10. There is only one version synced to the mirrors: > Solaris 8. Is this what you intended? > Yes, Phil asked me to only supply a Solaris 8 version unless there is a significant reason for having a special Solaris 10 package. I'll remove them all from testing now. From dam at baltic-online.de Fri Sep 11 20:59:05 2009 From: dam at baltic-online.de (Dagobert Michelsen) Date: Fri, 11 Sep 2009 18:59:05 -0000 Subject: [csw-maintainers] Updated TCPWrappers Message-ID: Hi, there is an updated tcpwrappers package in testing now with both 32 and 64 bit. It was quite hard to build and without Phils notices I probably wouldn't have managed to do it. If you use tcpwrappers with standard or extended configuration files please test it and let me know if it works as I don't use tcpwrappers myself (but a lot of my packages depend on tcpwrappers and there was not 64 bit libs). Best regards -- Dago From bchill at bch.net Mon Sep 21 00:19:39 2009 From: bchill at bch.net (Brian Hill) Date: Sun, 20 Sep 2009 22:19:39 +0000 Subject: [csw-maintainers] librsync 0.9.7 uploaded to testing Message-ID: <20090920221939.GA25482@vm-1.bch.net> I have uploaded librsync for testing. It isn't all that useful by itself, but it is needed for rdiff-backup, which is coming soon. Does the descriptions file update at regular intervals or is it done by hand? A pkg-get of librsync from testing doesn't work yet. Brian From philatbolthole at gmail.com Mon Sep 21 04:19:59 2009 From: philatbolthole at gmail.com (Philip Brown) Date: Sun, 20 Sep 2009 19:19:59 -0700 Subject: [csw-maintainers] big package update in testing/ In-Reply-To: <1253403883-sup-5997@ntdws12.chass.utoronto.ca> References: <1253403883-sup-5997@ntdws12.chass.utoronto.ca> Message-ID: <16A40B7B-FBFD-415B-B59F-9072DC2CD970@gmail.com> very cool. you might check with dago to see if it's ok to put the update script also on the testing dir. it probably is.