From dam at opencsw.org Tue Dec 1 09:37:44 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Dec 2009 09:37:44 +0100 Subject: [csw-maintainers] Major cleanup of testing/ In-Reply-To: References: Message-ID: Hi Phil, Am 30.11.2009 um 18:45 schrieb Philip Brown: > leave the samba ones please. they're useful, even though they arent > "official". > i did a very nice "proof of concept" thing with them at my work last > month with them. Could you please repackage it with a sane name? Best regards -- Dago From dam at opencsw.org Tue Dec 1 09:46:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Dec 2009 09:46:55 +0100 Subject: [csw-maintainers] New members welcome! Message-ID: Hi, the association welcomes the newly accepted members - Rupert Thurner Rupert already maintains packages including often-requested Mercurial and Trac. Please keep in mind that being a maintainer is not only about fame and glory, but also about tedious work to make the packages as good as possible and remove bugs timely when discovered. Please check regularly at the bottom of your maintainer page if there are any open issues. If you have spare cycles please adopt an orphaned package and help bring the complete software stack to a 100% current state. But enough of morality: A very warm welcome! Your membership is tracked at Please let me know on what are you working or are planning to work like "webpage", "maintainer", etc. Best regards -- Dago From dam at opencsw.org Tue Dec 1 09:53:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Dec 2009 09:53:32 +0100 Subject: [csw-maintainers] Possible splitting of liba52 and mpeg2dec In-Reply-To: References: <2CECC2D9-CA37-4C37-B694-39F6A2101AD9@opencsw.org> <4CAB987C-7DB3-4F97-BC16-E86DC3DEA80D@gmail.com> <1BB4AC5F-7708-4B2F-A96A-A26D5C8E1035@opencsw.org> Message-ID: <3E8DB3D0-21FC-4BFF-A557-46D282F45D61@opencsw.org> Hi Phil, Am 30.11.2009 um 18:06 schrieb Philip Brown: > On Sat, Nov 28, 2009 at 12:22 AM, Dagobert Michelsen > wrote: >> liba52-0.7.4,REV=2009.11.28-SunOS5.8-i386-CSW.pkg.gz >> liba52-0.7.4,REV=2009.11.28-SunOS5.8-sparc-CSW.pkg.gz > > Got it, thanks After some more thought I guess it would be good to split off the a52dec part. The library is from the same project as mpeg2dec, which recently changed the name to libmpeg2: The plan it to factor out the binaries (which will only be used by a fraction of users) in mpeg2dec a52dec and let them depend on libmpeg2 liba52 This way existing packages which depend on *dec won't break (which is CSWvlc only anyway which only uses the lib). Currently we have mpeg2dec CSWmpeg2dec liba52 CSWliba52 being not that much consistent. Best regards -- Dago From dam at opencsw.org Tue Dec 1 11:11:42 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Dec 2009 11:11:42 +0100 Subject: [csw-maintainers] Important change to GAR: include flags no longer passed to CFLAGS/CXXFLAGS Message-ID: <5818E604-12F2-45FD-8ECF-CC5DFAF905B5@opencsw.org> Hi, as discusses earlier the INCLUDE_FLAGS (-I...) are no longer passed to CFLAGS and CXXFLAGS, but only to CPPFLAGS starting with r7514. Additionally, I have added a new section "Important changes to GAR" on the GAR frontpage to list bugfixes that may break existing builds: Best regards -- Dago From dam at opencsw.org Tue Dec 1 14:42:08 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Dec 2009 14:42:08 +0100 Subject: [csw-maintainers] Replacing existing Solaris functionality by OpenCSW packages In-Reply-To: References: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> Message-ID: Hi, Am 24.11.2009 um 17:32 schrieb Philip Brown: > On Tue, Nov 24, 2009 at 7:54 AM, Dagobert Michelsen > wrote: >> >> ... >> As there is a "install all" option in pkg-get which is used it >> is adviseable to not install these replacemenet-packages by >> default. This may be accomplished by one of the following >> solutions: >> >> - Different [SVR4 pkg] prefix >> >> The addons would be named CSWX... to mark that they are Xtra >> to install. >> ... >> >> - Different catalog >> >> The extra packages may be put in a separate catalog. >> ... > > Or by other methods. > > Such as defining additional standard global configs to go in csw.conf > > "replace_sun_pkgs=yes" > or some such? > > Then a postinstall script could check for that, and > rename/disable/replace/whatever as appropriate. > > I suppose we might even support different values. > > replace_sun_pkgs={replace,rename,???} > > (where one could mean simple "mv old binaries to .old", and another > might be "actually put in symlink to our binaries, and yet another > could mean "pkgrm conflicting") No feedback for over a week. Maciej, what would you prefer? Peter, what do you think about a special pkgutil-mode instead of the csw.conf directive? Best regards -- Dago From bonivart at opencsw.org Tue Dec 1 14:49:11 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 1 Dec 2009 14:49:11 +0100 Subject: [csw-maintainers] Replacing existing Solaris functionality by OpenCSW packages In-Reply-To: References: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> Message-ID: <625385e30912010549o53175168x9da74912d5d23e92@mail.gmail.com> On Tue, Dec 1, 2009 at 2:42 PM, Dagobert Michelsen wrote: > Peter, what do you think about a special pkgutil-mode instead of the > csw.conf directive? I don't want to implement any special handling, that's bound to be a mess in the future. I think we should solve this with methods already defined and used, in this case a separate repo could be used just like, e.g., Ubuntu does it with things not belonging in the default repos. An option in csw.conf also gives the power to the end-user but in a more complicated way. -- /peter From phil at bolthole.com Tue Dec 1 17:40:05 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 1 Dec 2009 08:40:05 -0800 Subject: [csw-maintainers] Major cleanup of testing/ In-Reply-To: References: Message-ID: On Tue, Dec 1, 2009 at 12:37 AM, Dagobert Michelsen wrote: > Hi Phil, > > Am 30.11.2009 um 18:45 schrieb Philip Brown: >> >> leave the samba ones please. they're useful, even though they arent >> "official". >> i did a very nice "proof of concept" thing with them at my work last >> month with them. > > Could you please repackage it with a sane name? > if I could find the time to repackage it properly, it wouldnt be in testing any more :-P From william at wbonnet.net Tue Dec 1 22:55:05 2009 From: william at wbonnet.net (William Bonnet) Date: Tue, 01 Dec 2009 22:55:05 +0100 Subject: [csw-maintainers] X11 packaging Message-ID: <4B1590B9.3080702@wbonnet.net> Hi, I've almost finished to build the packages from X11 7.5. These packages are installed on test8s. There are the proto files and the following : libxau libxext libdmx libpthread-stubs xtrans libfs libice libsm libxt libx11 libxv libxmu libxfixes libxcomposite libxdamage libxinerama libxpm libxaw libxft libxdmcp libfontenc libxres xrender libxkbfile libxxf86dga libxxf86vm libxvmc libxfont libxi libxtst libxscrnsaver libxcursor libxrandr libwindowswm both lib and devel I still have to do libAppleWM-1.4.0 and libpciaccess-0.10.9. But i still have a few problems to compile these packages. I will now start to rebuild FF and TB against these libs. Feel free to tests yours :) The two missing libs are not that important 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 Tue Dec 1 23:55:02 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 1 Dec 2009 14:55:02 -0800 Subject: [csw-maintainers] X11 packaging In-Reply-To: <4B1590B9.3080702@wbonnet.net> References: <4B1590B9.3080702@wbonnet.net> Message-ID: On Tue, Dec 1, 2009 at 1:55 PM, William Bonnet wrote: > Hi, > > I've almost finished to build the packages from X11 7.5. These packages are > installed on test8s. There are the proto files and the following : > > libxau > libxext > libdmx ... wow.. that's a lot! Thanks William! From dam at opencsw.org Wed Dec 2 13:36:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Dec 2009 13:36:49 +0100 Subject: [csw-maintainers] Update of T5220 tomorrow Message-ID: <2B417740-7ADB-4DF8-943A-183B1A945A9A@opencsw.org> Dear maintainers, I want to take down the T5220 tomorrow for some hardware changes (install FC HBA) and OBP/Firmware updates. The machine will probably down for the day between 10 AM MET and 5 PM MET. Sorry for the inconvenience -- Dago From dam at opencsw.org Wed Dec 2 16:05:29 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Dec 2009 16:05:29 +0100 Subject: [csw-maintainers] [csw-buildfarm] Building postgresql-8.4.1 In-Reply-To: References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <988C113A-0FD5-4D91-B3DE-8174D2620B61@opencsw.org> Message-ID: Hi Maciej, Am 02.12.2009 um 15:35 schrieb Maciej (Matchek) Blizinski: > On Mon, Nov 30, 2009 at 10:27 AM, Dagobert Michelsen > wrote: >> Hi Maciej, > >>> On build8s the tests pass just fine. Is it something that buildfarm >>> admins can fix? >> >> Yes. I need to turn up SHMMAX on build8x and reboot. As I plan to >> migrate >> that >> on the VMware farm I can just install the new one for you to test. >> Please >> allow >> me some more time to finish it. > > Sure. Please let me know when it's done. I'll build the Intel > architecture packages then. > > Meanwhile, I'd like to continue the 32/64 bit PostgreSQL discussion. > My intuition is that application should run the native architecture > binaries, unless there's a reason to do otherwise. Dago wrote, that > it makes sense to do run 64-bit binaries (where possible) by default, > when: > >> (1) using the proper width is mandatory (e.g. /dev/kmem access) >> (2) using 64 bit always has an advantage >> (3) there is difference in output between 32/64 bit > > I don't agree with the second point, because it's phrased too > strongly. 64-bit will not always be advantageous, because you can > find such data and such criteria that 32-bit binary will do better. > > I understand that for many applications there's no advantage in > running in 64-bit width, and therefore the main policy is "use 32 bit > only unless there are reasons to use 64-bit". In the case of a > database engine, there is one general reason to use 64-bit width: > databases tend to be big and run on big machines, using way more than > just 2GB of RAM. Defaulting to 32-bit is like setting up a trap. > > I understand that the two main arguments against using 64-bit by > default where possible are: > > - it consumes more memory > - it potentially runs slower > > I've got a Netra T1125 2X 440MHZ to experiment with. I've run pgbench > using sparcv8 and sparcv9 binaries. > > sparcv8 > tps = 22.976848 (including connections establishing) > tps = 23.070799 (excluding connections establishing) > > sparcv9: > tps = 25.318832 (including connections establishing) > tps = 25.481666 (excluding connections establishing) > > I also know that Dago didn't want to use isaexec, because somebody > might want to copy raw data directories between 32- and 64-bit > architecture machines. I agree that it might happen, but as far as my > database experience goes, messing with raw data directories is > generally asking for trouble. The way to get the data to or out of a > database is via database dumps, which are architecture independent. > If somebody wants replication, they should use slony. > > We could have a postinstall script which would detect and set the > architecture, but isn't it what isaexec does anyway? Yes, but on every invocation. You can execute the postinstall selecting 32/64 bit with isaexec for optimal selection, but the selection should be static and not be changed between invocations of the database. > One more thing: using isaexec doesn't take the choice away. The user > can still set the path to the exact binary and run 32 or 64-bit > version specifically, if they want to. > > To sum up: I maintain that it's best to: > > 1. Use native architecture width by default > 2. Give the user the choice if they have a preference this or the > other way > > isaexec does both those things. > > There's another way of doing it: Force the user to choose the > architecture before they can run PostgreSQL at all. I think it would > be a user-repellent policy. It's so much nicer when the package runs > out of the box: > > pkgutil -y -i postgresql > sudo -u postgres createuser joe > createdb joe > psql > > The negative impact of the database not working out of the box would > in my opinion by greater than the positive impact of being always > conscious about whether it's possible to copy the data files between > machines with different bit width architectures. > > If people want to, I can draw another table with pros and cons. For me you can just default to 64 bit as almost all systems support it and as you said the advantage is there. Best regards -- Dago From maciej at opencsw.org Wed Dec 2 16:17:31 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 2 Dec 2009 15:17:31 +0000 Subject: [csw-maintainers] [csw-buildfarm] Building postgresql-8.4.1 In-Reply-To: References: <988C113A-0FD5-4D91-B3DE-8174D2620B61@opencsw.org> Message-ID: On Wed, Dec 2, 2009 at 3:05 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 02.12.2009 um 15:35 schrieb Maciej (Matchek) Blizinski: >> We could have a postinstall script which would detect and set the >> architecture, but isn't it what isaexec does anyway? > > Yes, but on every invocation. You can execute the postinstall selecting > 32/64 bit with isaexec for optimal selection, but the selection should > be static and not be changed between invocations of the database. Can I ask a na?ve "why"? Machine's architecture may change overnight? isaexec might become broken? I don't have any other ideas. Maciej From dam at opencsw.org Wed Dec 2 16:28:01 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Dec 2009 16:28:01 +0100 Subject: [csw-maintainers] [csw-buildfarm] Building postgresql-8.4.1 In-Reply-To: References: <988C113A-0FD5-4D91-B3DE-8174D2620B61@opencsw.org> Message-ID: Hi Maciej, Am 02.12.2009 um 16:17 schrieb Maciej (Matchek) Blizinski: > On Wed, Dec 2, 2009 at 3:05 PM, Dagobert Michelsen > wrote: >> Hi Maciej, >> >> Am 02.12.2009 um 15:35 schrieb Maciej (Matchek) Blizinski: >>> We could have a postinstall script which would detect and set the >>> architecture, but isn't it what isaexec does anyway? >> >> Yes, but on every invocation. You can execute the postinstall >> selecting >> 32/64 bit with isaexec for optimal selection, but the selection >> should >> be static and not be changed between invocations of the database. > > Can I ask a na?ve "why"? > > Machine's architecture may change overnight? isaexec might become > broken? I don't have any other ideas. You can boot a Solaris 8 and 9 Sparc in 32 or 64 bit. Yes, this is an artifical example. However, I have a very bad feeling selecting this at runtime. I just don't like the idea of copying an installation from one machine to another and it then doesn't work but I may be too picky here... Best regards -- Dago From maciej at opencsw.org Wed Dec 2 16:47:09 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 2 Dec 2009 15:47:09 +0000 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <4AF48870.2040308@opencsw.org> References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> <4AD1C002.1050409@opencsw.org> <7D96D3D3-FA0A-40E1-9549-9114E56174DC@opencsw.org> <4AF18FE6.9040703@opencsw.org> <4AF1A21C.4060201@opencsw.org> <25FB7213-E65F-4115-8DC9-50D57113E275@opencsw.org> <8853603E-D4FD-4534-8D3C-5781B3FC4286@opencsw.org> <4AF48870.2040308@opencsw.org> Message-ID: What does replatforms do? Which stages does it reset? Perhaps it would be better to have more descriptive target names, for example: gmake platforms-reconfigure gmake platforms-repackage gmake platforms-clean etc. Maciej From maciej at opencsw.org Wed Dec 2 16:55:14 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 2 Dec 2009 15:55:14 +0000 Subject: [csw-maintainers] Building MySQL 5.1.x Message-ID: I'm looking at MySQL 5.1. I'm currently experimenting with building it in /opt/csw, with the support for different versions (5.0, 5.1 and so forth). I'm starting this thread to track everything related to building and testing MySQL 5.1. I've just run into this: source='conf_to_src.c' object='conf_to_src.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../depcomp \ /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I../include -I../include -I../include -I/opt/csw/include -I/opt/csw/include/mysql5/5.1 -g -DSAFE_MUTEX -g -xarch=v8 -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 -DHAVE_CURSES_H -I/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/include -DHAVE_RWLOCK_T -DUNIV_SOLARIS -DUNIV_SOLARIS -c conf_to_src.c /bin/bash ../libtool --preserve-dup-deps --tag=CC --mode=link /opt/studio/SOS11/SUNWspro/bin/cc -g -DSAFE_MUTEX -g -xarch=v8 -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 -DHAVE_CURSES_H -I/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/include -DHAVE_RWLOCK_T -DUNIV_SOLARIS -DUNIV_SOLARIS -static -xarch=v8 -L/opt/csw/lib -L/opt/csw/lib/mysql5/5.1 -L/opt/csw/lib -o conf_to_src conf_to_src.o xml.o ctype.o bcmp.o -lpthread -lposix4 -lresolv -lc -lsocket -lnsl -lm -lpthread libtool: Version mismatch error. This is libtool 2.2.6, but the libtool: definition of this LT_INIT comes from libtool 2.2.6b. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 libtool: and run autoconf again. gmake[4]: *** [conf_to_src] Error 63 gmake[4]: *** Waiting for unfinished jobs.... gmake[4]: Leaving directory `/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/strings' This is a completely clean build, no preexisting files. Has anyone seen this problem before? Maciej From bonivart at opencsw.org Wed Dec 2 17:27:44 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 2 Dec 2009 17:27:44 +0100 Subject: [csw-maintainers] /testing postgrey Message-ID: <625385e30912020827mfc0e9dbh7a468ec2b2776b6c@mail.gmail.com> Upon request I have built postgrey, it implements greylisting in the Postfix mail server. I maintain milter-greylist which is similar and can be run on both Sendmail and Postfix but this one is Postfix only. Since I don't use Postfix I can't test this and I may not be the best maintainer for it so if you feel like maintaining it just tell me, it's in GAR so it's really simple to produce a new package. But first of all we need some people to test it, if you use Postfix I would appreciate it if you could install this and try it out. Reference: http://postgrey.schweikert.ch/ Link to package: http://mirror.opencsw.org/testing/postgrey-1.32,REV=2009.12.02-SunOS5.8-all-CSW.pkg.gz -- /peter From phil at bolthole.com Wed Dec 2 19:27:55 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 2 Dec 2009 10:27:55 -0800 Subject: [csw-maintainers] Building MySQL 5.1.x In-Reply-To: References: Message-ID: Maybe you should follow its suggestion and regenerate those files using autoconf, etc. From william at wbonnet.net Wed Dec 2 20:24:22 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 02 Dec 2009 20:24:22 +0100 Subject: [csw-maintainers] X11 packaging In-Reply-To: References: <4B1590B9.3080702@wbonnet.net> Message-ID: <4B16BEE6.9050600@wbonnet.net> Hi Phil > wow.. that's a lot! > > Thanks William! > You're welcome :) but i have to add that it is also dued since a long long time... (and i mean it was stuck on my side) 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 yann at pleiades.fr.eu.org Wed Dec 2 22:04:38 2009 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Wed, 02 Dec 2009 22:04:38 +0100 Subject: [csw-maintainers] Openssl vulnerability CVE-2009-3555 Message-ID: <4B16D666.9030804@pleiades.fr.eu.org> Hi everybody, A ssl vulnerability has been recently found in openssl, this flaw is difficult to fix because the problem lies in the renegotiation feature which is part of the protocol itself. As a result, the last openssl version disables completely tls renegotiation, which could break some setups. From what I understand, there are few setups which would be impacted but I can't be perfectly sure about that. We can either: - release openssl 0.9.8l with renegotiation disabled and warn our users. It would be nice for users who don't want to upgrade to be able to forbid a package upgrade in pkg-get / pkgutil configuration. - do not release 0.9.8l for now and release a new apache 2 / apache mod ssl / other http servers with client initiated renegotiation disabled.Wed, 02 Dec 2009 21:47:50 +0100 This should fix the vulnerability for most Apache configuration and for now only exploits on the HTTPS protocol have been documented. I was planning to do the former but I welcome advices on this matter. You will find below the email I was planning to send to our users. You can find more information about this flaw at the following urls: http://extendedsubset.com/?p=8 http://www.links.org/?p=780 http://www.links.org/?p=786 http://www.links.org/?p=789 http://www.links.org/?p=804 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 The openssl 0.9.8l packages are in testing: http://buildfarm.opencsw.org/testing/openssl_utils-0.9.8l,REV=2009.11.07-SunOS5.8-sparc-CSW.pkg.gz http://buildfarm.opencsw.org/testing/openssl_rt-0.9.8l,REV=2009.11.07-SunOS5.8-sparc-CSW.pkg.gz http://buildfarm.opencsw.org/testing/openssl_devel-0.9.8l,REV=2009.11.07-SunOS5.8-sparc-CSW.pkg.gz http://buildfarm.opencsw.org/testing/openssl_utils-0.9.8l,REV=2009.11.07-SunOS5.8-i386-CSW.pkg.gz http://buildfarm.opencsw.org/testing/openssl_rt-0.9.8l,REV=2009.11.07-SunOS5.8-i386-CSW.pkg.gz http://buildfarm.opencsw.org/testing/openssl_devel-0.9.8l,REV=2009.11.07-SunOS5.8-i386-CSW.pkg.gz Best regards, Yann --------------------------------------------------------------------------- Dear users, A security vulnerability has been recently found in the TLS and SSL protocol part related to the handling of session renegotiation [1]. This vulnerability allows an attacker to inject arbitrary content at the beginning of a TLS/SSL connection. This problem is caused by a design flaw in the TLS/SSL protocol and is difficult to fix in a clean and backward compatible way. As a result the new openssl release (0.9.8l) which fixes this bug simply completely disables renegotiation. This new package will hit csw unstable mirror very soon. This modification should not have any impact for most setups except for Apache https configurations which use certificate client verification (SSLVerifyClient) or specify a new ssl cipher list (SSLCipherSuite) in a directory or location context. If that's your case, you should try to use these instructions on the server or virtual host level, or avoid upgrading to openssl 0.9.8l, but you will stay vulnerable in the latter. A new protocol extension to TLS is planned to address this issue but the RFC draft is still under review and it will require both the client and the server to implement the extension. Best regards Yann [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 From bonivart at opencsw.org Wed Dec 2 22:56:36 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 2 Dec 2009 22:56:36 +0100 Subject: [csw-maintainers] Openssl vulnerability CVE-2009-3555 In-Reply-To: <4B16D666.9030804@pleiades.fr.eu.org> References: <4B16D666.9030804@pleiades.fr.eu.org> Message-ID: <625385e30912021356j4f3cbc96n26150d62ecedbb5e@mail.gmail.com> On Wed, Dec 2, 2009 at 10:04 PM, Yann Rouillard wrote: > ?- release openssl 0.9.8l with renegotiation disabled and warn our users. > ? It would be nice for users who don't want to upgrade to be able to forbid > a package upgrade in pkg-get / pkgutil configuration. Users of pkgutil 1.9 could add the following in pkgutil.conf: exclude_pattern=CSWossl That should skip the openssl packages. peter at opensolaris:~$ sudo pkgutil -i openssl Parsing catalog, may take a while... CURRENT packages: CSWcacertificates-20091101,REV=2009.11.01 CSWcommon-1.4.7,REV=2009.09.20 CSWcswclassutils-1.30,REV=2009.11.21 EXCLUDED packages: CSWossl CSWossldevel CSWosslrt CSWosslutils Nothing to do. peter at opensolaris:~$ -- /peter From glaw at opencsw.org Wed Dec 2 23:59:14 2009 From: glaw at opencsw.org (Gary Law) Date: Wed, 2 Dec 2009 22:59:14 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr Message-ID: Hi all Been chatting with Maciej about a bug/feature I've hit where I can't properly install CSWcswclassutils, as it wants to write in /usr, and that's mounted readonly (it's a non-global zone). Does this mean CSWcswclassutils violates policy? I thought we had to confine ourselves to /opt, /etc/opt/csw and /var/opt/csw Maciej suggested non-global zones and/or non-writable /usr aren't supported by CSW, which may be correct, but is news to me. Thoughts? Gary -- glaw at opencsw.org From bonivart at opencsw.org Thu Dec 3 00:01:57 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 3 Dec 2009 00:01:57 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: Message-ID: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> On Wed, Dec 2, 2009 at 11:59 PM, Gary Law wrote: > Hi all > > Been chatting with Maciej about a bug/feature I've hit where I can't > properly install CSWcswclassutils, as it wants to write in /usr, and > that's mounted readonly (it's a non-global zone). > > Does this mean CSWcswclassutils violates policy? I thought we had to > confine ourselves to /opt, /etc/opt/csw and /var/opt/csw > > Maciej suggested non-global zones and/or non-writable /usr aren't > supported by CSW, which may be correct, but is news to me. > > Thoughts? It's how Sun designed it. Just install that package from the global zone and be done with it. :-) -- /peter From bwalton at opencsw.org Thu Dec 3 03:49:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 02 Dec 2009 21:49:12 -0500 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> Message-ID: <1259808438-sup-9303@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Nov 26 08:59:48 -0500 2009: > On line 94 from /opt/csw/share/perl/5.8.8/ExtUtils/Install.pm it must > say > my(%from_to) = @$from_to; > I changed this only on build8s, please verify that this works. This was reverted on build8s then? Git is broken by this bug too. Peter, are you patching the CSWperl build or waiting for an upstream fix (5.8.9)? Can we manually correct the issue, as per Dago's sleuthing, in the meantime? 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. From dam at opencsw.org Thu Dec 3 10:13:36 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Dec 2009 10:13:36 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: <1259808438-sup-9303@ntdws12.chass.utoronto.ca> References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> <1259808438-sup-9303@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 03.12.2009 um 03:49 schrieb Ben Walton : > Excerpts from Dagobert Michelsen's message of Thu Nov 26 08:59:48 -0500 2009 > : > >> On line 94 from /opt/csw/share/perl/5.8.8/ExtUtils/Install.pm it must >> say >> my(%from_to) = @$from_to; > >> I changed this only on build8s, please verify that this works. > > This was reverted on build8s then? Git is broken by this bug too. > Peter, are you patching the CSWperl build or waiting for an upstream > fix (5.8.9)? > > Can we manually correct the issue, as per Dago's sleuthing, in the > meantime? Unfortunately some modules require the old line. I guess the only viable solution until 5.10.1 is to not replace the build-in module containing the file. Best regards -- Dago From skayser at opencsw.org Thu Dec 3 12:40:56 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 3 Dec 2009 12:40:56 +0100 Subject: [csw-maintainers] OpenCSW Winter Camp - 23/24 Jan 2010. Who is coming? Message-ID: <20091203114056.GA26420@sebastiankayser.de> Hi, the venue and dates are fixed. Winter Camp will get us together in a cosy seminar hotel near the Bavarian mountains on 23.01./24.01. next year. http://wiki.opencsw.org/wintercamp-2009 I have updated the wiki page with details. The hotel doesn't have a online booking system, so those of you who can make their way please send me an email (by 17.12.2009) so that I can let them know with how many people we are attending and take care of the room bookings. Except for the room rate (approx 60EUR / night for a single) everything will be covered by the company I work for, so you just need to get there. :) Any questions, just let me know. Hope to see you there. Sebastian From maciej at opencsw.org Thu Dec 3 13:31:41 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 3 Dec 2009 12:31:41 +0000 Subject: [csw-maintainers] [csw-buildfarm] Building postgresql-8.4.1 In-Reply-To: References: <988C113A-0FD5-4D91-B3DE-8174D2620B61@opencsw.org> Message-ID: On Wed, Dec 2, 2009 at 3:28 PM, Dagobert Michelsen wrote: > You can boot a Solaris 8 and 9 Sparc in 32 or 64 bit. Yes, this is > an artifical example. However, I have a very bad feeling selecting > this at runtime. I understand this gut feeling. However, there aren't any obvious failure modes (apart from the one where can run Solaris 8 in either 32 or 64 bit mode). Also, there aren't much consequences of attempting to run incompatible executable / data combinarion. I tested that; the database server just won't start up, there's an error message in the log file, you can copy the files to a machine with the right architecture, or you configure the start script to use the right binary. I'll put some information in the postinstall script, and also a README file. > I just don't like the idea of copying an > installation from one machine to another and it then doesn't work > but I may be too picky here... I think you might be too picky. I talked to a PostgreSQL developer today to ask about what practices are common for moving databases. Moving raw data files can be used, but it's only expected to work between machines of the same architecture. Otherwise dump/restore or replication can be used. Meanwhile, I put PostgreSQL 8.4.1 into testing/. It uses a different layout than the current package: - /opt/csw prefix - /opt/csw/bin/postgresql/8.4/ - /var/opt/csw/postgresql/8.4/pgdata for the data - includes contrib (pgbench, etc.) - allows to choose between 32/64 bit - uses isaexec by default Maciej From maciej at opencsw.org Thu Dec 3 15:36:31 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 3 Dec 2009 14:36:31 +0000 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: <83CED7D4-8FCB-4D9D-965F-4D8975BEEF6D@opencsw.org> Message-ID: On Thu, Nov 19, 2009 at 4:56 PM, Eric J Korpela wrote: > Sure. ?I'll do initial builds on machines here. ?I probably won't move > in to /testing until the apparent issues with the libraries are > resolved. wxwidgets in testing is a release candidate. It ships the old binaries ripped from the 2.8.5 package and the new ones built with GAR. Unless there are problems with it, I'm going to submit them for release next week. Maciej From dam at opencsw.org Thu Dec 3 15:57:10 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Dec 2009 15:57:10 +0100 Subject: [csw-maintainers] Update on buildfarm: Takes longer Message-ID: <68AA9784-2EE1-4CDC-9FCB-0A47424DADF4@opencsw.org> Hi, there is some progress on updating the buildfarm. The following tasks have been finished: - HBA has been plugged in - FC array has been set up and new zpool created for user homes - LSI firmware has been updated Unfortunately, some tasks still run and will probably do so until tomorrow: - Copying the user homes to the new zpool - Updating Solaris to Solaris 10U8. After the machine has been rebooted when the above tasks have finished I will also upgrade the firmware for LDom support to finally install OpenSolaris Sparc at some later point. So enjoy one free evening or use build8s.go.opencsw.org instead ;-) Sorry for the inconvenience -- Dago From dam at opencsw.org Thu Dec 3 16:32:20 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Dec 2009 16:32:20 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> <4AD1C002.1050409@opencsw.org> <7D96D3D3-FA0A-40E1-9549-9114E56174DC@opencsw.org> <4AF18FE6.9040703@opencsw.org> <4AF1A21C.4060201@opencsw.org> <25FB7213-E65F-4115-8DC9-50D57113E275@opencsw.org> <8853603E-D4FD-4534-8D3C-5781B3FC4286@opencsw.org> <4AF48870.2040308@opencsw.org> Message-ID: Hi Maciej, Am 02.12.2009 um 16:47 schrieb Maciej (Matchek) Blizinski: > What does replatforms do? Which stages does it reset? All. It does gmake spotless gmake platforms Probably too invasive to be useful. > Perhaps it would be better to have more descriptive target names, > for example: > > gmake platforms-reconfigure > gmake platforms-repackage > gmake platforms-clean Sounds good. Would you mind adding a feature request? I'll have some unpleasent certification things to do until the end of the year, so I will probably not have time to do nice-to-have things at the moment. Best regards -- Dago From dam at opencsw.org Thu Dec 3 23:13:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Dec 2009 23:13:18 +0100 Subject: [csw-maintainers] Update on buildfarm: Finished In-Reply-To: <68AA9784-2EE1-4CDC-9FCB-0A47424DADF4@opencsw.org> References: <68AA9784-2EE1-4CDC-9FCB-0A47424DADF4@opencsw.org> Message-ID: <853E9782-1424-4FFC-9592-A3A1B69BE9BA@opencsw.org> Hi, Am 03.12.2009 um 15:57 schrieb Dagobert Michelsen: > there is some progress on updating the buildfarm. The following tasks > have been finished: > > - HBA has been plugged in > - FC array has been set up and new zpool created for user homes > - LSI firmware has been updated > > Unfortunately, some tasks still run and will probably do so until > tomorrow: > > - Copying the user homes to the new zpool > - Updating Solaris to Solaris 10U8. > > After the machine has been rebooted when the above tasks have > finished I will also upgrade the firmware for LDom support to > finally install OpenSolaris Sparc at some later point. > > So enjoy one free evening or use build8s.go.opencsw.org instead ;-) - Firmware has been patched to support LDoms in the future - All Solaris 10 Sparc Zones are running U8 now with latest patchset - All user homes, mirrors and archives have been migrated from the internal disks to a SATA-FC-JBOD with ZFS freeing up space for the new control domain and OSOL LDom The farm should be fully functional again. Please keep your eyes open if you see anything unusual. Best regards -- Dago From bwalton at opencsw.org Fri Dec 4 03:21:55 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 03 Dec 2009 21:21:55 -0500 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> <1259808438-sup-9303@ntdws12.chass.utoronto.ca> Message-ID: <1259893227-sup-3790@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Dec 03 04:13:36 -0500 2009: Hi Dago, > Unfortunately some modules require the old line. I guess the only > viable solution until 5.10.1 is to not replace the build-in module > containing the file. What packages would that affect then? If it was updated due to requests, presumably we're at a point where either choice will have negative impact on some packaging efforts? 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 Fri Dec 4 10:45:57 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Dec 2009 10:45:57 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: <1259893227-sup-3790@ntdws12.chass.utoronto.ca> References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> <1259808438-sup-9303@ntdws12.chass.utoronto.ca> <1259893227-sup-3790@ntdws12.chass.utoronto.ca> Message-ID: <23FA802C-4C6E-47B8-835E-D7DA6054DA93@opencsw.org> Hi Ben, Am 04.12.2009 um 03:21 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Thu Dec 03 04:13:36 > -0500 2009: > >> Unfortunately some modules require the old line. I guess the only >> viable solution until 5.10.1 is to not replace the build-in module >> containing the file. > > What packages would that affect then? If it was updated due to > requests, presumably we're at a point where either choice will have > negative impact on some packaging efforts? Well, the problem was that some packages needed a more recent version of MakeMaker then the one shipped with Perl 5.8.8. So we replaced the MakeMaker version shipped with Perl 5.8.8 with a current version. This fixes packages which needed an updated version of MakeMaker. This new version seems to use an idiom not understood in all cases by the old version of Perl causing some package using the old idiom to break. The idea is that Perl 5.10.1 already has an updated MakeMaker shipped, which only uses supported idioms as it is tested together with that Perl version. At least this is how I understood what happened. Best regards -- Dago From maciej at opencsw.org Fri Dec 4 11:52:28 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 4 Dec 2009 10:52:28 +0000 Subject: [csw-maintainers] Building MySQL 5.1.x In-Reply-To: References: Message-ID: On Wed, Dec 2, 2009 at 6:27 PM, Philip Brown wrote: > Maybe you should follow its suggestion and regenerate those files > using autoconf, etc. "autoreconf -fi" didn't help. I blame libtool installation on build8s. There must be libtool 2.2.6 lurking somewhere. Maciej From dam at opencsw.org Fri Dec 4 12:03:16 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Dec 2009 12:03:16 +0100 Subject: [csw-maintainers] Building MySQL 5.1.x In-Reply-To: References: Message-ID: <48E837C1-8FC2-41D0-9379-6BEABF129BD4@opencsw.org> Hi Maciej, Am 02.12.2009 um 16:55 schrieb Maciej (Matchek) Blizinski: > I'm looking at MySQL 5.1. I'm currently experimenting with building > it in /opt/csw, with the support for different versions (5.0, 5.1 and > so forth). I'm starting this thread to track everything related to > building and testing MySQL 5.1. > > I've just run into this: > > source='conf_to_src.c' object='conf_to_src.o' libtool=no \ > DEPDIR=.deps depmode=none /bin/bash ../depcomp \ > /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. > -I../include -I../include -I../include -I/opt/csw/include > -I/opt/csw/include/mysql5/5.1 -g -DSAFE_MUTEX -g -xarch=v8 -mt > -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 > -DHAVE_CURSES_H > -I/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/ > work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/include > -DHAVE_RWLOCK_T -DUNIV_SOLARIS -DUNIV_SOLARIS -c conf_to_src.c > /bin/bash ../libtool --preserve-dup-deps --tag=CC --mode=link > /opt/studio/SOS11/SUNWspro/bin/cc -g -DSAFE_MUTEX -g -xarch=v8 -mt > -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 > -DHAVE_CURSES_H > -I/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/ > work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/include > -DHAVE_RWLOCK_T -DUNIV_SOLARIS -DUNIV_SOLARIS -static -xarch=v8 > -L/opt/csw/lib -L/opt/csw/lib/mysql5/5.1 -L/opt/csw/lib -o > conf_to_src conf_to_src.o xml.o ctype.o bcmp.o -lpthread -lposix4 > -lresolv -lc -lsocket -lnsl -lm -lpthread > libtool: Version mismatch error. This is libtool 2.2.6, but the > libtool: definition of this LT_INIT comes from libtool 2.2.6b. > libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 > libtool: and run autoconf again. > gmake[4]: *** [conf_to_src] Error 63 > gmake[4]: *** Waiting for unfinished jobs.... > gmake[4]: Leaving directory > `/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/ > work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/strings' > > This is a completely clean build, no preexisting files. Has anyone > seen this problem before? *Sigh* I did update libtool to 2.2.6b a couple of days ago. Most certainly this is the cause for the problem. However, I don't understand why it actually *is* a problem as the macros should only be pulled in when the autoconf-files are regenerated. I can offer to look at the problem but won't consider myself a libtool wizard. Best regards -- Dago From maciej at opencsw.org Fri Dec 4 12:40:22 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 4 Dec 2009 11:40:22 +0000 Subject: [csw-maintainers] GPG package verification Message-ID: When pkg-get or pkgutil verify the gpg signature of a catalog file, what is it that it's specifically checking for? My guess is that it checks for any good signature from any trusted key from root's keyring. The assumption here is that there isn't any bogus key imported into root's keyring. Otherwise, someone could hijack DNS, and serve their own catalog with their signature. pkg-get or pkgutil would look at the signature and say: "It's a good signature from badguy at evil.com. I have that UID in my keyring, looks good to me!" and let the package install. Debian uses a separate keyring for package verification. Perhaps we should have something similar? What I would like to be able to control there, is: - there's a known set of gpg keys used to verify packages - the set of gpg keyrings is easy to control by running specific scripts or dropping files into directories Thoughts or suggestions? Maciej From maciej at opencsw.org Fri Dec 4 12:37:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 4 Dec 2009 11:37:47 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: On Mon, Nov 30, 2009 at 6:01 PM, Philip Brown wrote: > Maciej, I apologise if you feel "disgruntled" in any way... While I > understand it might be frustrating to redo work, I thought we had > actually found the best way to move forward. > > To resummarize (and recap a bit for the wider audience): > The core issue is that we have 3 packages: > > CSWsudo - ?"minimal" sudo (aka "normal" sudo that most people want) > CSWsudoldap - LDAP enabled sudo > CSWsudo-common ?- common files. > > > The first two packages provide either a "sudo_minimal" or "sudo_ldap" binary. > The issue revolves around how/what creates /opt/csw/bin/sudo. > > we need to be able to have all installed, and not cause conflicts. > We also need to have "sudo" behave as desired by the site admins. > > After discussing various options, I think that the solution that > addresses all of Maciej's concerns, is to have CSWsudo also create a > symlink of /opt/csw/bin/sudo ->sudo_minimal in a postinstall script, > If and only If /opt/csw/bin/sudo does not already exist. > > I suggested that on nov 18th, and did not see any objection, or any > reply at all, after that. > I presumed that meant he was working on the update. But now I guess not...? Sorry for my last grumpy e-mail, I was just frustrated and angry. I started to reply to the last sudo-related e-mail and realized that we have to start from the very beginning, i.e.: what is CSWsudo_ldap for, and how is it supposed to be used. I guess that there's just no other way, so let's go ahead and do it. My best guess about CSWsudo and CSWsudo_ldap is that CSWsudo is a an alternative version of sudo, created so that CSWsudo would not be dependent on the ldap packages, and users would not be forced to install ldap just to have simple sudo. The obvious way of doing it would be to have CSWsudo and CSWsudo_ldap mutually incompatible: user installs one or the other. There's no gain in installing both, as sudo_ldap pulls ldap packages, so all the benefit of CSWsudo (without the dependency) is lost. The current way sudo is packaged is probably a work in progress which become stuck at some point. I don't see any sense of CSWsudo_common installing a dangling symlink from /opt/csw/bin/sudo to /opt/csw/bin/sudo.minimal. I agree that if CSWsudo installed the symlink if it wasn't already there would fix the discussed failure mode. However, it strikes me as an attempt do deal with this one failure mode without looking at the bigger picture, or perhaps Phil and I have different bigger pictures. If I wanted to switch between ldap-enabled and minimal sudo, I would expect the following to work: pkgrm CSWsudo_ldap pkg-get -i CSWsudo or pkgrm CSWsudo pkg-get -i CSWsudo_ldap Anything else is in my opinion unintuitive. If we wanted a solution with both binaries installed at the same time (assuming there's a benefit there), we would need a mechanism for switching the alternatives. I'll be happy to discuss that, and deploy a thought-through solution. I don't want to start messing with symlinks with no design in place. Maciej From dam at opencsw.org Fri Dec 4 13:36:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Dec 2009 13:36:51 +0100 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Hi Phil, Am 04.12.2009 um 12:37 schrieb Maciej (Matchek) Blizinski: > If we wanted a solution with both binaries installed at the same time > (assuming there's a benefit there), we would need a mechanism for > switching the alternatives. I'll be happy to discuss that, and deploy > a thought-through solution. I don't want to start messing with > symlinks with no design in place. This exact same problem is there for tcpwrappers as you stated in the README: > TCP-Wrappers, from http://www.porcupine.org > > Note that the library is compiled to use LOG_LOCAL1 as the > syslog facility, NOT "LOG_MAIL", the default. > > ALSO, it uses /etc/opt/csw/hosts.xxx, NOT /etc/hosts.XXX > > man hosts_access(3), hosts_access(5), hosts_options(5) > for syntax on those. > > The compile has been hacked to provide a shared-library version > instead > of libwrap.a > There is an extra hack, in that there are default variable > definitions of > deny_severity and allow_severity, set to 0. > This is to allow for ./configure style tests, that break in the > transition > from lib.a to lib.so > > > Note also that there are TWO versions of libwrap.so: > libwrap-std.so.1 The "standard" tcp wrapper library > libwrap-ext.so.1 The "extended" tcp wrapper library > > By default, /opt/csw/lib/libwrap.so.1 is linked to the std version. > To use the extended syntax in hosts_options(5), you need to change > the link to point to libwrap-ext.so.1 > Unfortunately, the syntax for the two versions, is slightly > incompatible, > which is why there are two versions. Whatever solution we find for sudo, it should be applied for tcpwrappers too. Best regards -- Dago From maciej at opencsw.org Fri Dec 4 18:36:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 4 Dec 2009 17:36:58 +0000 Subject: [csw-maintainers] SOS12 on build9s Message-ID: I'm trying to build a package with SOS12 on build9s, but it's failing: checking for gcc... /opt/studio/SOS12/SUNWspro/bin/cc checking for C compiler default output file name... configure: error: in `/home/maciej/src/opencsw/pkg/pinentry/trunk/work/solaris9-sparc/build-isa-sparcv8/pinentry-0.7.6': configure: error: C compiler cannot create executables See `config.log' for more details. gmake: *** [configure-work/solaris9-sparc/build-isa-sparcv8/pinentry-0.7.6/configure] Error 77 gmake: Leaving directory `/home/maciej/src/opencsw/pkg/pinentry/trunk' gmake: *** [merge-isa-sparcv8] Error 2 gmake: Leaving directory `/home/maciej/src/opencsw/pkg/pinentry/trunk' Connection to build9s closed. gmake: *** [platforms] Error 2 config.log says: configure:2949: /opt/studio/SOS12/SUNWspro/bin/cc -xO3 -m32 -xarch=v8 -D__EXTENSIONS__ -I/opt/csw/X11/include -I/opt/csw/include -m32 -xarch=v8 -L/opt/csw/lib -L/opt/csw/X11/lib conftest.c >&5 ./configure: /opt/studio/SOS12/SUNWspro/bin/cc: No such file or directory configure:2953: $? = 127 configure:2991: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "pinentry" | #define PACKAGE_TARNAME "pinentry" | #define PACKAGE_VERSION "0.7.6" | #define PACKAGE_STRING "pinentry 0.7.6" | #define PACKAGE_BUGREPORT "gnupg-devel at gnupg.org" | #define PACKAGE "pinentry" | #define VERSION "0.7.6" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2997: error: in `/home/maciej/src/opencsw/pkg/pinentry/trunk/work/solaris9-sparc/build-isa-sparcv8/pinentry-0.7.6': configure:3000: error: C compiler cannot create executables See `config.log' for more details. Checking for the binary: maciej at build9s :~ > ls -l /opt/studio/SOS12/SUNWspro/bin/cc lrwxrwxrwx 1 root other 14 Jan 23 2009 /opt/studio/SOS12/SUNWspro/bin/cc -> ../prod/bin/cc maciej at build9s :~ > ls -l /opt/studio/SOS12/SUNWspro/bin/../prod/bin/cc -rwxr-xr-x 1 root sys 280268 May 1 2009 /opt/studio/SOS12/SUNWspro/bin/../prod/bin/cc It's there. Before I spend time debugging that, do you have any ideas? Maciej From phil at bolthole.com Fri Dec 4 20:38:33 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Dec 2009 11:38:33 -0800 Subject: [csw-maintainers] GPG package verification In-Reply-To: References: Message-ID: On Fri, Dec 4, 2009 at 3:40 AM, Maciej (Matchek) Blizinski wrote: > When pkg-get or pkgutil verify the gpg signature of a catalog file, > what is it that it's specifically checking for? ?My guess is that it > checks for any good signature from any trusted key from root's > keyring. > True. > Debian uses a separate keyring for package verification. ?Perhaps we > should have something similar? err, debian uses gpg completely differently. it has a keyring, because it has each maintainer INDIVIDUALLY sign their packages. Which means you then need a whole keyring/web of trust/blahblah to verify ALL the maintainers. whereas we, at the moment, only sign the catalog, which has hashes of all the packages it knows about. This provides about the same level of non-tamperability, with much less hassle to the maintainers individuallly. (but more hassle for ME as the release manager ;-) Now, that being said,we COULD theoretically have pkgutil and pkg-get explicitly check for a particular signature, instead of just "any signature" I suppose. From phil at bolthole.com Fri Dec 4 20:40:06 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Dec 2009 11:40:06 -0800 Subject: [csw-maintainers] SOS12 on build9s In-Reply-To: References: Message-ID: On Fri, Dec 4, 2009 at 9:36 AM, Maciej (Matchek) Blizinski wrote: > > Checking for the binary: > > maciej at build9s :~ > ls -l /opt/studio/SOS12/SUNWspro/bin/cc > lrwxrwxrwx ? 1 root ? ? other ? ? ? ? 14 Jan 23 ?2009 > /opt/studio/SOS12/SUNWspro/bin/cc -> ../prod/bin/cc > maciej at build9s :~ > ls -l /opt/studio/SOS12/SUNWspro/bin/../prod/bin/cc > -rwxr-xr-x ? 1 root ? ? sys ? ? ? 280268 May ?1 ?2009 > /opt/studio/SOS12/SUNWspro/bin/../prod/bin/cc > > It's there. ?Before I spend time debugging that, do you have any ideas? > you've proved there is a binary. you havent proved it works. show that it works first ;-) start with "cc -V" and then move on to cat >test.c < References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Fri, Dec 4, 2009 at 4:36 AM, Dagobert Michelsen wrote: > > Whatever solution we find for sudo, it should be applied for tcpwrappers > too. I disagree. tcpwrappers is a GLOBALLY SHARED LIBRARY, that has MULTIPLE packages dependant on it. that forces us to provide a single shared lib, and hence its current installtime behaviour. whereas sudo, is just an executable, that has nothing dependant on it. That means that it is perfectly allowable to have BOTH executables present. > There's no >gain in installing both, as sudo_ldap pulls ldap packages, so all the >benefit of CSWsudo (without the dependency) is lost. I would have to disagree here. on multiple levels. But I'll just state the simplest useful reason to allow both: picture an environment where ldap is USUALLY used. in this case, sudo_ldap would be routinely used. however, one day, "something bad happens", where both root login, and ldap information, is messed up. It then becomes very very useful, to have sudo.minimal installed and ready to use, as a fallback cleanup tool. From dam at opencsw.org Sat Dec 5 17:43:33 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 5 Dec 2009 17:43:33 +0100 Subject: [csw-maintainers] SOS12 on build9s In-Reply-To: References: Message-ID: <7E34193F-F569-417C-8AB7-032484C66C25@opencsw.org> Hi Maciej, Am 04.12.2009 um 18:36 schrieb Maciej (Matchek) Blizinski: > It's there. Before I spend time debugging that, do you have any > ideas? Yes, because it tries to build on build8s instead of build9s, and as SOS12 doesn't run on Solaris 8 it is not installed there: > [===== Building modulation 'isa-sparcv8' on host 'build8s' =====] > ssh build8s "PATH=/home/dam/mgar/pkg/pinentry/trunk/gar/bin/sos12- > wrappers:/home/dam/mgar/pkg/pinentry/trunk/work/solaris9-sparc/ > install-global/opt/csw/bin:/home/dam/mgar/pkg/pinentry/trunk/work/ > solaris9-sparc/install-global/opt/csw/bin:/home/dam/mgar/pkg/ > pinentry/trunk/work/solaris9-sparc/install-global/opt/csw/sbin:/home/ > dam/mgar/pkg/pinentry/trunk/work/solaris9-sparc/install-global/opt/ > csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/ > studio/SOS12/SUNWspro/bin:/home/dam/mgar/pkg/pinentry/trunk/gar/bin:/ > usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin gmake - > C /home/dam/mgar/pkg/pinentry/trunk PLATFORM=solaris9-sparc > MODULATION=isa-sparcv8 ISA=sparcv8 merge-modulated" The PACKAGING_PLATFORMS currently only specify on which the hosts the package is assembled. I guess it should also set the minimum OS level where the package is built, but it currently doesn't do that. In the meantime I added a patch as r7558 resetting the default buildhosts for pinetry. Hopefully I can fix this cleanly in GAR on monday. BTW, please make sure you do "gmake garchive" some time so the source files get archived. Best regards -- Dago From maciej at opencsw.org Sat Dec 5 17:11:32 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Dec 2009 16:11:32 +0000 Subject: [csw-maintainers] SOS12 on build9s In-Reply-To: References: Message-ID: On Fri, Dec 4, 2009 at 7:40 PM, Philip Brown wrote: > you've proved there is a binary. you havent proved it works. show that > it works first ;-) > > start with "cc -V" > > and then move on to > > cat >test.c < main(){} > EOF > cc -o t test.c maciej at build9s :~ > /opt/studio/SOS12/SUNWspro/prod/bin/cc -V cc: Sun C 5.9 SunOS_sparc Patch 124867-11 2009/04/30 usage: cc [ options] files. Use 'cc -flags' for details maciej at build9s :~ > cat >test.c < main(){} continued> EOF maciej at build9s :~ > /opt/studio/SOS12/SUNWspro/prod/bin/cc -o t test.c "test.c", line 1: warning: old-style declaration or incorrect type for: main maciej at build9s :~ > echo $? 0 The binary works. Any ideas what else might have gone wrong? From maciej at opencsw.org Sat Dec 5 20:50:20 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Dec 2009 19:50:20 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Fri, Dec 4, 2009 at 7:51 PM, Philip Brown wrote: >> There's no >>gain in installing both, as sudo_ldap pulls ldap packages, so all the >>benefit of CSWsudo (without the dependency) is lost. > > I would have to disagree here. on multiple levels. > But I'll just state the simplest useful reason to allow both: > > picture an environment where ldap is USUALLY used. ?in this case, > sudo_ldap would be routinely used. > > however, one day, "something bad happens", where both root login, and > ldap information, is messed up. ?It then becomes very very useful, to > have sudo.minimal installed and ready to use, as a fallback cleanup > tool. Is it a case that you know how to reproduce, or is it just a hunch? I'm asking, because I can't an obvious case of this problem. If the information that joe has sudo access is stored in ldap and ldap is unavailable, joe will not get root with sudo.ldap nor sudo.minimal. If the information that joe has access is stored locally, sudo.ldap will look in both places and grant joe access. Having sudo.minimal installed doesn't make it any better or worse. Regardless to whether it makes sense to have both packages installed at the same time, we can consider the general case of providing alternatives. Let's suppose functionality baz provided by either foo or bar. We want to type "baz" and have the job done. However, in some cases we want to use foo or bar specifically. How do we handle that? Maciej From maciej at opencsw.org Sun Dec 6 11:07:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 6 Dec 2009 10:07:47 +0000 Subject: [csw-maintainers] SOS12 on build9s In-Reply-To: <7E34193F-F569-417C-8AB7-032484C66C25@opencsw.org> References: <7E34193F-F569-417C-8AB7-032484C66C25@opencsw.org> Message-ID: On Sat, Dec 5, 2009 at 4:43 PM, Dagobert Michelsen wrote: > The PACKAGING_PLATFORMS currently only specify on which the hosts the > package is assembled. I guess it should also set the minimum OS level > where the package is built, but it currently doesn't do that. In the > meantime I added a patch as r7558 resetting the default buildhosts > for pinetry. I've spent some time on it and got pinentry to build with SOS11. I had replace one macro by hand, but this was the easy patch. The next problem was that pinentry used getopt.h, so I had to use gnulib to add getopt support. I haven't built the 64-bit version: Solaris 10 has the file /usr/include/getopt.h which conflicts with the one created by gnulib, which was a problem on build10x. Now that we've got pinentry, I'll try go get it released soon and build gnupg 2.0 with pinentry support. We run into the alternatives problem again: I need gnupg 2.0 to be accessible as /opt/csw/bin/gpg. Maciej From bwalton at opencsw.org Sun Dec 6 14:46:10 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 06 Dec 2009 08:46:10 -0500 Subject: [csw-maintainers] SOS12 on build9s In-Reply-To: References: <7E34193F-F569-417C-8AB7-032484C66C25@opencsw.org> Message-ID: <1260106882-sup-7799@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sun Dec 06 05:07:47 -0500 2009: > Now that we've got pinentry, I'll try go get it released soon and > build gnupg 2.0 with pinentry support. We run into the alternatives > problem again: I need gnupg 2.0 to be accessible as /opt/csw/bin/gpg. GPG seems to be one place where neither Debian nor RHEL use their alternatives functionality. I _believe_ that this is due to the fact that gpg2 is not a pure superset of gpg's functionality. I ran into some issues when using gpg2 as my default gpg. I could sign and verify mail I sent, but others using gpg1 couldn't verify signatures I generated. As with much of the rest of the gpg documentation, tracking down info on this problem wasn't easy. In the end, I reverted to using gpg, as using gpg2 had been an experiment for other reasons only. If you need an app to use 2 by default, my recommendation would be twiddle a config knob if provided or build it with the /path/to/gpg2 built in instead. HTH.[1] -Ben [1] If you have info that makes gpg2 sign things in a way that older gpg can work with, I'd be interested to see it. -- 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 Sun Dec 6 14:48:15 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 6 Dec 2009 13:48:15 +0000 Subject: [csw-maintainers] Alternatives Message-ID: On Sat, Dec 5, 2009 at 7:50 PM, Maciej (Matchek) Blizinski wrote: > Let's suppose functionality baz provided by either foo > or bar. ?We want to type "baz" and have the job done. ?However, in > some cases we want to use foo or bar specifically. ?How do we handle > that? Here's an idea: reuse somebody else's work! We start with no symlink. netra ~ # ls -l /opt/csw/bin/sudo* -rwsr-xr-x 1 root bin 221736 Oct 5 19:26 /opt/csw/bin/sudoedit -rwxr-xr-x 1 root bin 245232 Oct 5 19:30 /opt/csw/bin/sudo.ldap -rwsr-xr-x 1 root bin 221736 Oct 5 19:26 /opt/csw/bin/sudo.minimal Let's tell the alternatives system that we've got something called 'sudo' which is provided by sudo.minimal. netra ~ # update-alternatives --install /opt/csw/bin/sudo sudo /opt/csw/bin/sudo.minimal 40 update-alternatives: using /opt/csw/bin/sudo.minimal to provide /opt/csw/bin/sudo (sudo) in auto mode. netra ~ # ls -l /opt/csw/bin/sudo* lrwxrwxrwx 1 root root 30 Dec 6 14:41 /opt/csw/bin/sudo -> /etc/opt/csw/alternatives/sudo -rwsr-xr-x 1 root bin 221736 Oct 5 19:26 /opt/csw/bin/sudoedit -rwxr-xr-x 1 root bin 245232 Oct 5 19:30 /opt/csw/bin/sudo.ldap -rwsr-xr-x 1 root bin 221736 Oct 5 19:26 /opt/csw/bin/sudo.minimal The alternatives system has chosen the best alternative, the highest priority number. (A bit counterintuitive direction.) Let's see what /etc/opt/csw/alternatives/sudo points at. netra ~ # ls -l /etc/opt/csw/alternatives/sudo lrwxrwxrwx 1 root root 25 Dec 6 14:41 /etc/opt/csw/alternatives/sudo -> /opt/csw/bin/sudo.minimal We can now add the ldap-enabled version of sudo: netra ~ # update-alternatives --install /opt/csw/bin/sudo sudo /opt/csw/bin/sudo.ldap 20 Let's see what the alternatives system says about sudo now. netra ~ # update-alternatives --display sudo sudo - auto mode link currently points to /opt/csw/bin/sudo.minimal /opt/csw/bin/sudo.ldap - priority 20 /opt/csw/bin/sudo.minimal - priority 40 Current `best' version is /opt/csw/bin/sudo.minimal. It has chosen the implementation based on priority. Let's try to modify it by hand. netra ~ # update-alternatives --config sudo There are 2 choices for the alternative sudo (providing /opt/csw/bin/sudo). Selection Path Priority Status ------------------------------------------------------------ * 0 /opt/csw/bin/sudo.minimal 40 auto mode 1 /opt/csw/bin/sudo.ldap 20 manual mode 2 /opt/csw/bin/sudo.minimal 40 manual mode Press enter to keep the current choice[*], or type selection number: 1 update-alternatives: using /opt/csw/bin/sudo.ldap to provide /opt/csw/bin/sudo (sudo) in manual mode. ...and see where the symlink points to now. netra ~ # ls -l /opt/csw/bin/sudo* lrwxrwxrwx 1 root root 30 Dec 6 14:44 /opt/csw/bin/sudo -> /etc/opt/csw/alternatives/sudo -rwsr-xr-x 1 root bin 221736 Oct 5 19:26 /opt/csw/bin/sudoedit -rwxr-xr-x 1 root bin 245232 Oct 5 19:30 /opt/csw/bin/sudo.ldap -rwsr-xr-x 1 root bin 221736 Oct 5 19:26 /opt/csw/bin/sudo.minimal This symlink hasn't changed, but... netra ~ # ls -l /etc/opt/csw/alternatives/sudo lrwxrwxrwx 1 root root 22 Dec 6 14:44 /etc/opt/csw/alternatives/sudo -> /opt/csw/bin/sudo.ldap This one now points at sudo. Thoughts? Maciej From bwalton at opencsw.org Sun Dec 6 15:00:28 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 06 Dec 2009 09:00:28 -0500 Subject: [csw-maintainers] Alternatives In-Reply-To: References: Message-ID: <1260107634-sup-2839@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sun Dec 06 08:48:15 -0500 2009: > Thoughts? I've always enjoyed this functionality on Debian and RHEL systems (implemented slightly differently, but with similar goals). -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 yann at pleiades.fr.eu.org Sun Dec 6 20:19:11 2009 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sun, 06 Dec 2009 20:19:11 +0100 Subject: [csw-maintainers] [Fwd: Re: [csw-users] Openssl vulnerability CVE-2009-3555] Message-ID: <4B1C03AF.7000203@pleiades.fr.eu.org> Hi, I don't know exactly what is the good answer to the following question asked on the csw users mailing list. Can someone enlighten me ? Yann -------- Message original -------- Sujet: Re: [csw-users] Openssl vulnerability CVE-2009-3555 Date: Sun, 6 Dec 2009 11:10:15 -0600 De: Mike Gerdts R?pondre ? :: Questions and discussions Pour :: Questions and discussions R?f?rences: <4B1B9DC4.9050009 at pleiades.fr.eu.org> On Sun, Dec 6, 2009 at 6:04 AM, Yann Rouillard wrote: > Dear users, > > A security vulnerability has been recently found in the TLS and SSL > protocol part related to the handling of session renegotiation [1]. This > vulnerability allows an attacker to inject arbitrary content at the > beginning of a TLS/SSL connection within a Man-in-the-middle attack. > > This problem is caused by a design flaw in the TLS/SSL protocol and is > difficult to fix in a clean and backward compatible way. As a result the > new openssl release (0.9.8l) which fixes this bug simply completely > disables renegotiation. > > This new package will hit csw unstable mirror very soon. What is the plan for updating stable? If there are no plans to maintain stable, is there a documented procedure for me to create a custom branch (e.g. mystable) that contains the fixes and updates that I care about? The current stable seems to be a bit stale. -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ users mailing list users at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/users From maciej at opencsw.org Sun Dec 6 23:41:19 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 6 Dec 2009 22:41:19 +0000 Subject: [csw-maintainers] [Fwd: Re: [csw-users] Openssl vulnerability CVE-2009-3555] In-Reply-To: <4B1C03AF.7000203@pleiades.fr.eu.org> References: <4B1C03AF.7000203@pleiades.fr.eu.org> Message-ID: On Sun, Dec 6, 2009 at 7:19 PM, Yann Rouillard wrote: > Hi, > > I don't know exactly what is the good answer to the following question asked > on the csw users mailing list. > > Can someone enlighten me ? > > Yann > (...) > What is the plan for updating stable? ?If there are no plans to > maintain stable, is there a documented procedure for me to create a > custom branch (e.g. mystable) that contains the fixes and updates that > I care about? ?The current stable seems to be a bit stale. I'd say: use bldcat to create own catalog with newer versions or fixes, then use it on top of the stable catalog using multiple catalogs in pkgutil.conf. I'm not sure if pkg-get can do the same. Maciej From phil at bolthole.com Mon Dec 7 18:05:27 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Dec 2009 09:05:27 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Sat, Dec 5, 2009 at 11:50 AM, Maciej (Matchek) Blizinski wrote: > > Regardless to whether it makes sense to have both packages installed > at the same time, we can consider the general case of providing > alternatives. ?Let's suppose functionality baz provided by either foo > or bar. ?We want to type "baz" and have the job done. ?However, in > some cases we want to use foo or bar specifically. ?How do we handle > that? > Whatever you come up with, needs to still allow all packages to be installed simultaneously. Can we do this with sudo now please? :-) From phil at bolthole.com Mon Dec 7 18:10:03 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Dec 2009 09:10:03 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: References: Message-ID: On Sun, Dec 6, 2009 at 5:48 AM, Maciej (Matchek) Blizinski wrote: > .... > > Here's an idea: reuse somebody else's work! >.... > Let's tell the alternatives system that we've got something called > 'sudo' which is provided by sudo.minimal. > .... > Thoughts? Sounds like it has potential. My two concerns are that 1. you havent spelled out how it would be used by a package, at pkgadd time. (please note that I explicitly used "pkgadd" there) 2. it should probably have some kind of csw-specific naming, rather than "update-alternatives" (not to mentiont that that name is just too durn long!! ;-) From maciej at opencsw.org Mon Dec 7 18:36:27 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 7 Dec 2009 17:36:27 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: References: Message-ID: On Mon, Dec 7, 2009 at 5:10 PM, Philip Brown wrote: > On Sun, Dec 6, 2009 at 5:48 AM, Maciej (Matchek) Blizinski > wrote: >> .... >> >> Here's an idea: reuse somebody else's work! >>.... >> Let's tell the alternatives system that we've got something called >> 'sudo' which is provided by sudo.minimal. >> > > .... >> Thoughts? > > Sounds like it has potential. > My two concerns are that > > 1. you havent spelled out how it would be used by a package, at pkgadd time. > > (please note that I explicitly used "pkgadd" there) You forgot to explicitly mention pkgrm. ;-) It's package's responsibility to register and deregister binaries. Either a post{install,remove} script or a new class action script. > 2. it should probably have some kind of csw-specific naming, rather > than "update-alternatives" Why should it? It's not specific to CSW. It can be used to use alternatives from any package provider. From bwalton at opencsw.org Mon Dec 7 18:48:09 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Dec 2009 12:48:09 -0500 Subject: [csw-maintainers] Alternatives In-Reply-To: References: Message-ID: <1260206340-sup-1423@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Dec 07 12:10:03 -0500 2009: > 1. you havent spelled out how it would be used by a package, at pkgadd time. > > (please note that I explicitly used "pkgadd" there) My suggestion here would be a CAS. The action to take if no current 'altnernative' is in place is to use the default of the package being provided. A package installing a new 'alternative' that finds the link existing already should NOTE this and carry on. So, in the prototype, a file marked class cswalternative /opt/csw/bin/sudo may or may not provide an actual file in the end. At removal, if the target of the link is still there, the link itself should be left in tact. > 2. it should probably have some kind of csw-specific naming, rather > than "update-alternatives" That sounds reasonable, although I don't have anything better to offer right now. -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 Mon Dec 7 18:50:45 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Dec 2009 12:50:45 -0500 Subject: [csw-maintainers] Alternatives In-Reply-To: References: Message-ID: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Dec 07 12:36:27 -0500 2009: > Why should it? It's not specific to CSW. It can be used to use > alternatives from any package provider. No, I think Phil is right here. As much as restricting ourselves to /opt/csw would also restrict overall usefulness, it's the only policy (in my current thinking) that wouldn't open a big nasty can of worms. It'd be great to replace /usr/lib/sendmail using these mechanisms, but if other packages aren't aware of the system, it really wouldn't help much anyway. 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 Mon Dec 7 19:14:53 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 7 Dec 2009 18:14:53 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Dec 7, 2009 at 5:50 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Mon Dec 07 12:36:27 -0500 2009: > >> Why should it? ?It's not specific to CSW. ?It can be used to use >> alternatives from any package provider. > > No, I think Phil is right here. ?As much as restricting ourselves to > /opt/csw would also restrict overall usefulness, it's the only policy > (in my current thinking) that wouldn't open a big nasty can of worms. > > It'd be great to replace /usr/lib/sendmail using these mechanisms, but > if other packages aren't aware of the system, it really wouldn't help > much anyway. What if I have my own in-house built package? It's going to use a different installation prefix, and all will be custom. It will depend CSWalternatives and use it. We would restrict ourselves to /opt/csw, but it doesn't mean that the alternatives mechanism can be used only within /opt/csw, so it's not CSW specific -- in the sense that you can use for any package you want, CSW or not. After all, it's just another program, which wasn't even written with Solaris in mind, not to mention CSW. Maciej From bwalton at opencsw.org Mon Dec 7 19:23:58 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Dec 2009 13:23:58 -0500 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> Message-ID: <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Dec 07 13:14:53 -0500 2009: > What if I have my own in-house built package? It's going to use a > different installation prefix, and all will be custom. It will depend > CSWalternatives and use it. Ok, that'd be fair. As long as you wouldn't be affecting, say, SUNW packages with this mechanism, it's fair to allow it to interoperate among packages that are aware of the functionality, I guess. > We would restrict ourselves to /opt/csw, but it doesn't mean that the > alternatives mechanism can be used only within /opt/csw, so it's not > CSW specific -- in the sense that you can use for any package you > want, CSW or not. After all, it's just another program, which wasn't > even written with Solaris in mind, not to mention CSW. Ok. :) 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 Dec 8 10:12:02 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 8 Dec 2009 09:12:02 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Mon, Dec 7, 2009 at 5:05 PM, Philip Brown wrote: > On Sat, Dec 5, 2009 at 11:50 AM, Maciej (Matchek) Blizinski > wrote: >> >> Regardless to whether it makes sense to have both packages installed >> at the same time, we can consider the general case of providing >> alternatives. ?Let's suppose functionality baz provided by either foo >> or bar. ?We want to type "baz" and have the job done. ?However, in >> some cases we want to use foo or bar specifically. ?How do we handle >> that? >> > > Whatever you come up with, needs to still allow all packages to be > installed simultaneously. > > Can we do this with sudo now please? :-) We don't have to do it now. Here's the reason: # cat /var/sadm/pkg/CSWsudoldap/save/pspool/CSWsudoldap/pkgmap : 1 489 1 f none /opt/csw/bin/sudo.ldap 0755 root bin 245232 16892 1254763822 1 i depend 227 20555 1254763830 1 i pkginfo 487 41164 1254763830 Look at the permissions: "/opt/csw/bin/sudo.ldap 0755". The CSWsudoldap package is contains a binary that is not setuid root. I would like to declare CSWsudoldap useless and ignore it for now. We'll worry about making CSWsudoldap an alternative when it's done properly, and when it actually works. From phil at bolthole.com Tue Dec 8 17:46:50 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Dec 2009 08:46:50 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Tue, Dec 8, 2009 at 1:12 AM, Maciej (Matchek) Blizinski wrote: > > # cat /var/sadm/pkg/CSWsudoldap/save/pspool/CSWsudoldap/pkgmap > : 1 489 > 1 f none /opt/csw/bin/sudo.ldap 0755 root bin 245232 16892 1254763822 > 1 i depend 227 20555 1254763830 > 1 i pkginfo 487 41164 1254763830 > > Look at the permissions: "/opt/csw/bin/sudo.ldap 0755". The > CSWsudoldap package is contains a binary that is not setuid root. ?I > would like to declare CSWsudoldap useless and ignore it for now. > We'll worry about making CSWsudoldap an alternative when it's done > properly, and when it actually works. oh wow. that's really sad. And yet, there IS a (very old) bug filed against the package, about something else. Please "do the right thing", and provide a properly packaged version update? its not like the older version "doesnt work at all". it just needs site-local fixes for the poor packaging :-( From dam at opencsw.org Wed Dec 9 17:01:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Dec 2009 17:01:32 +0100 Subject: [csw-maintainers] Fwd: [solarisx86] Perl issue References: <4B1E4A2D.7080800@mindspring.com> Message-ID: Hi Peter, Anfang der weitergeleiteten E-Mail: > Von: Phillip Bruce > Datum: 8. Dezember 2009 13:44:29 MEZ > An: solarisx86 at yahoogroups.com > Betreff: [solarisx86] Perl issue > Antwort an: solarisx86 at yahoogroups.com > > Anyone ran into this issue: > > Running make install > Can't coerce array into hash at > /opt/csw/share/perl/5.8.8/ExtUtils/Install.pm line 94. > gmake: *** [pure_site_install] Error 255 > /usr/sfw/bin/gmake install -- NOT OK > > what I was doing here is using perl -MCPAN -e shell and trying to > install Date::Format module. > > i tried using make under /usr/ccs/bin but it failed in the same way. > > Got same issue when running perl 5..8.4 > > Phillip It starts hurting users. Peter, could you please revert the update of MakeMaker or even better update to 5.10.1? Let me know if I can be of any help here. Best regards -- Dago From bwalton at opencsw.org Wed Dec 9 17:25:21 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Dec 2009 11:25:21 -0500 Subject: [csw-maintainers] Fwd: [solarisx86] Perl issue In-Reply-To: References: <4B1E4A2D.7080800@mindspring.com> Message-ID: <1260375875-sup-5462@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Dec 09 11:01:32 -0500 2009: > It starts hurting users. Peter, could you please revert the update > of MakeMaker or even better update to 5.10.1? Let me know if I can > be of any help here. Yes please. I don't care how it's resolved, but it's currently a blocking factor for me. 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 Dec 9 18:17:19 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Dec 2009 17:17:19 +0000 Subject: [csw-maintainers] Links from mantis to the 'processing bugs' wiki page In-Reply-To: References: Message-ID: On Tue, Sep 29, 2009 at 8:23 PM, Maciej (Matchek) Blizinski wrote: > 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? Sebastian? From bwalton at opencsw.org Thu Dec 10 01:18:19 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Dec 2009 19:18:19 -0500 Subject: [csw-maintainers] perl maintenance on buildfarm Message-ID: <1260404227-sup-6341@ntdws12.chass.utoronto.ca> Hi All, I'm in the process of down-revving CSWperl on the buildfarm. Please be patient if you experience problems in the next little while. 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 Thu Dec 10 08:24:11 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 07:24:11 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Tue, Dec 8, 2009 at 4:46 PM, Philip Brown wrote: > And yet, there IS a (very old) bug filed against the package, about > something else. > Please "do the right thing", and provide a properly packaged version update? > its not like the older version "doesnt work at all". it just needs > site-local fixes for the poor packaging :-( Filed bug 4074 about this issue. http://www.opencsw.org/mantis/view.php?id=4074 My brain says the right thing to do is: 1. Get the alternatives mechanism in place 2. Modify CSWsudo to use it 3. Modify CSWsudo_ldap to use it, give it higher priority (if both are installed at the same time, use sudo.ldap) 4. Remove the stupid symlink from CSWsudo_common 5. Release all three packages at the same time Does it look good? From maciej at opencsw.org Thu Dec 10 08:41:48 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 07:41:48 +0000 Subject: [csw-maintainers] Replacing existing Solaris functionality by OpenCSW packages In-Reply-To: References: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> Message-ID: On Tue, Nov 24, 2009 at 4:32 PM, Philip Brown wrote: > On Tue, Nov 24, 2009 at 7:54 AM, Dagobert Michelsen wrote: >> >>... >> As there is a "install all" option in pkg-get which is used it >> is adviseable to not install these replacemenet-packages by >> default. This may be accomplished by one of the following >> solutions: >> >> - Different [SVR4 pkg] prefix >> >> The addons would be named CSWX... to mark that they are Xtra >> to install. >>... >> >> - Different catalog >> >> The extra packages may be put in a separate catalog. >>... > > > Or by other methods. > > Such as defining additional standard global configs to go in csw.conf > > "replace_sun_pkgs=yes" > or some such? > > Then a postinstall script could check for that, and > rename/disable/replace/whatever as appropriate. > > I suppose we might even support different values. > > replace_sun_pkgs={replace,rename,???} > > (where one could mean simple "mv old binaries to .old", and another > might be "actually put in symlink to our binaries, and yet another > could mean "pkgrm conflicting") One package can't remove another package upon installation, can it? I think that the alternatives mechianism could be used to switch the implementation: mkdir /usr/libexec/sun mv /usr/bin/foo /usr/libexec/sun/foo update-alternatives --install /usr/bin/foo foo /usr/libexec/sun/foo 30 update-alternatives --install /usr/bin/foo foo /opt/csw/bin/foo 20 In this way, the Sun binary is still used. However, this could get messed up during OS patching or OS upgrades, I suppose. It's much better to have the conflicting SUNW packages uninstalled. Anyway, about handling the "install all CSW" scenario, isn't it better to just skip the packages which conflict with already installed ones? From maciej at opencsw.org Thu Dec 10 09:32:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 08:32:46 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> Message-ID: On Wed, Dec 2, 2009 at 11:01 PM, Peter Bonivart wrote: > On Wed, Dec 2, 2009 at 11:59 PM, Gary Law wrote: >> Hi all >> >> Been chatting with Maciej about a bug/feature I've hit where I can't >> properly install CSWcswclassutils, as it wants to write in /usr, and >> that's mounted readonly (it's a non-global zone). >> >> Does this mean CSWcswclassutils violates policy? I thought we had to >> confine ourselves to /opt, /etc/opt/csw and /var/opt/csw >> >> Maciej suggested non-global zones and/or non-writable /usr aren't >> supported by CSW, which may be correct, but is news to me. >> >> Thoughts? > > It's how Sun designed it. Just install that package from the global > zone and be done with it. :-) For the record: http://www.opencsw.org/bugtrack/view.php?id=3760 From glaw at opencsw.org Thu Dec 10 12:52:40 2009 From: glaw at opencsw.org (Gary Law) Date: Thu, 10 Dec 2009 11:52:40 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> Message-ID: HI 2009/12/10 Maciej (Matchek) Blizinski : > On Wed, Dec 2, 2009 at 11:01 PM, Peter Bonivart wrote: >> It's how Sun designed it. Just install that package from the global >> zone and be done with it. :-) > > For the record: > > http://www.opencsw.org/bugtrack/view.php?id=3760 OK, I don't think we should be using classutils then. It violates policy. The 'workaround' is clunky for some, and impossible if you don't have root on the global zone. -- Gary Law Email: garylaw at garylaw.net Chat googletalk/messenger: gary.law at gmail.com iChat/jabber/AIM: gary.law at mac.com From james at opencsw.org Thu Dec 10 13:08:40 2009 From: james at opencsw.org (James Lee) Date: Thu, 10 Dec 2009 12:08:40 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: Message-ID: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> On 10/12/09, 11:52:40, Gary Law wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > >> It's how Sun designed it. Just install that package from the global > >> zone and be done with it. :-) > > > > For the record: > > > > http://www.opencsw.org/bugtrack/view.php?id=3760 > OK, I don't think we should be using classutils then. It violates > policy. The 'workaround' is clunky for some, and impossible if you > don't have root on the global zone. I support Gary. I understand that classutils is clever and works well in some situations but it's not a complete solution and therefor we should look for something else. James. From bonivart at opencsw.org Thu Dec 10 13:27:26 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 10 Dec 2009 13:27:26 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> Message-ID: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> On Thu, Dec 10, 2009 at 12:52 PM, Gary Law wrote: > HI > > 2009/12/10 Maciej (Matchek) Blizinski : >> On Wed, Dec 2, 2009 at 11:01 PM, Peter Bonivart wrote: >>> It's how Sun designed it. Just install that package from the global >>> zone and be done with it. :-) >> >> For the record: >> >> http://www.opencsw.org/bugtrack/view.php?id=3760 > > OK, I don't think we should be using classutils then. It violates > policy. The 'workaround' is clunky for some, and impossible if you > don't have root on the global zone. You made a choice using a shared file system you don't have write access to in any way. Sounds like a bad choice. :-) -- /peter From maciej at opencsw.org Thu Dec 10 13:47:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 12:47:13 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> Message-ID: On Thu, Dec 10, 2009 at 12:08 PM, James Lee wrote: > On 10/12/09, 11:52:40, Gary Law wrote regarding Re: > [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > >> >> It's how Sun designed it. Just install that package from the global >> >> zone and be done with it. :-) >> > >> > For the record: >> > >> > http://www.opencsw.org/bugtrack/view.php?id=3760 > >> OK, I don't think we should be using classutils then. It violates >> policy. The 'workaround' is clunky for some, and impossible if you >> don't have root on the global zone. > > I support Gary. ?I understand that classutils is clever and works > well in some situations but it's not a complete solution and therefor > we should look for something else. Can we have our own implementation of class action scripts? I know that we can't rework pkgadd, but we can have our own equivalent: a common postinstall script which reads a configuration file and processes files marked in csw-prototype. We could even make it better by allowing one file to have multiple classes. Any other ideas? From maciej at opencsw.org Thu Dec 10 13:56:32 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 12:56:32 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> Message-ID: On Thu, Dec 10, 2009 at 11:52 AM, Gary Law wrote: > HI > > 2009/12/10 Maciej (Matchek) Blizinski : >> On Wed, Dec 2, 2009 at 11:01 PM, Peter Bonivart wrote: >>> It's how Sun designed it. Just install that package from the global >>> zone and be done with it. :-) >> >> For the record: >> >> http://www.opencsw.org/bugtrack/view.php?id=3760 > > OK, I don't think we should be using classutils then. It violates > policy. The 'workaround' is clunky for some, and impossible if you > don't have root on the global zone. It's only impossible if you don't have root on the global zone and you inherit /usr from it. I would say that if you intent to install packages to a Solaris system, it should be either a global zone or a full root zone. Can you ask for conversion of your zone to full root? Maciej From skayser at opencsw.org Thu Dec 10 14:05:01 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 10 Dec 2009 14:05:01 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> Message-ID: <20091210130501.GA7667@sebastiankayser.de> * Peter Bonivart wrote: > On Thu, Dec 10, 2009 at 12:52 PM, Gary Law wrote: > > 2009/12/10 Maciej (Matchek) Blizinski : > >> On Wed, Dec 2, 2009 at 11:01 PM, Peter Bonivart wrote: > >>> It's how Sun designed it. Just install that package from the global > >>> zone and be done with it. :-) > >> > >> For the record: > >> > >> http://www.opencsw.org/bugtrack/view.php?id=3760 > > > > OK, I don't think we should be using classutils then. It violates > > policy. The 'workaround' is clunky for some, and impossible if you > > don't have root on the global zone. > > You made a choice using a shared file system you don't have write > access to in any way. Sounds like a bad choice. :-) Peter, did you experiment with the approach that we came up with during summer camp? Put dummy CAS scripts in the package which hand over to the real CAS scripts in /opt/csw/somewhere. This way we wouldn't need to have our CAS scripts beneath /usr. Does the user get prompted with "do you really want the package to do things that you probably don't care about"? Sebastian From bonivart at opencsw.org Thu Dec 10 14:27:03 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 10 Dec 2009 14:27:03 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> Message-ID: <625385e30912100527i1afbebb1o9c7e35ab5b91fb44@mail.gmail.com> On Thu, Dec 10, 2009 at 1:56 PM, Maciej (Matchek) Blizinski wrote: > On Thu, Dec 10, 2009 at 11:52 AM, Gary Law wrote: >> HI >> >> 2009/12/10 Maciej (Matchek) Blizinski : >>> On Wed, Dec 2, 2009 at 11:01 PM, Peter Bonivart wrote: >>>> It's how Sun designed it. Just install that package from the global >>>> zone and be done with it. :-) >>> >>> For the record: >>> >>> http://www.opencsw.org/bugtrack/view.php?id=3760 >> >> OK, I don't think we should be using classutils then. It violates >> policy. The 'workaround' is clunky for some, and impossible if you >> don't have root on the global zone. > > It's only impossible if you don't have root on the global zone and you > inherit /usr from it. ?I would say that if you intent to install > packages to a Solaris system, it should be either a global zone or a > full root zone. ?Can you ask for conversion of your zone to full root? Not in reply to Maciej but more in general: I have never understood this "I don't have root in the global zone"-issue. If you're only root in the sparse zone, why don't you just ask the global root to install cswclassutils? It's not like asking them to pollute the global zone with an Oracle installation, it's just a few shell scripts. In what situation could this not get done? I doubt much can be done at all at a company that can't provide that minor service. Sorry for not being more understanding but if we're dropping support for an excellent feature I'm not going to work at replacing it. -- /peter From bonivart at opencsw.org Thu Dec 10 15:06:27 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 10 Dec 2009 15:06:27 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091210130501.GA7667@sebastiankayser.de> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> Message-ID: <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> On Thu, Dec 10, 2009 at 2:05 PM, Sebastian Kayser wrote: > Peter, did you experiment with the approach that we came up with during > summer camp? Put dummy CAS scripts in the package which hand over to the > real CAS scripts in /opt/csw/somewhere. This way we wouldn't need to > have our CAS scripts beneath /usr. No, I haven't had time to yet but if that approach works it's the only sane way to go if we're not to take a giant step backwards. > Does the user get prompted with "do you really want the package to do > things that you probably don't care about"? Yes. -- /peter From phil at bolthole.com Thu Dec 10 18:11:31 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 09:11:31 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Wed, Dec 9, 2009 at 11:24 PM, Maciej (Matchek) Blizinski wrote: > > Filed bug 4074 about this issue. > Thanks. > My brain says the right thing to do is: > > 1. Get the alternatives mechanism in place > 2. Modify CSWsudo to use it > 3. Modify CSWsudo_ldap to use it, give it higher priority (if both are > installed at the same time, use sudo.ldap) > 4. Remove the stupid symlink from CSWsudo_common > 5. Release all three packages at the same time > > Does it look good? yes... except if it takes more than a week to implement, in which case, I'd say just release new sudo with the symlink in postinstall. sudo needs upgrading sooner rather than later, for security reasons, I thought. From phil at bolthole.com Thu Dec 10 18:12:54 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 09:12:54 -0800 Subject: [csw-maintainers] need new subversion maintainer? Message-ID: Hi folks, Rupert has not responded to emails in a while. he was the last person to offer to "take over" subversion, which needs a new maintainer. Seems like we need a new takeover offer, so to speak. Anyone? From phil at bolthole.com Thu Dec 10 18:25:33 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 09:25:33 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> Message-ID: On Thu, Dec 10, 2009 at 4:08 AM, James Lee wrote: > On 10/12/09, 11:52:40, Gary Law wrote regarding Re: > >> OK, I don't think we should be using classutils then. It violates >> policy. [of writing to /usr] >> The 'workaround' is clunky for some, and impossible if you >> don't have root on the global zone. > > I support Gary. ?I understand that classutils is clever and works > well in some situations but it's not a complete solution and therefor > we should look for something else. wow. I'm surprised you have that view, James. is this something you actually run into anywhere, or is this a purely abstract, "purity" level objection? For myself, I'm not "happy" with it. but unfortunately, it's the only way sun allows class actions to work. I am very behind class actions, because it is the cleanest way to migrate to IPS [whatever-the-hell-they-are-called], 4 years down the road. The other reason is because it is the only way to avoid prompting the user for trivial pre-approved stuff, while at the same time still allowing the user control for prompting about SERIOUS stuff. In other words: Prompt user for known, understood behaviour for copying conf scripts? no. Prompt user for running a completely new, one-shot complicated postinstall script? YES, if they care about checking out those things. This is important, in my opinion. There is *NO* other solution that allows for this, while still using straight SVR4 pkgadd. You MUST use class action scripts, and they MUST go in /usr. Everything else will be forced to use postinstall script, which will have the prompting problem. From phil at bolthole.com Thu Dec 10 18:25:56 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 09:25:56 -0800 Subject: [csw-maintainers] Replacing existing Solaris functionality by OpenCSW packages In-Reply-To: References: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> Message-ID: On Wed, Dec 9, 2009 at 11:41 PM, Maciej (Matchek) Blizinski wrote: > > One package can't remove another package upon installation, can it? not in pre or postinstall, far as I know, due to pkg database locking issues? not DIRECTLY anyways... there are sneaky workarounds I think. but meanwhile.. > Anyway, about handling the "install all CSW" scenario, isn't it better > to just skip the packages which conflict with already installed ones? And how are you going to define "conflict"? and how are you going to deal with the fact that for our NORMAL operations, standard operation is the exact opposite: REMOVE packages for which newer ones (of ours) conflict. it just doesnt work well. I made a suggestion, which satisfies both "how do we deal with it", and "how do we not mess up existing expected behaviour of our packages". Perhaps you'd like to review the archives and reconsider it. (I dont remember exactly what it was right now, but I do know it fulfilled the above two criteria) From maciej at opencsw.org Thu Dec 10 18:57:07 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 17:57:07 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: <1260210104-sup-2487@ntdws12.chass.utoronto.ca> References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: Moving Here's the alternatives package for you to test: http://mirror.opencsw.org/testing/alternatives-1.15.5.3,REV=2009.12.10-SunOS5.8-all-CSW.pkg.gz To address the concern that the executable name is long: it's not going to be typed by humans. It will be used by postinstall scripts (or class action scripts). It's the Debian's alternatives system, cut out from the dpkg source tarball. How do you like it? Maciej From phil at bolthole.com Thu Dec 10 18:59:46 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 09:59:46 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Dec 10, 2009 at 9:57 AM, Maciej (Matchek) Blizinski wrote: > Here's the alternatives package for you to test: > > http://mirror.opencsw.org/testing/alternatives-1.15.5.3,REV=2009.12.10-SunOS5.8-all-CSW.pkg.gz > > To address the concern that the executable name is long: it's not > going to be typed by humans. ?It will be used by postinstall scripts > (or class action scripts). > Then how will humans specify what they want? From skayser at opencsw.org Thu Dec 10 19:05:31 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 10 Dec 2009 19:05:31 +0100 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: <20091210180531.GC7667@sebastiankayser.de> * Philip Brown wrote: > On Thu, Dec 10, 2009 at 9:57 AM, Maciej (Matchek) Blizinski > wrote: > > Here's the alternatives package for you to test: > > > > http://mirror.opencsw.org/testing/alternatives-1.15.5.3,REV=2009.12.10-SunOS5.8-all-CSW.pkg.gz > > > > To address the concern that the executable name is long: it's not > > going to be typed by humans. ?It will be used by postinstall scripts > > (or class action scripts). > > Then how will humans specify what they want? What's the concern about the command name being too long when we live in an age of shell auto-completion? As a related question: we port a known utility to our platform (Solaris), why not keep the known name? That's what we do with almost all the other software. Sebastian From phil at bolthole.com Thu Dec 10 19:26:31 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 10:26:31 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: <20091210180531.GC7667@sebastiankayser.de> References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> <20091210180531.GC7667@sebastiankayser.de> Message-ID: On Thu, Dec 10, 2009 at 10:05 AM, Sebastian Kayser wrote: > >>... >> Then how will humans specify what they want? > > What's the concern about the command name being too long when we live in > an age of shell auto-completion? my shell doesnt autocomplete, nor do I want it to. >As a related question: we port a known > utility to our platform (Solaris), why not keep the known name? That's > what we do with almost all the other software. well now that you mention it, it might be nice to keep an alias for the "regular name", or vice versa. but I'd still like to see a short(er) name for primary use. From maciej at opencsw.org Thu Dec 10 19:28:36 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 18:28:36 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Dec 10, 2009 at 5:59 PM, Philip Brown wrote: > On Thu, Dec 10, 2009 at 9:57 AM, Maciej (Matchek) Blizinski > wrote: >> Here's the alternatives package for you to test: >> >> http://mirror.opencsw.org/testing/alternatives-1.15.5.3,REV=2009.12.10-SunOS5.8-all-CSW.pkg.gz >> >> To address the concern that the executable name is long: it's not >> going to be typed by humans. ?It will be used by postinstall scripts >> (or class action scripts). >> > > > Then how will humans specify what they want? User, non-maintainer humans? They will use rm and ln to make different symlinks in /etc/opt/csw/alternatives. From maciej at opencsw.org Thu Dec 10 19:40:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 18:40:13 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Thu, Dec 10, 2009 at 5:11 PM, Philip Brown wrote: > On Wed, Dec 9, 2009 at 11:24 PM, Maciej (Matchek) Blizinski > wrote: >> >> Filed bug 4074 about this issue. >> > > Thanks. > >> My brain says the right thing to do is: >> >> 1. Get the alternatives mechanism in place >> 2. Modify CSWsudo to use it >> 3. Modify CSWsudo_ldap to use it, give it higher priority (if both are >> installed at the same time, use sudo.ldap) >> 4. Remove the stupid symlink from CSWsudo_common >> 5. Release all three packages at the same time >> >> Does it look good? > > yes... except if it takes more than a week to implement, in which > case, I'd say just release new sudo with the symlink in postinstall. > sudo needs upgrading sooner rather than later, for security reasons, I thought. There is no security hole, it's even the opposite: the sudo command vanishes, and the system becomes more secure, because users can't get root. Unless they figure out sudo.minimal. There is one thing I'm curious about. If I understand it correctly, the transition from the older scheme (CSWsudo containing /opt/csw/bin/sudo binary) to the new scheme (CSWsudo containing /opt/csw/bin/sudo.minimal and CSWsudo-common containing the symlink), assuming the upgrade order (CSWsudo-common gets upgraded first), must inevitably lead to the problem I described. I find it hard to believe that nobody ran into this problem before and that there were no bug reports. Maintainers, are you sure that the issue hasn't surfaced after the introduction of the symlink? Was there any magic during the upgrade used? Or are our users still stuck to the old package? From what I see in the catalog, even our old stable contains packages with the newer scheme. From phil at bolthole.com Thu Dec 10 20:00:04 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 11:00:04 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Dec 10, 2009 at 10:28 AM, Maciej (Matchek) Blizinski wrote: > On Thu, Dec 10, 2009 at 5:59 PM, Philip Brown wrote: >> >> >> Then how will humans specify what they want? > > User, non-maintainer humans? ?They will use rm and ln to make > different symlinks in /etc/opt/csw/alternatives. > ick. that's rather user-unfriendly. If that's how debian-alternatives does it... lets go one BETTER than debian, eh? From james at opencsw.org Thu Dec 10 20:10:11 2009 From: james at opencsw.org (James Lee) Date: Thu, 10 Dec 2009 19:10:11 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> Message-ID: <20091210.19101100.2415089556@gyor.oxdrove.co.uk> On 10/12/09, 17:25:33, Philip Brown wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > On Thu, Dec 10, 2009 at 4:08 AM, James Lee wrote: > > On 10/12/09, 11:52:40, Gary Law wrote regarding Re: > > > >> OK, I don't think we should be using classutils then. It violates > >> policy. [of writing to /usr] > >> The 'workaround' is clunky for some, and impossible if you > >> don't have root on the global zone. > > > > I support Gary. ?I understand that classutils is clever and works > > well in some situations but it's not a complete solution and therefor > > we should look for something else. > wow. I'm surprised you have that view, James. > is this something you actually run into anywhere, or is this a purely > abstract, "purity" level objection? I have global root access but use zones to provide separation. I have stable production zones and test play zones. I do not want the same version packages in all zones, that includes classutils. Admittedly the classutils is passive until packages are changed so its update does not affect running stability and hence I've tolerated this one exception. There is the possibility that a later classutils won't be compatible with older installed packages when they eventually require update and so I object to the principle of requiring global installation and a common version. Sharing resources is a feature of zones so suggesting using root zones is a poor workaround. I want share the system and separate the /opt/ional software. > There is *NO* other solution that allows for this, while still using > straight SVR4 pkgadd. You MUST use class action scripts, and they MUST > go in /usr. If I had the solution I'd have made a suggestion long ago. I'm saying although I haven't complained myself I do support anyone else for whom it is an issue and I support the quest for an alternative. It might be possible to use the existing build/sed classes and provide developer tools that write the necessary code to work with those classes. I make ghostscript, groff and some others to install the correct paper size using request and the existing build class. I've no idea if the standard classes would work or if another technology is needed but as long as CSW needs to write to /usr there is room for improvement. James. From phil at bolthole.com Thu Dec 10 20:12:18 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 11:12:18 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Thu, Dec 10, 2009 at 10:40 AM, Maciej (Matchek) Blizinski wrote: > On Thu, Dec 10, 2009 at 5:11 PM, Philip Brown wrote: >> >> yes... except if it takes more than a week to implement, in which >> case, I'd say just release new sudo with the symlink in postinstall. >> sudo needs upgrading sooner rather than later, for security reasons, I thought. > > There is no security hole, it's even the opposite: ... I meant, I thought there was a version upgrade needed to sudo. huh. interestingly, there wasnt when we started... but there IS now a newer version of sudo. from 4 days ago :-} From phil at bolthole.com Thu Dec 10 20:55:49 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 11:55:49 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091210.19101100.2415089556@gyor.oxdrove.co.uk> References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> <20091210.19101100.2415089556@gyor.oxdrove.co.uk> Message-ID: On Thu, Dec 10, 2009 at 11:10 AM, James Lee wrote: > > There is the possibility that a later classutils won't be compatible with > older installed packages when they eventually require update and so I > object to the principle of requiring global installation and a common > version. Well, if we were talking about [random anonymous 3rd party vendor], I can see how this is a concern. but seeing as how WE are the vendor... I think we can put this concern to bed fairly easily ;-) A quick off-the-cuff solution: We declare that classutils implementations must be backwards compatible. If you want to do something incompatible,you must do it in a newly named class. Problem solved? > If I had the solution I'd have made a suggestion long ago. ?I'm saying > although I haven't complained myself I do support anyone else for whom > it is an issue and I support the quest for an alternative. ah. fair enough there. i wouldnt ever say "this is perfect, i'm going to ignore any other proposals for alternatives". I would say that I just want other alternatives to be *at least as good*. > It might be possible to use the existing build/sed classes and provide > developer tools that write the necessary code to work with those classes. > I make ghostscript, groff and some others to install the correct paper > size using request and the existing build class. ?I've no idea if the > standard classes would work or if another technology is needed but as > long as CSW needs to write to /usr there is room for improvement. Well, there are probably some things for which we can use existing sun provided classes. But they ARE *very* limited. From maciej at opencsw.org Fri Dec 11 08:29:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 11 Dec 2009 07:29:58 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Dec 10, 2009 at 7:00 PM, Philip Brown wrote: > On Thu, Dec 10, 2009 at 10:28 AM, Maciej (Matchek) Blizinski > wrote: >> On Thu, Dec 10, 2009 at 5:59 PM, Philip Brown wrote: >>> >>> >>> Then how will humans specify what they want? >> >> User, non-maintainer humans? ?They will use rm and ln to make >> different symlinks in /etc/opt/csw/alternatives. >> > > ick. that's rather user-unfriendly. On the contrary, this is exactly why it's user friendly. You don't have to know about update-alternatives command line to manage your alternatives. If you want to change which sudo to use, you can go /etc/opt/csw/alternatives, replace existing symlink with the one you want and be done with it. The next time you upgrade sudo or sudo_ldap, update-alternatives will notice that the symlink has been changed, and it won't touch it. It's similar to the way we currently handle configuration files. Of course, nothing prevents humans from using the update-alternatives command line. If someone wants to type less, they should be intelligent enough to use the power of alias. From glaw at opencsw.org Fri Dec 11 08:35:07 2009 From: glaw at opencsw.org (Gary Law) Date: Fri, 11 Dec 2009 07:35:07 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <625385e30912100527i1afbebb1o9c7e35ab5b91fb44@mail.gmail.com> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100527i1afbebb1o9c7e35ab5b91fb44@mail.gmail.com> Message-ID: Hi 2009/12/10 Peter Bonivart : > I have never understood this "I don't have root in the global > zone"-issue. If you're only root in the sparse zone, why don't you > just ask the global root to install cswclassutils? It's not like > asking them to pollute the global zone with an Oracle installation, > it's just a few shell scripts. > > In what situation could this not get done? I doubt much can be done at > all at a company that can't provide that minor service. If you're buying a Solaris VM service based on zones then it might not be an option (which is the position for one of my machines). Or, if it is, it might take a long time to get done. Not only that, if you are in this position CSWcswclassutils will install (and fail, with a partially installed error message) but dependent software will still install (using pkg-get or pkgutil) and then not work. At the very least CSWcswclassutils should test the writability of /usr, and bail if it can't. > Sorry for not being more understanding but if we're dropping support > for an excellent feature I'm not going to work at replacing it. I've just done a lot of work, and Maciej has done a lot more, getting one of my packages in GAR. The package now doesn't start/stop on my test rig which means it fails my tests. I was surprised that we're writing in /usr and don't remember the robust debate on this channel which I'm sure would have accompanied the proposal to start doing so. I guess I wasn't paying attention that day. Gary -- glaw at opencsw.org From glaw at opencsw.org Fri Dec 11 08:45:42 2009 From: glaw at opencsw.org (Gary Law) Date: Fri, 11 Dec 2009 07:45:42 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> <20091210.19101100.2415089556@gyor.oxdrove.co.uk> Message-ID: 2009/12/10 Philip Brown : > A quick off-the-cuff solution: > > We declare that classutils implementations must be backwards > compatible. If you want to do something incompatible,you must do it in > a newly named class. > > Problem solved? Might be if there were no-one out there shipping identically named utils installing in the same place, who might just go ahead and upgrade thiers in an incompatible way. But there is. This is a general problem obviously, not just for this package and classutils, which opencsw and blastwave persist in ignoring. As for the question of how we reimplement something which we've done, which IMHO we should not have done, with an identical feature set I don't know (I simply don't understand enough about the features of classutils to make a suggestion at this stage). I'll have a think, and maybe pick some brains on IRC at a better time.[1] Gary [1] Right now I'm in an airport departure lounge after getting up far too early this morning -- glaw at opencsw.org From glaw at opencsw.org Fri Dec 11 08:49:51 2009 From: glaw at opencsw.org (Gary Law) Date: Fri, 11 Dec 2009 07:49:51 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: 2009/12/10 Philip Brown : > ick. that's rather user-unfriendly. > If that's how debian-alternatives does it... lets go one BETTER than debian, eh? -1. I suggest copy Debian, bugs and all, first. Then think about improving it if/when we get some feedback. Personally I like the alternatives system, it's 'unixy' in all the right ways. Gary -- glaw at opencsw.org From james at opencsw.org Fri Dec 11 10:44:16 2009 From: james at opencsw.org (James Lee) Date: Fri, 11 Dec 2009 09:44:16 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> <20091210.19101100.2415089556@gyor.oxdrove.co.uk> Message-ID: <20091211.9441600.2229441902@gyor.oxdrove.co.uk> On 10/12/09, 19:55:49, Philip Brown wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > > If I had the solution I'd have made a suggestion long ago. ?I'm saying > > although I haven't complained myself I do support anyone else for whom > > it is an issue and I support the quest for an alternative. > ah. fair enough there. i wouldnt ever say "this is perfect, i'm going > to ignore any other proposals for alternatives". I would say that I > just want other alternatives to be *at least as good*. I define better as not writing to /usr. > > It might be possible to use the existing build/sed classes and provide > > developer tools that write the necessary code to work with those classes. > > I make ghostscript, groff and some others to install the correct paper > > size using request and the existing build class. ?I've no idea if the > > standard classes would work or if another technology is needed but as > > long as CSW needs to write to /usr there is room for improvement. > Well, there are probably some things for which we can use existing sun > provided classes. > But they ARE *very* limited. The build class runs the 2 scripts supplied in the package file so isn't limited. James. From phil at bolthole.com Fri Dec 11 17:51:19 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Dec 2009 08:51:19 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> <20091210.19101100.2415089556@gyor.oxdrove.co.uk> Message-ID: On Thu, Dec 10, 2009 at 11:45 PM, Gary Law wrote: > 2009/12/10 Philip Brown : >> A quick off-the-cuff solution: >> >> We declare that classutils implementations must be backwards >> compatible. If you want to do something incompatible,you must do it in >> a newly named class. >> >> Problem solved? > > Might be if there were no-one out there shipping identically named > utils installing in the same place, who might just go ahead and > upgrade thiers in an incompatible way. But there is. > no one else (who matters...) is going to be shipping any pkg class utils named "cswxxxx". our namespace is safe. From phil at bolthole.com Fri Dec 11 17:58:44 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Dec 2009 08:58:44 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Dec 10, 2009 at 11:29 PM, Maciej (Matchek) Blizinski wrote: > On Thu, Dec 10, 2009 at 7:00 PM, Philip Brown wrote: >> >> >> ick. that's rather user-unfriendly. > > On the contrary, this is exactly why it's user friendly. ?You don't > have to know about update-alternatives command line to manage your > alternatives. But you DO have to know in depth about your target program. You might not KNOW all the places you need to symlink, as a user. picture sendmail. It has MULTIPLE things that need to be replaced. sendmail itself, plus mailq, plus newaliases, (and possibly more?) The most userfriendly thing to do, is provide a nice simple one-stop interface, that allows the user to say, [i want CSWpostfix to completely replace the functionality of sendmail on my box] the ANTI-friendly thing to do, is to default the user to, [it's up to you to know and remember all the places sun sendmail has hooks into your system] > ?If someone wants to type less, they should be > intelligent enough to use the power of alias. This is a very bad attitude in my opinion. You are essentially saying "well, we COULD make things easier for the user... but we choose to make them do the work themselves". "update-alternatives" is a *20 character command*. Gary extols the virtues of doing things in a "unixy way". I would point out that having ludicrously long command names is not a "unixy way". Rather, the opposite. > Of course, nothing prevents humans from using the update-alternatives > command line. From phil at bolthole.com Fri Dec 11 18:00:47 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Dec 2009 09:00:47 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Dec 10, 2009 at 11:49 PM, Gary Law wrote: > 2009/12/10 Philip Brown : >> ick. that's rather user-unfriendly. >> If that's how debian-alternatives does it... lets go one BETTER than debian, eh? > > -1. I suggest copy Debian, bugs and all, first. Then think about > improving it if/when we get some feedback. Personally I like the > alternatives system, it's 'unixy' in all the right ways. Errr.. we're not implementing "WINE" here. we have no reward for copying the BUGS :-} I like the concept of the alternatives system. I'm suggesting we implement debian normal behavior, and then *augment* it, to be better. Such as, including a short-command invocation. From maciej at opencsw.org Sat Dec 12 02:27:14 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 12 Dec 2009 01:27:14 +0000 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file Message-ID: Suppose I have a file CSWfoo.postinstall, which has some variables which need to be substituted before the file can be shipped. Something along the lines of: mycommand=@bindir@/foo Is it possible to preprocess a postinstall file like that? At which stage should it be done? From phil at bolthole.com Sat Dec 12 02:58:43 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Dec 2009 17:58:43 -0800 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: Message-ID: On Fri, Dec 11, 2009 at 5:27 PM, Maciej (Matchek) Blizinski wrote: > Suppose I have a file CSWfoo.postinstall, which has some variables > which need to be substituted before the file can be shipped. > Something along the lines of: > > mycommand=@bindir@/foo > > Is it possible to preprocess a postinstall file like that? ?At which > stage should it be done? its impossible to answer that without you specifying where the data to be substituted, comes *from*. From bwalton at opencsw.org Sat Dec 12 03:53:48 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 11 Dec 2009 21:53:48 -0500 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: Message-ID: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Dec 11 20:27:14 -0500 2009: > Suppose I have a file CSWfoo.postinstall, which has some variables > which need to be substituted before the file can be shipped. > Something along the lines of: > > mycommand=@bindir@/foo Use the dynamic adm script capability in GAR. See docbook-style-xsl: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/docbook-style-xsl/trunk/Makefile http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/docbook-style-xsl/trunk/files/CSWdocbookxsl.postinstall Just be careful to $$ when you need to use a shell variable as the script is subject to regular Makefile expansion rules. Also, the final product will be much less readable than a normal script. Is this what you're after? 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 Dec 12 08:05:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 12 Dec 2009 08:05:26 +0100 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: Message-ID: <2FD57AEC-D3E7-4533-ACE7-3B0A351B6D13@opencsw.org> Hi Maciej, Am 12.12.2009 um 02:27 schrieb Maciej (Matchek) Blizinski: > Suppose I have a file CSWfoo.postinstall, which has some variables > which need to be substituted before the file can be shipped. > Something along the lines of: > > mycommand=@bindir@/foo > > Is it possible to preprocess a postinstall file like that? At which > stage should it be done? The natural place for this is in post-install-modulated. However, you may also do it during post-merge or in a custom-merge rule doing substitute-copy in one step. Best regards -- Dago From maciej at opencsw.org Sun Dec 13 00:09:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 12 Dec 2009 23:09:47 +0000 Subject: [csw-maintainers] Font packages In-Reply-To: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> References: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> Message-ID: On Wed, Apr 1, 2009 at 3:58 PM, Alexander Maier wrote: > Am 31.03.2009 um 12:20 schrieb Maciej (Matchek) Blizinski: > >> How do we go about adding font packages? Let's suppose I have a font >> what I want to package. Let it be Terminus[1], for the sake of the >> exercise. Can it be somehow integrated with Sun-provided X server in >> Solaris 10? Are there established practices about including fonts in >> OpenCSW? >> > > > I think one have to distinguish between fonts for "classic X apps" with > local/remote xfs and fonts for apps using libfreetype/fontconfig (based on > GTK or Qt). > > In the latter case I would suggest to put these fonts into > /opt/csw/share/fonts (e.g. Microsoft TrueType fonts or Red Hat Liberation > fonts). > > Terminus seems to be a classic X11/Motif font, so it would probably be > better off somewhere below /opt/csw/X11 (as Phil has suggested). Speaking of TTF fonts, is it possible to achieve the effect of making the font package "just work"? I mean that the fonts would just appear in the font lists after installing a font package. It works that way if one puts fonts into /usr/openwin/lib/X11/fonts/TrueType but the OpenCSW policy prohibits putting anything there. What is the least invasive way of going about it? Fiddling with configuration in /etc? (this would require X restart for the change to take effect) Releasing an update to fontconfig and adding a new fonts directory under /opt/csw? Maciej From rupert at opencsw.org Sun Dec 13 00:43:48 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 13 Dec 2009 00:43:48 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> Message-ID: <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> will do tomorrow, when i get back to the computer with the login keys on it :) sorry for beeing slow. my main problem is that in my day job i am sitting behind a firewall which does not allow me access opencsw emails, and also not looging in to build/submit so i have a slow reaction time. therefor i would not mind if somebody submits the packages without asking and waiting for a response, which might come up to 2 weeks later. rupert On Mon, Nov 30, 2009 at 18:47, Philip Brown wrote: > On Sat, Nov 28, 2009 at 5:01 AM, Dagobert Michelsen > wrote: > > > > I am already working on a version-modulated OpenLDAP package including > the > > previous shared version. In the meantime I removed the broken OpenLDAP > > package. > > > > oh good. in that case I guess the subversion in testing can be > released? Please officially submit it Rupert? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Sun Dec 13 20:43:47 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 13 Dec 2009 20:43:47 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> Message-ID: Hi Rupert, Am 13.12.2009 um 00:43 schrieb rupert THURNER: > will do tomorrow, when i get back to the computer with the login keys on it :) sorry for beeing slow. > > my main problem is that in my day job i am sitting behind a firewall which does not allow me access opencsw emails, and also not looging in to build/submit so i have a slow reaction time. > > therefor i would not mind if somebody submits the packages without asking and waiting for a response, which might come up to 2 weeks later. No, no, we are grateful that you do this at all given your restrictions. Just let the list know when your timeframe gets even fuller :-) Please go ahead. Best regards -- Dago From rupert at opencsw.org Sun Dec 13 21:54:33 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 13 Dec 2009 21:54:33 +0100 Subject: [csw-maintainers] Fwd: [trac 0004077]: undeclared dependency on python_devel In-Reply-To: <5227c158cd8ba1432ab4a77f045f8334@www.opencsw.org> References: <5227c158cd8ba1432ab4a77f045f8334@www.opencsw.org> Message-ID: <6af4270912131254i6ab989e2sb8bc29633861c532@mail.gmail.com> hi, can the python specialists amongst you drop a line on this bug report? how is python devel, setuptools and distutils interconnected, and which package contains what? rupert. ---------- Forwarded message ---------- From: Mantis Bug Tracker Date: Fri, Dec 11, 2009 at 09:22 Subject: [trac 0004077]: undeclared dependency on python_devel To: rupert at opencsw.org The following issue has been SUBMITTED. ====================================================================== http://www.opencsw.org/bugtrack/view.php?id=4077 ====================================================================== Reported By: pfelecan Assigned To: ====================================================================== Project: trac Issue ID: 4077 Category: packaging Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2009-12-11 09:22 CET Last Modified: 2009-12-11 09:22 CET ====================================================================== Summary: undeclared dependency on python_devel Description: After installing trac, trying to get help: trac-admin help we get: Traceback (most recent call last): File "/opt/csw/bin/trac-admin", line 5, in from pkg_resources import load_entry_point File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 657, in class Environment(object): File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 660, in Environment def __init__(self, search_path=None, platform=get_supported_platform(), python=PY_MAJOR): File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 55, in get_supported_platform plat = get_build_platform(); m = macosVersionString.match(plat) File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 186, in get_build_platform from distutils.util import get_platform ImportError: No module named distutils.util After installing python_devel, everything seems alright. ====================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Dec 13 22:06:45 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 13 Dec 2009 21:06:45 +0000 Subject: [csw-maintainers] Fwd: [trac 0004077]: undeclared dependency on python_devel In-Reply-To: <6af4270912131254i6ab989e2sb8bc29633861c532@mail.gmail.com> References: <5227c158cd8ba1432ab4a77f045f8334@www.opencsw.org> <6af4270912131254i6ab989e2sb8bc29633861c532@mail.gmail.com> Message-ID: On Sun, Dec 13, 2009 at 8:54 PM, rupert THURNER wrote: > hi, > > can the python specialists amongst you drop a line on this bug report? how > is python devel, setuptools and distutils interconnected, and which package > contains what? The problem is that distutils (the distutils module which you import by "import distutils") isn't included in CSWpython, but in CSWpython-devel instead. I believe that distutils should be included in CSWpython. I've already filed a bug report about this: http://www.opencsw.org/mantis/view.php?id=3967 However, Mike Watters is on sabbatical, so we can't expect this to change anytime soon, unless someone else takes over the package. Maciej From phil at bolthole.com Mon Dec 14 17:12:43 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Dec 2009 08:12:43 -0800 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> Message-ID: On Sat, Dec 12, 2009 at 3:43 PM, rupert THURNER wrote: > > my main problem is that in my day job i am sitting behind a firewall which > does not allow me access opencsw emails, and also not looging in to > build/submit so i have a slow reaction time. > What does the firewall allow? From phil at bolthole.com Mon Dec 14 17:21:27 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Dec 2009 08:21:27 -0800 Subject: [csw-maintainers] Font packages In-Reply-To: References: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> Message-ID: On Sat, Dec 12, 2009 at 3:09 PM, Maciej (Matchek) Blizinski wrote: > Speaking of TTF fonts, is it possible to achieve the effect of making > the font package "just work"? ?I mean that the fonts would just appear > in the font lists after installing a font package. > > It works that way if one puts fonts into > /usr/openwin/lib/X11/fonts/TrueType but the OpenCSW policy prohibits > putting anything there. ?What is the least invasive way of going about > it? ?Fiddling with configuration in /etc? (this would require X > restart for the change to take effect) Releasing an update to > fontconfig and adding a new fonts directory under /opt/csw? > Huh. I thougth we already had an X11 fonts dir. but it would seem we do not. Soooo... yeah, we should have an official CSW fonts dir for X. Presumably /opt/csw/X11/fonts ? But then for fonts that are not strictly X only, we have the question of ..."well, what about non-X things, that still want access to true type fonts?" We have more than one package that provides some hooks for truetype fonts. tetex, for one. openoffice, for another. From dam at opencsw.org Mon Dec 14 17:31:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 14 Dec 2009 17:31:43 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> Message-ID: <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> Hi, Am 14.12.2009 um 17:12 schrieb Philip Brown: > On Sat, Dec 12, 2009 at 3:43 PM, rupert THURNER > wrote: >> >> my main problem is that in my day job i am sitting behind a >> firewall which >> does not allow me access opencsw emails, and also not looging in to >> build/submit so i have a slow reaction time. >> > > What does the firewall allow? I could setup wither SSH on 443 to allow tunneling with proxy connect or Sun SGD for a real webconnect if that would help you. Best regards -- Dago From phil at bolthole.com Mon Dec 14 18:21:35 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Dec 2009 09:21:35 -0800 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> Message-ID: On Mon, Dec 14, 2009 at 8:31 AM, Dagobert Michelsen wrote: > > > I could setup wither SSH on 443 to allow tunneling with > proxy connect or Sun SGD for a real webconnect if that would > help you. > For those not familiar with the acronym, that's "Sun(or "secure"?) Global Desktop". sorta like VNC over https kinda. From rupert at opencsw.org Mon Dec 14 19:01:29 2009 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 14 Dec 2009 19:01:29 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: References: <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> Message-ID: <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> On Mon, Dec 14, 2009 at 18:21, Philip Brown wrote: > On Mon, Dec 14, 2009 at 8:31 AM, Dagobert Michelsen > wrote: > > > > > > I could setup wither SSH on 443 to allow tunneling with > > proxy connect or Sun SGD for a real webconnect if that would > > help you. > > > > For those not familiar with the acronym, that's "Sun(or "secure"?) > Global Desktop". > > sorta like VNC over https > > oh, then this would definitely help. http(s) is only blocked to public mailers. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon Dec 14 21:45:57 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 14 Dec 2009 21:45:57 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> References: <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> Message-ID: <2A4937DB-0B66-4E92-BA39-E972CB88FC3A@opencsw.org> Hi, Am 14.12.2009 um 19:01 schrieb rupert THURNER: > On Mon, Dec 14, 2009 at 18:21, Philip Brown wrote: > On Mon, Dec 14, 2009 at 8:31 AM, Dagobert Michelsen > wrote: > > > > > > I could setup wither SSH on 443 to allow tunneling with > > proxy connect or Sun SGD for a real webconnect if that would > > help you. > > > > For those not familiar with the acronym, that's "Sun(or "secure"?) > Global Desktop". > > sorta like VNC over https > > oh, then this would definitely help. http(s) is only blocked to > public mailers. I'll see what I can do. BTW, this also means real passwords on 'login' in addition to ssh keys. Best regards -- Dago From skayser at opencsw.org Tue Dec 15 01:02:19 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 15 Dec 2009 01:02:19 +0100 Subject: [csw-maintainers] OpenCSW Winter Camp - 23/24 Jan 2010. Who is coming? In-Reply-To: <20091203114056.GA26420@sebastiankayser.de> References: <20091203114056.GA26420@sebastiankayser.de> Message-ID: <4B26D20B.4020506@opencsw.org> Sebastian Kayser wrote on 03.12.2009 12:40: > the venue and dates are fixed. Winter Camp will get us together in a > cosy seminar hotel near the Bavarian mountains on 23.01./24.01. next > year. > > http://wiki.opencsw.org/wintercamp-2009 > > I have updated the wiki page with details. The hotel doesn't have a > online booking system, so those of you who can make their way please > send me an email (by 17.12.2009) so that I can let them know with > how many people we are attending and take care of the room bookings. > > Except for the room rate (approx 60EUR / night for a single) everything > will be covered by the company I work for, so you just need to get > there. :) > > Any questions, just let me know. Hope to see you there. Ping, anyone else? I would like to confirm the booking this Thursday and so far the lists consists of the following people - Dagobert Michelsen - Maciej Blizinski - Trygve Laugstol - Benny von Mossner - Alexander Maier - me William, Dominique? There is some good beer to have in Bavaria ;) Sebastian From phil at bolthole.com Tue Dec 15 01:05:55 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Dec 2009 16:05:55 -0800 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> References: <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> Message-ID: On Mon, Dec 14, 2009 at 10:01 AM, rupert THURNER wrote: > > > oh, then this would definitely help. http(s) is only blocked to public > mailers. > Do you have ssh access though? From maciej at opencsw.org Tue Dec 15 10:03:26 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Dec 2009 09:03:26 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: On Thu, Dec 10, 2009 at 7:12 PM, Philip Brown wrote: > On Thu, Dec 10, 2009 at 10:40 AM, Maciej (Matchek) Blizinski > wrote: >> On Thu, Dec 10, 2009 at 5:11 PM, Philip Brown wrote: >>> >>> yes... except if it takes more than a week to implement, in which >>> case, I'd say just release new sudo with the symlink in postinstall. >>> sudo needs upgrading sooner rather than later, for security reasons, I thought. >> >> There is no security hole, it's even the opposite: ... > > I meant, I thought there was a version upgrade needed to sudo. > > huh. interestingly, there wasnt when we started... but there IS now a > newer version of sudo. > > from 4 days ago :-} Postinstall also needs to be implemented and tested. I think that if it's a security update it can go without any other changes: preserve the existing package structure, upgrade from p1 to p2. We can quibble about symlinks/alternatives later. Upgraded sudo packages are in testing/. Version bump is the only change. I haven't changed any file locations, or permissions, or anything else. Version bump, period. I haven't tested these packages, since I'm using my own sudo packages at the moment. Would you please test the packages if they work for you? Maciej From maciej at opencsw.org Tue Dec 15 10:46:34 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Dec 2009 09:46:34 +0000 Subject: [csw-maintainers] GPG, agent, pinentry and keychain Message-ID: I'd like to tell you about the packaging work I've done with relation to cryptographic key management. There are 3 main packages that are related to it: - gnupg_agent - pinentry - keychain The idea is to hold an unlocked key in the memory, using gpg-agent. When you need to use your private key, gpg talks to gpg-agent, which provides it with an unlocked key. In this way, you can browse e-mail encrypted to you without typing in your password each time you want to open an encrypted e-mail. Pinentry is a small utility which allows entering passwords to gpg-agent. I've compiled two backends, gtk2 and curses. The way to use the agent-pinentry-keychain combo: - install the three packages - put the following lines in your shell configuration (e.g. ~/.bash_profile) keychain 1234ABCD . ~/.keychain/$HOSTNAME-sh-gpg ...where 1234ABCD is your gpg key's shortened fingerprint. If you also want to do the same thing (unlock a key) with ssh keys, you can do: keychain id_dsa id_rsa 1234ABCD . ~/.keychain/$HOSTNAME-sh . ~/.keychain/$HOSTNAME-sh-gpg Use id_dsa and/or id_rsa depending on which keys you have. This is a more secure way to provide paswordless ssh logins, compared to unprotected private ssh keys. After putting the configuration into your shell run control file / config file, you'll be asked to unlock your keys during login. Your unlocked key will be preserved between shell sessions and will expire with time. The gnupg_agent can be used with both gpg 1.x and 2.x. It's available as part of gpg 2.x source distribution, so I've packaged it separately. gnupg_agent is in testing/. Maciej From james at opencsw.org Tue Dec 15 11:28:05 2009 From: james at opencsw.org (James Lee) Date: Tue, 15 Dec 2009 10:28:05 GMT Subject: [csw-maintainers] Font packages In-Reply-To: References: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> Message-ID: <20091215.10280500.1365323061@gyor.oxdrove.co.uk> On 14/12/09, 16:21:27, Philip Brown wrote regarding Re: [csw-maintainers] Font packages: > I thougth we already had an X11 fonts dir. but it would seem we do not. > Soooo... yeah, we should have an official CSW fonts dir for X. > Presumably /opt/csw/X11/fonts ? We had decided on: /opt/csw/share/fonts/${FORMAT}/ > But then for fonts that are not strictly X only, we have the question > of ..."well, what about non-X things, that still want access to true > type fonts?" Correct, fonts are used by X, they are not X. > We have more than one package that provides some hooks for truetype > fonts. > tetex, for one. > openoffice, for another. There's no Bitstream Vera in OOo at the moment. There are many fonts available (free for download) but Solaris comes with more and better fonts as standard than competitive systems so to me CSW fonts aren't important. I don't need the Liberation Fonts because I don't need liberating, neither do I need yet another clone of Helvetica or Times Roman. Ideally fonts should be in a common /opt/csw/share/fonts/ directory and the default font paths set in the apps. The problem is programs that index the installed fonts so adding fonts to the directory needs a way of notifying the apps, eg, Gostscript's Fontmap.GS. James. From phil at bolthole.com Tue Dec 15 17:45:21 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Dec 2009 08:45:21 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: On Tue, Dec 15, 2009 at 1:03 AM, Maciej (Matchek) Blizinski wrote: > > Upgraded sudo packages are in testing/. ?Version bump is the only > change. ?I haven't changed any file locations, or permissions, or > anything else. ?Version bump, period. > there is at least ONE "known bug", that you havent fixed: perms on sudo_ldap. please fix that. From rupert at opencsw.org Tue Dec 15 17:51:50 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 15 Dec 2009 17:51:50 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: References: <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> Message-ID: <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> from work? no, nothing but http/s. but i will ask them if i get an exception for ssh to opencsw. rupert. On Tue, Dec 15, 2009 at 01:05, Philip Brown wrote: > On Mon, Dec 14, 2009 at 10:01 AM, rupert THURNER > wrote: > > > > > > oh, then this would definitely help. http(s) is only blocked to public > > mailers. > > > > Do you have ssh access though? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Tue Dec 15 17:57:34 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 15 Dec 2009 17:57:34 +0100 Subject: [csw-maintainers] make platforms, PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" Message-ID: <6af4270912150857pbb3fdd8ic1b7daaee7977b0d@mail.gmail.com> hi, what would be the best way to use the multicore architecture and "make platforms" at the same time? usually i do PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" gmake clean package now i tried with gmake platforms which works great, but it does not parallelize on the target. or it maybe does but not the way i call it. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Tue Dec 15 17:59:24 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 15 Dec 2009 17:59:24 +0100 Subject: [csw-maintainers] mod_wsgi-3.1 in testing - this should support python-2.6 and python-3.1 Message-ID: <6af4270912150859x3ea92465qd722db5342ef3bf6@mail.gmail.com> hi, mod_wsgi-3.1 is now in testing - this should support python-2.6 and python-3.1. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Tue Dec 15 18:10:10 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 15 Dec 2009 18:10:10 +0100 Subject: [csw-maintainers] trac-0.11.6 upgrade, CSWgenshi not found? Message-ID: <6af4270912150910l179db3b7r4e93f812513703d3@mail.gmail.com> hi, i tried to upgrade the trac package. building gives system CSWcommon common - common files and dirs for CSW packages application CSWcswclassutils cswclassutils - CSW class action utilities ERROR: information for "CSWgenshi" was not found ERROR: Invalid package CSWgenshi specified. Check of /tmp/trac-0.11.6,REV=2009.12.15-SunOS5.8-sparc-CSW.pkg.gz fails gmake: *** [pkgcheck-CSWtrac] Error 2 where this could come from? i checked it in as well, so it should be easier to reproduce. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Tue Dec 15 18:14:11 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Dec 2009 09:14:11 -0800 Subject: [csw-maintainers] Font packages In-Reply-To: <20091215.10280500.1365323061@gyor.oxdrove.co.uk> References: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> <20091215.10280500.1365323061@gyor.oxdrove.co.uk> Message-ID: On Tue, Dec 15, 2009 at 2:28 AM, James Lee wrote: > > Ideally fonts should be in a common /opt/csw/share/fonts/ directory > and the default font paths set in the apps. ?The problem is programs > that index the installed fonts so adding fonts to the directory needs > a way of notifying the apps, eg, Gostscript's Fontmap.GS. > please propose something? From bwalton at opencsw.org Tue Dec 15 18:24:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 15 Dec 2009 12:24:12 -0500 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> References: <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> Message-ID: <1260896801-sup-2625@ntdws12.chass.utoronto.ca> Excerpts from rupert THURNER's message of Tue Dec 15 11:51:50 -0500 2009: Hi Rupert, > from work? no, nothing but http/s. but i will ask them if i get an exception > for ssh to opencsw. If you don't mind me asking, where do you work? Your firewall seems extremely restrictive. 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 Dec 15 18:58:20 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Dec 2009 17:58:20 +0000 Subject: [csw-maintainers] make platforms, PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" In-Reply-To: <6af4270912150857pbb3fdd8ic1b7daaee7977b0d@mail.gmail.com> References: <6af4270912150857pbb3fdd8ic1b7daaee7977b0d@mail.gmail.com> Message-ID: On Tue, Dec 15, 2009 at 4:57 PM, rupert THURNER wrote: > hi, > > what would be the best way to use the multicore architecture and "make > platforms" at the same time? > > usually i do > > PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" > gmake clean package > > now i tried with > > gmake platforms > > which works great, but it does not parallelize on the target. or it maybe > does but not the way i call it. I've put PARALLELMFLAGS into my ~/.garrc. From maciej at opencsw.org Tue Dec 15 19:00:23 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Dec 2009 18:00:23 +0000 Subject: [csw-maintainers] trac-0.11.6 upgrade, CSWgenshi not found? In-Reply-To: <6af4270912150910l179db3b7r4e93f812513703d3@mail.gmail.com> References: <6af4270912150910l179db3b7r4e93f812513703d3@mail.gmail.com> Message-ID: On Tue, Dec 15, 2009 at 5:10 PM, rupert THURNER wrote: > where this could come from? i checked it in as well, so it should be easier > to reproduce. Ask buildfarm@ to install the CSWgenshi package for you. (assuming it's been released) From maciej at opencsw.org Tue Dec 15 19:49:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Dec 2009 18:49:47 +0000 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> References: <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> Message-ID: On Tue, Dec 15, 2009 at 4:51 PM, rupert THURNER wrote: > from work? no, nothing but http/s. but i will ask them if i get an exception > for ssh to opencsw. Yes, it's generally better to get the permission rather than pierce the firewall, which might violate company's security policy. Not that the security policies always make sense. From maciej at opencsw.org Tue Dec 15 21:57:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Dec 2009 20:57:01 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: On Tue, Dec 15, 2009 at 4:45 PM, Philip Brown wrote: > On Tue, Dec 15, 2009 at 1:03 AM, Maciej (Matchek) Blizinski > wrote: >> >> Upgraded sudo packages are in testing/. ?Version bump is the only >> change. ?I haven't changed any file locations, or permissions, or >> anything else. ?Version bump, period. >> > > there is at least ONE "known bug", that you havent fixed: perms on sudo_ldap. > please fix that. I'll pass for now. I'm offering only the version bump. From skayser at opencsw.org Tue Dec 15 22:03:32 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 15 Dec 2009 22:03:32 +0100 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: <4B27F9A4.8060100@opencsw.org> Hi Maciej, Maciej (Matchek) Blizinski wrote on 15.12.2009 10:03: > On Thu, Dec 10, 2009 at 7:12 PM, Philip Brown wrote: >> On Thu, Dec 10, 2009 at 10:40 AM, Maciej (Matchek) Blizinski >> wrote: >>> On Thu, Dec 10, 2009 at 5:11 PM, Philip Brown wrote: >>>> yes... except if it takes more than a week to implement, in which >>>> case, I'd say just release new sudo with the symlink in postinstall. >>>> sudo needs upgrading sooner rather than later, for security reasons, I thought. >>> There is no security hole, it's even the opposite: ... >> I meant, I thought there was a version upgrade needed to sudo. >> >> huh. interestingly, there wasnt when we started... but there IS now a >> newer version of sudo. >> >> from 4 days ago :-} > > Postinstall also needs to be implemented and tested. I think that if > it's a security update it can go without any other changes: preserve > the existing package structure, upgrade from p1 to p2. We can quibble > about symlinks/alternatives later. > > Upgraded sudo packages are in testing/. Version bump is the only > change. I haven't changed any file locations, or permissions, or > anything else. Version bump, period. > > I haven't tested these packages, since I'm using my own sudo packages > at the moment. would it make sense to add what you are currently maintaing for yourself to our sudo packages (and then adopt the CSW sudo packages) or are your changes too custom/environment-specific? Sebastian From skayser at opencsw.org Tue Dec 15 22:07:47 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 15 Dec 2009 22:07:47 +0100 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: <4B27FAA3.9030903@opencsw.org> Maciej (Matchek) Blizinski wrote on 10.12.2009 19:40: > On Thu, Dec 10, 2009 at 5:11 PM, Philip Brown wrote: >> On Wed, Dec 9, 2009 at 11:24 PM, Maciej (Matchek) Blizinski >> wrote: >>> Filed bug 4074 about this issue. >>> >> Thanks. >> >>> My brain says the right thing to do is: >>> >>> 1. Get the alternatives mechanism in place >>> 2. Modify CSWsudo to use it >>> 3. Modify CSWsudo_ldap to use it, give it higher priority (if both are >>> installed at the same time, use sudo.ldap) >>> 4. Remove the stupid symlink from CSWsudo_common >>> 5. Release all three packages at the same time >>> >>> Does it look good? >> yes... except if it takes more than a week to implement, in which >> case, I'd say just release new sudo with the symlink in postinstall. >> sudo needs upgrading sooner rather than later, for security reasons, I thought. > > There is no security hole, it's even the opposite: the sudo command > vanishes, and the system becomes more secure, because users can't get > root. Unless they figure out sudo.minimal. > > There is one thing I'm curious about. If I understand it correctly, > the transition from the older scheme (CSWsudo containing > /opt/csw/bin/sudo binary) to the new scheme (CSWsudo containing > /opt/csw/bin/sudo.minimal and CSWsudo-common containing the symlink), > assuming the upgrade order (CSWsudo-common gets upgraded first), must > inevitably lead to the problem I described. I find it hard to believe > that nobody ran into this problem before and that there were no bug > reports. Maintainers, are you sure that the issue hasn't surfaced > after the introduction of the symlink? Just cross-checked with two of our systems which were upgraded recently. Both have up to date sudo packages now, but no /opt/csw/bin/sudo any more. So yes, the problem has surfaced, but as we don't use sudo in that environment it hasn't been noticed so far. As a side note: I guess with pkgutil 1.9 which removes all to-be-upgraded packages before installing the newer versions, one wouldn't see this issue. Right? Sebastian From phil at bolthole.com Tue Dec 15 22:12:35 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Dec 2009 13:12:35 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: On Tue, Dec 15, 2009 at 12:57 PM, Maciej (Matchek) Blizinski wrote: > On Tue, Dec 15, 2009 at 4:45 PM, Philip Brown wrote: >> there is at least ONE "known bug", that you havent fixed: perms on sudo_ldap. >> please fix that. > > I'll pass for now. ?I'm offering only the version bump. It's a trivial change. one line in the prototype file. I wont accept the packages until you fix it. From bwalton at opencsw.org Tue Dec 15 22:27:27 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 15 Dec 2009 16:27:27 -0500 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: <1260912178-sup-4991@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Dec 15 16:12:35 -0500 2009: > It's a trivial change. one line in the prototype file. I wont accept > the packages until you fix it. As it stands now, these are two separate packages. They're built from the same source, but from different build descriptions. They're tracked separately in our version control. This means that the package Maciej is _volunteering_ his time to correct is completely independent of the sudo_ldap package[1]. Why not accept the work that Maciej is willing to do and work towards getting the sudo_ldap package updated as well[2] if it's that important. It seems to me that nobody is really rushing to work on sudo_ldap, so maybe nobody is actually using it? Thanks -Ben [1] This doesn't have to be the way it is, but that's how our history has evolved it. [2] The two should likely be merged in GAR and built with modulations. We could then do away with the sudo_ldap package completely, while still providing a mechanism to toggle between the 'backends' to sudo. -- 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 Tue Dec 15 23:48:48 2009 From: glaw at opencsw.org (Gary Law) Date: Tue, 15 Dec 2009 22:48:48 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: <1260912178-sup-4991@ntdws12.chass.utoronto.ca> References: <1260912178-sup-4991@ntdws12.chass.utoronto.ca> Message-ID: 2009/12/15 Ben Walton : > > Why not accept the work that Maciej is willing to do and work towards > getting the sudo_ldap package updated as well[2] if it's that important. +1 -- glaw at opencsw.org From glaw at opencsw.org Tue Dec 15 23:57:27 2009 From: glaw at opencsw.org (Gary Law) Date: Tue, 15 Dec 2009 22:57:27 +0000 Subject: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr) Message-ID: Hi 2009/12/11 Philip Brown : > On Thu, Dec 10, 2009 at 11:45 PM, Gary Law wrote: >> 2009/12/10 Philip Brown : >>> A quick off-the-cuff solution: >>> >>> We declare that classutils implementations must be backwards >>> compatible. If you want to do something incompatible,you must do it in >>> a newly named class. >>> >>> Problem solved? >> >> Might be if there were no-one out there shipping identically named >> utils installing in the same place, who might just go ahead and >> upgrade thiers in an incompatible way. But there is. >> > > no one else (who matters...) is going to be shipping any pkg class > utils named "cswxxxx". > our namespace is safe. I'm sorry, there is someone else who really does matter shipping identically named software, Blastwave. They have a larger installed base, more hits on google (*much* more in fact, and more recent new pages that refer to them too), active forums and IRC channel that suggest plenty of users. What we have is, IMHO, better software. However, we give the software the same pkg name as them, and install in the same place, which given our generally commitment to quality, is madness. I've said it before and I'm going to say it again: we need to shift name space and distinguish this project from Blastwave. We completely lack credibility otherwise, and have to worry -- as we are now -- about collisions. In this particular case, of course, this is a real problem. I've got to go to my provider of zones and say ' install this package ' and hope none of their other customers ever want to use Blastwave. If I was a commercial provider of zones, and had an understanding of these issues, I'd refuse to install our package (and the Blastwave one of the same name) just to avoid future support headaches. -- glaw at opencsw.org From skayser at opencsw.org Wed Dec 16 00:00:29 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 16 Dec 2009 00:00:29 +0100 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: <4B28150D.4040506@opencsw.org> Philip Brown wrote on 15.12.2009 22:12: > On Tue, Dec 15, 2009 at 12:57 PM, Maciej (Matchek) Blizinski > wrote: >> On Tue, Dec 15, 2009 at 4:45 PM, Philip Brown wrote: >>> there is at least ONE "known bug", that you havent fixed: perms on sudo_ldap. >>> please fix that. >> I'll pass for now. I'm offering only the version bump. > > It's a trivial change. one line in the prototype file. I wont accept > the packages until you fix it. Disclaimer: no offense intended. It's not about "the one prototype line". You once pointed out the importance of volunteers. At the same time we are having discussions over and over again, many times about subtleties, many times leading nowhere, where i can't help but to feel a sort of "clever" argumentation (for the sake of the argument) and a "my way or highway" attitude on your side. Often this ends up with disgruntled parties, just like here. Might well be that this is all in a quest for perfection, but we are all volunteers (including you) and I really think it would help the project, if someone at a central position like yours would take a step back sometimes and try to better understand/foster what people are trying to contribute, instead of hitting them with the "nah, we/you should do it better, completely different or simply the way I think" autocracy hammer. In particular, when they are the ones doing the work. There are always multiple sides of a story. This is how I perceive things within my INBOX and it simply doesn't feel right to see people who are passionately contributing to OpenCSW (Maciej in this case, others in other cases, maybe even you sometimes, or anyone else for that matter) to go home being frustrated over OpenCSW internals. Sebastian From rupert at opencsw.org Wed Dec 16 08:45:36 2009 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 16 Dec 2009 08:45:36 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: <1260896801-sup-2625@ntdws12.chass.utoronto.ca> References: <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> <1260896801-sup-2625@ntdws12.chass.utoronto.ca> Message-ID: <6af4270912152345o14005c2ds642cfcebad108997@mail.gmail.com> On Tue, Dec 15, 2009 at 18:24, Ben Walton wrote: > Excerpts from rupert THURNER's message of Tue Dec 15 11:51:50 -0500 2009: > > Hi Rupert, > > > from work? no, nothing but http/s. but i will ask them if i get an > exception > > for ssh to opencsw. > > If you don't mind me asking, where do you work? Your firewall seems > extremely restrictive. > > credit suisse. the firewall policies allow certain things, and forbid others, besides the technical restrictions in place. either there is a technically clean possibility in line with the rules (like Sun SGD), or i have to go through the paper process for getting a permission for "ssh login.opencsw". but i do not want to break their rules even if technically possible (e.g. pierce the firewall by tunneling ssh through 443). if i do not like the rules any more it is time to look for another job i guess :) rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Wed Dec 16 09:24:17 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 16 Dec 2009 08:24:17 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: <4B27F9A4.8060100@opencsw.org> References: <4B27F9A4.8060100@opencsw.org> Message-ID: On Tue, Dec 15, 2009 at 9:03 PM, Sebastian Kayser wrote: > Hi Maciej, > > Maciej (Matchek) Blizinski wrote on 15.12.2009 10:03: >> I haven't tested these packages, since I'm using my own sudo packages >> at the moment. > > would it make sense to add what you are currently maintaing for yourself > to our sudo packages (and then adopt the CSW sudo packages) or are your > changes too custom/environment-specific? It would make sense to add it to our sudo packages. The difference between the two is that my packages move the /opt/csw/bin/sudo -> sudo.minimal symlink from CSWsudo-common to CSWsudo. This fixes the sudo upgrade problem which has just hit you. Phil did not accept this change because "somebody might have also installed CSWsudoldap and manually change the symlink to /opt/csw/bin/sudo -> sudo.ldap and this upgrade would revert their local change". I'm using the version of sudo from trunk, the one in testing/ is from branches/old-symlink-scheme. The main diff between the two is that the one in trunk has the following line: PKGFILES_CSWsudo += $(bindir)/sudo Maciej [1] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/sudo/trunk/Makefile [2] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/sudo/branches/old-symlink-scheme/Makefile From maciej at opencsw.org Wed Dec 16 09:27:49 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 16 Dec 2009 08:27:49 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: <4B27FAA3.9030903@opencsw.org> References: <4B27FAA3.9030903@opencsw.org> Message-ID: On Tue, Dec 15, 2009 at 9:07 PM, Sebastian Kayser wrote: > Maciej (Matchek) Blizinski wrote on 10.12.2009 19:40: >> On Thu, Dec 10, 2009 at 5:11 PM, Philip Brown wrote: >>> On Wed, Dec 9, 2009 at 11:24 PM, Maciej (Matchek) Blizinski >>> wrote: >>>> Filed bug 4074 about this issue. >>>> >>> Thanks. >>> >>>> My brain says the right thing to do is: >>>> >>>> 1. Get the alternatives mechanism in place >>>> 2. Modify CSWsudo to use it >>>> 3. Modify CSWsudo_ldap to use it, give it higher priority (if both are >>>> installed at the same time, use sudo.ldap) >>>> 4. Remove the stupid symlink from CSWsudo_common >>>> 5. Release all three packages at the same time >>>> >>>> Does it look good? >>> yes... except if it takes more than a week to implement, in which >>> case, I'd say just release new sudo with the symlink in postinstall. >>> sudo needs upgrading sooner rather than later, for security reasons, I thought. >> >> There is no security hole, it's even the opposite: ?the sudo command >> vanishes, and the system becomes more secure, because users can't get >> root. ?Unless they figure out sudo.minimal. >> >> There is one thing I'm curious about. ?If I understand it correctly, >> the transition from the older scheme (CSWsudo containing >> /opt/csw/bin/sudo binary) to the new scheme (CSWsudo containing >> /opt/csw/bin/sudo.minimal and CSWsudo-common containing the symlink), >> assuming the upgrade order (CSWsudo-common gets upgraded first), must >> inevitably lead to the problem I described. ?I find it hard to believe >> that nobody ran into this problem before and that there were no bug >> reports. ?Maintainers, are you sure that the issue hasn't surfaced >> after the introduction of the symlink? > > Just cross-checked with two of our systems which were upgraded recently. > Both have up to date sudo packages now, but no /opt/csw/bin/sudo any > more. So yes, the problem has surfaced, but as we don't use sudo in that > environment it hasn't been noticed so far. I was wondering why were there no bug reports or complaints. In which order does pkg-get upgrade the packages? pkgutil was doing it from bottom-up (i.e. dependencies first). If pkg-get does it the other way (i.e. dependencies last), the upgrade wouldn't cause the issue. > As a side note: I guess with pkgutil 1.9 which removes all > to-be-upgraded packages before installing the newer versions, one > wouldn't see this issue. Right? Correct. From james at opencsw.org Wed Dec 16 11:27:14 2009 From: james at opencsw.org (James Lee) Date: Wed, 16 Dec 2009 10:27:14 GMT Subject: [csw-maintainers] Font packages In-Reply-To: References: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> <20091215.10280500.1365323061@gyor.oxdrove.co.uk> Message-ID: <20091216.10271400.3514256454@gyor.oxdrove.co.uk> On 15/12/09, 17:14:11, Philip Brown wrote regarding Re: [csw-maintainers] Font packages: > > Ideally fonts should be in a common /opt/csw/share/fonts/ directory > > and the default font paths set in the apps. ?The problem is programs > > that index the installed fonts so adding fonts to the directory needs > > a way of notifying the apps, eg, Gostscript's Fontmap.GS. > please propose something? I thought this is what package hooks was for? If not, what I think they are will do it. James. From dam at opencsw.org Wed Dec 16 11:49:27 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 16 Dec 2009 11:49:27 +0100 Subject: [csw-maintainers] Access to the buildfarm via http with Sun Secure Global Desktop In-Reply-To: <6af4270912152345o14005c2ds642cfcebad108997@mail.gmail.com> References: <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> <1260896801-sup-2625@ntdws12.chass.utoronto.ca> <6af4270912152345o14005c2ds642cfcebad108997@mail.gmail.com> Message-ID: <029C3E5C-61F4-4BF6-A786-B30CCDECE9C3@opencsw.org> Hi Rupert, Am 16.12.2009 um 08:45 schrieb rupert THURNER: > On Tue, Dec 15, 2009 at 18:24, Ben Walton wrote: > Excerpts from rupert THURNER's message of Tue Dec 15 11:51:50 -0500 > 2009: > > from work? no, nothing but http/s. but i will ask them if i get an > exception > > for ssh to opencsw. > > the firewall policies allow certain things, and forbid others, > besides the technical restrictions in place. either there is a > technically clean possibility in line with the rules (like Sun SGD), > or i have to go through the paper process for getting a permission > for "ssh login.opencsw". > > but i do not want to break their rules even if technically possible > (e.g. pierce the firewall by tunneling ssh through 443). if i do not > like the rules any more it is time to look for another job i guess :) Fortunately setting up SGD is quite easy. If you want you can try logging in with accessing https://login.opencsw.org (http is redirected). As it is not an official certificate you must accept the root cert and add it to your keystore once. As there needs to be a password set I only opened this for Rupert for now, if anyone else is interested please mail to buildfarm at . Best regards -- Dago From rupert at opencsw.org Wed Dec 16 12:05:56 2009 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 16 Dec 2009 12:05:56 +0100 Subject: [csw-maintainers] Access to the buildfarm via http with Sun Secure Global Desktop In-Reply-To: <029C3E5C-61F4-4BF6-A786-B30CCDECE9C3@opencsw.org> References: <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> <1260896801-sup-2625@ntdws12.chass.utoronto.ca> <6af4270912152345o14005c2ds642cfcebad108997@mail.gmail.com> <029C3E5C-61F4-4BF6-A786-B30CCDECE9C3@opencsw.org> Message-ID: <6af4270912160305n56c0a9f1x460bd23c7b6b07de@mail.gmail.com> On Wed, Dec 16, 2009 at 11:49, Dagobert Michelsen wrote: > Hi Rupert, > > Am 16.12.2009 um 08:45 schrieb rupert THURNER: > >> On Tue, Dec 15, 2009 at 18:24, Ben Walton wrote: >> Excerpts from rupert THURNER's message of Tue Dec 15 11:51:50 -0500 2009: >> > from work? no, nothing but http/s. but i will ask them if i get an >> exception >> > for ssh to opencsw. >> >> the firewall policies allow certain things, and forbid others, besides the >> technical restrictions in place. either there is a technically clean >> possibility in line with the rules (like Sun SGD), or i have to go through >> the paper process for getting a permission for "ssh login.opencsw". >> >> but i do not want to break their rules even if technically possible (e.g. >> pierce the firewall by tunneling ssh through 443). if i do not like the >> rules any more it is time to look for another job i guess :) >> > > Fortunately setting up SGD is quite easy. If you want you can try > logging in with accessing > https://login.opencsw.org > (http is redirected). As it is not an official certificate you must > accept the root cert and add it to your keystore once. > > uuh .. that reminds me that we have another restriction in place: there is a list of trusted ca's. we use a software called "webwasher" which breaks up https connections at the firewall - and blocks everything which is not on this list. but, we convinced the security people to accept http://cacert.org/ certs to have a free alternative as well - besides the usual suspects thawte, etc. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Wed Dec 16 12:17:55 2009 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 16 Dec 2009 12:17:55 +0100 Subject: [csw-maintainers] Access to the buildfarm via http with Sun Secure Global Desktop In-Reply-To: <6af4270912160305n56c0a9f1x460bd23c7b6b07de@mail.gmail.com> References: <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> <1260896801-sup-2625@ntdws12.chass.utoronto.ca> <6af4270912152345o14005c2ds642cfcebad108997@mail.gmail.com> <029C3E5C-61F4-4BF6-A786-B30CCDECE9C3@opencsw.org> <6af4270912160305n56c0a9f1x460bd23c7b6b07de@mail.gmail.com> Message-ID: <6af4270912160317i2c0d7e37m3938468ed768e199@mail.gmail.com> On Wed, Dec 16, 2009 at 12:05, rupert THURNER wrote: > On Wed, Dec 16, 2009 at 11:49, Dagobert Michelsen wrote: > >> Hi Rupert, >> >> Am 16.12.2009 um 08:45 schrieb rupert THURNER: >> >>> On Tue, Dec 15, 2009 at 18:24, Ben Walton wrote: >>> Excerpts from rupert THURNER's message of Tue Dec 15 11:51:50 -0500 2009: >>> > from work? no, nothing but http/s. but i will ask them if i get an >>> exception >>> > for ssh to opencsw. >>> >>> the firewall policies allow certain things, and forbid others, besides >>> the technical restrictions in place. either there is a technically clean >>> possibility in line with the rules (like Sun SGD), or i have to go through >>> the paper process for getting a permission for "ssh login.opencsw". >>> >>> but i do not want to break their rules even if technically possible (e.g. >>> pierce the firewall by tunneling ssh through 443). if i do not like the >>> rules any more it is time to look for another job i guess :) >>> >> >> Fortunately setting up SGD is quite easy. If you want you can try >> logging in with accessing >> https://login.opencsw.org >> (http is redirected). As it is not an official certificate you must >> accept the root cert and add it to your keystore once. >> >> > uuh .. that reminds me that we have another restriction in place: there is > a list of trusted ca's. we use a software called "webwasher" which breaks up > https connections at the firewall - and blocks everything which is not on > this list. > > but, we convinced the security people to accept http://cacert.org/ certs > to have a free alternative as well - besides the usual suspects thawte, etc. > > > i tested it from home and it seems to work great. the following i was wondering: * where to change the password * where to change the terminal type rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Wed Dec 16 13:44:46 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 16 Dec 2009 07:44:46 -0500 Subject: [csw-maintainers] Font packages In-Reply-To: <20091216.10271400.3514256454@gyor.oxdrove.co.uk> References: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> <20091215.10280500.1365323061@gyor.oxdrove.co.uk> <20091216.10271400.3514256454@gyor.oxdrove.co.uk> Message-ID: <1260967259-sup-9606@ntdws12.chass.utoronto.ca> Excerpts from James Lee's message of Wed Dec 16 05:27:14 -0500 2009: > > > a way of notifying the apps, eg, Gostscript's Fontmap.GS. > > > please propose something? > > I thought this is what package hooks was for? If not, what I think > they are will do it. Hooks could do this, but aren't ideally suited to the task. You'd need to do something like: prebatch(remove|install|upgrade): Record list of fonts present postbatch(remove|install|upgrade): Compare current list with previouslist; trigger font index updates if difference. The problems are: 1. The script(s) need to be aware of all different indexes that need updating. 2. It's not plain pkgadd/pkgrm aware. Ultimately, class action scripts would be better for this, but since this whole /usr issue seems so thorny, I'm not sure it will gain tractaion. If only Sun hadn't made this such a fundamental flaw. -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 Dec 16 20:06:55 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Dec 2009 11:06:55 -0800 Subject: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr) In-Reply-To: References: Message-ID: On Tue, Dec 15, 2009 at 2:57 PM, Gary Law wrote: >... Blastwave. They have a larger installed > base, more hits on google (*much* more in fact, and more recent new > pages that refer to them too), active forums and IRC channel that > suggest plenty of users. So lets fix that. It has already been proposed that we need to make an effort to "advertise" ourselves better. I think that those people who are interested in doing something about this, should form an off-list "working group", to improve the situation. I am interested in this, also I think William... who else is willing to actually DO something about it? > What we have is, IMHO, better software. yes we do. > We completely lack credibility otherwise, I'm not sure how this translates into lack of "credibility". To my mind, its just the opposite. Keeping the same prefix, that many of us had, while we worked on "CSW at blastwave", emphasises that it belongs to us, the true continuation of "The CSW packaging project" Changing it, reduces our credibility, by denying the above. I will remind you that "CSW packaging" is *NOT* a creation of Dennis Clarke. He merely hosted it. He never "owned" it, even though he liked to give the appearance that he did. > In this particular case, of course, this is a real problem. I've got > to go to my provider of zones and say ' install this package ' and > hope none of their other customers ever want to use Blastwave. If I > was a commercial provider of zones, and had an understanding of these > issues, I'd refuse to install our package (and the Blastwave one of > the same name) just to avoid future support headaches. I think that the conflict works in our favor; users have to choose between "install blastwave", or "install opencsw", and thus do an evaluation of "which is better?" Almost any sane organization that does the evaluation, will concur that they are better off installing *our* packages. For cases where those organizations have an issue of, "we really like your packages, but there's this specific issue where blastwave has ...." hopefully, they can be encouraged to actually mention this to us, and then we can FIX it. I will take a moment to point out that we are way ahead of blastwave in up to date packages at this point. Since this is a public list, and the "advertising/promote group" has not been formed yet (and I i think would deserve first say on how this is disclosed), I wont mention exactly how far ahead we are. But take my word for it when I say *very* far ahead. From phil at bolthole.com Wed Dec 16 20:20:04 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Dec 2009 11:20:04 -0800 Subject: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr) In-Reply-To: References: Message-ID: On Tue, Dec 15, 2009 at 2:57 PM, Gary Law wrote: > ... > In this particular case, of course, this is a real problem. I've got > to go to my provider of zones and say ' install this package ' and > hope none of their other customers ever want to use Blastwave. oh, a small point on zone compatibility, btw: sparse zones usually share /usr from the global zone. However, no-one says they HAVE to. They can actually share /usr from somewhere else(whether that be a non-global zone, or somewhere else entirely) Similar for /opt, and /opt/csw, if you want those shared rather than zone-local. Additionally.. just because /usr is read-only, doesnt mean that you cannot modify it for a zone, funnily enough :-} If for some reason, you really REALLY want multiple zones on a single box, all with single shared /usr from global zone.. but you wish some zones to use blastwave, and others to use opencsw.. and thus you maybe have a conflict in /usr/sadm/install/scripts... You can have an overlay mount for /usr/sadm/install/scripts. Its not quite as pretty or simple, as just having "everything use opencsw". But it is as least, not an insurmountable problem. From phil at bolthole.com Wed Dec 16 20:36:59 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Dec 2009 11:36:59 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <4B27FAA3.9030903@opencsw.org> Message-ID: On Wed, Dec 16, 2009 at 12:27 AM, Maciej (Matchek) Blizinski wrote: > > I was wondering why were there no bug reports or complaints. In which > order does pkg-get upgrade the packages? ?pkgutil was doing it from > bottom-up (i.e. dependencies first). ?If pkg-get does it the other way > (i.e. dependencies last), the upgrade wouldn't cause the issue. > pkg-get does dependancies first. It actually insists that (direct)dependancies be up to date, before it will update a package. side note: perhaps there are few complaints, because there are few people who trust a third party sudo package, but usually create their own ;-) From james at opencsw.org Thu Dec 17 11:25:06 2009 From: james at opencsw.org (James Lee) Date: Thu, 17 Dec 2009 10:25:06 GMT Subject: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr) In-Reply-To: References: Message-ID: <20091217.10250600.3134011945@gyor.oxdrove.co.uk> On 16/12/09, 19:20:04, Philip Brown wrote regarding Re: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr): > sparse zones usually share /usr from the global zone. However, no-one > says they HAVE to. > They can actually share /usr from somewhere else(whether that be a > non-global zone, or somewhere else entirely) > Similar for /opt, and /opt/csw, if you want those shared rather than > zone-local. No one says I have to share /usr, or use zones, or use CSW, or use Solaris - but I choose to. Zones are good *because* they allow me to share resources, suggesting I don't as a workaround is stupid. Example: $ zoneadm list -c | wc -l 14 $ du -sh /usr 5.7G /usr 13 * 5.7G > 100% full, the only reason this system exists is because I share /usr/. I could buy 2 more hard drives but then I couldn't spend the money on something else, and eventually the point comes when I can't buy more kit, or anything else. (If ZFS clones worked with live update it would be different.) James. From maciej at opencsw.org Thu Dec 17 21:08:50 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 17 Dec 2009 20:08:50 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <4B0D1316.5000704@opencsw.org> References: <4AF342DE.2020604@opencsw.org> <4AF5B104.90307@opencsw.org> <4AF74A6F.6010004@opencsw.org> <4B0D1316.5000704@opencsw.org> Message-ID: mysql 5.0.87 has been sitting in testing for quite a while now. I was thinking to spend more time on it, but I've been sidetracked by other things. Since I'm not going to work on mysql-5.1 tests in the nearest weeks, what do you think of releasing the packages from testing? It's a question partly to the general maintainers audience, and partly to Phil as the release manager. Maciej From phil at bolthole.com Thu Dec 17 23:55:08 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 17 Dec 2009 14:55:08 -0800 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> <4AF5B104.90307@opencsw.org> <4AF74A6F.6010004@opencsw.org> <4B0D1316.5000704@opencsw.org> Message-ID: On Thu, Dec 17, 2009 at 12:08 PM, Maciej (Matchek) Blizinski wrote: > mysql 5.0.87 .[...]. > ?It's > a question partly to the general maintainers audience, and partly to > Phil as the release manager. > my comments are: while 5.1 would of course be better, it's at least an improvement over what we currently have, 5.0.51. = ancient. If at least one other person can say they tried it out, in however limited a form, I'd say lets release it. From glaw at opencsw.org Fri Dec 18 09:50:14 2009 From: glaw at opencsw.org (Gary Law) Date: Fri, 18 Dec 2009 08:50:14 +0000 Subject: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr) In-Reply-To: References: Message-ID: Hi 2009/12/16 Philip Brown : > On Tue, Dec 15, 2009 at 2:57 PM, Gary Law wrote: >>... Blastwave. They have a larger installed >> base, more hits on google (*much* more in fact, and more recent new >> pages that refer to them too), active forums and IRC channel that >> suggest plenty of users. > > > So lets fix that. Fixing that is not a bad idea. However, until it is fixed, we should recognise that we're not the dominant software distributor in the /opt/csw space. It is therefore unwise to make statements along the lines of no-one who matters will ship software with conflicting names. > It has already been proposed that we need to make an effort to > "advertise" ourselves better. I think that those people who are > interested in doing something about this, should form an off-list > "working group", to improve the situation. > > I am interested in this, also I think William... who else is willing > to actually DO something about it? I've chatted to William about this on IRC, and I love what he's done with the beta website. Let's get it launched and get google trawling it. >> What we have is, IMHO, better software. > > yes we do. > >> We completely lack credibility otherwise, > > I'm not sure how this translates into lack of "credibility". > > To my mind, its just the opposite. Keeping the same prefix, that many > of us had, while we worked on "CSW at blastwave", emphasises that it > belongs to us, the true continuation of "The CSW packaging project" > > Changing it, reduces our credibility, by denying the above. > > I will remind you that "CSW packaging" is *NOT* a creation of Dennis > Clarke. He merely hosted it. He never "owned" it, even though he liked > to give the appearance that he did. No-one owns a name space in this context. But whatever the rights and wrongs of who owns the name the mature and sensible approach at this stage is to walk away from the /opt/csw space (and CSW packaging prefix) because someone else is using it. Never mind that it wasn't his idea, the conflict is damaging. >> In this particular case, of course, this is a real problem. I've got >> to go to my provider of zones and say ' install this package ' and >> hope none of their other customers ever want to use Blastwave. If I >> was a commercial provider of zones, and had an understanding of these >> issues, I'd refuse to install our package (and the Blastwave one of >> the same name) just to avoid future support headaches. > > I think that the conflict works in our favor; users have to choose > between "install blastwave", or "install opencsw", and thus do an > evaluation of "which is better?" Or say, 'sod it, neither of them untill they sort their act out'. Which is what I would do if I were such a commercial provider -- there's no way I'd 'take sides' like that. > Almost any sane organization that does the evaluation, will concur > that they are better off installing *our* packages. > > For cases where those organizations have an issue of, "we really like > your packages, but there's this specific issue where blastwave has > ...." hopefully, they can be encouraged to actually mention this to > us, and then we can FIX it. > > I will take a moment to point out that we are way ahead of blastwave > in up to date packages at this point. > Since this is a public list, and the "advertising/promote group" has > not been formed yet (and I i think would deserve first say on how this > is disclosed), I wont mention exactly how far ahead we are. > But take my word for it when I say *very* far ahead. This should not be a matter of Blastwave vs. OpenCSW any more than OpenCSW is 'vs' Sunfreeware. All should be able to exist independently, no admin should be forced to choose. We're getting close to the point where most of our software is in GAR (which is where this thread started, I'm having trouble with /usr!) which means we can rebuild and retarget on mass. Gary -- glaw at opencsw.org From rupert at opencsw.org Fri Dec 18 17:53:19 2009 From: rupert at opencsw.org (rupert THURNER) Date: Fri, 18 Dec 2009 17:53:19 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4ADB697E.5060403@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> <4ADB4837.9010404@opencsw.org> <1255887034-sup-5726@ntdws12.chass.utoronto.ca> <4ADB697E.5060403@opencsw.org> Message-ID: <6af4270912180853r22f087aet4756e5d47dd2c4a6@mail.gmail.com> maciej and i tried to convert apache2 to dynamic prototype, and removed the gspec files. to have a testable version i switched back to a single-package apache2, which i also moved into /home/testing to give it a try. some links: * ihsan's version: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/apache2/tags/apache-2.2.13-by-idogan * last commit: http://sourceforge.net/apps/trac/gar/changeset/7671 * http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/apache2/trunk/files?rev=7671 post/pre scripts need to be verified * http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/apache2/trunk/Makefile?rev=7667 version of the makefile which still has all the packages, but i did not get it to work it would be great if somebody more experienced could have a look what was wrong with the multiple packages Makefile. it did not produce distinct prototype files. some of the packages then had an empty prototype file, others had a prototype file containing everything. rupert. On Sun, Oct 18, 2009 at 20:16, Ihsan Dogan wrote: > Am 18.10.2009 19:31 Uhr, Ben Walton schrieb: > > > Excerpts from Ihsan Dogan's message of Sun Oct 18 12:54:15 -0400 2009: > > > >> The packaging has to be changed to dynamic prototype, gspec files has to > >> be removed and maybe the packaging of the rt and c package has to be > >> verified. > > > > ...and sysconfdir -> /etc/opt/csw/apache2, localstatedir -> > > /var/opt/csw/apache2? [Just a personal wishlist item.] > > Of course, I've forgot that one. This would require coordination with > other package maintainers. > > > > Ihsan > > -- > ihsan at dogan.ch http://blog.dogan.ch/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Dec 18 18:25:05 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 18 Dec 2009 18:25:05 +0100 Subject: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr) In-Reply-To: References: Message-ID: <7562555E-319E-4091-9F1C-82C24C43B25B@opencsw.org> Hi Gary, Am 18.12.2009 um 09:50 schrieb Gary Law: >> It has already been proposed that we need to make an effort to >> "advertise" ourselves better. I think that those people who are >> interested in doing something about this, should form an off-list >> "working group", to improve the situation. >> >> I am interested in this, also I think William... who else is willing >> to actually DO something about it? > > I've chatted to William about this on IRC, and I love what he's done > with the beta website. Let's get it launched and get google trawling > it. If you have spare cycles you can speed it up by working on any item on the todo list at http://wiki.opencsw.org/new-website Best regards -- Dago From phil at bolthole.com Fri Dec 18 18:34:15 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 09:34:15 -0800 Subject: [csw-maintainers] advertising Message-ID: On Fri, Dec 18, 2009 at 12:50 AM, Gary Law wrote: > Hi > > 2009/12/16 Philip Brown : > >> It has already been proposed that we need to make an effort to >> "advertise" ourselves better. I think that those people who are >> interested in doing something about this, should form an off-list >> "working group", to improve the situation. >> >> I am interested in this, also I think William... who else is willing >> to actually DO something about it? > > I've chatted to William about this on IRC, and I love what he's done > with the beta website. Let's get it launched and get google trawling > it. Thats nice an all,... but it doesnt really address the topic of my paragraph there. The core issue being, How do we get more people aware of us/using our packages? While getting the beta website productional would be "more pretty"... I dont think that it will have any impact towards "getting more people aware of us/using our packages". From phil at bolthole.com Fri Dec 18 18:43:05 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 09:43:05 -0800 Subject: [csw-maintainers] advertising Message-ID: PS: On Fri, Dec 18, 2009 at 12:50 AM, Gary Law wrote: > > This should not be a matter of Blastwave vs. OpenCSW any more than > OpenCSW is 'vs' Sunfreeware. ?? Of COURSE we are "vs" sunfreeware, et. al. We should be(?) trying to make "the best packages for solaris out there". "best" means "better than all others". Therefore, we are already in competition with them. If we are not trying to generate a better product, then what's the point? > All should be able to exist > independently, no admin should be forced to choose. Admins are already "forced" to choose in various ways. They are "forced" to choose which mail program they use to process their email. They are "forced" to choose which web server, from which "vendor" they are going to use to run their website. Unless a company's business, is providing "choice" to other businesses, they will almost inevitably choose one solution for all their packaging needs, and go with it, until such time as another solution shows itself as better. We should have our mission to prove ourselves as "the better solution", in all cases. In any cases where we are not.. let's fix it! From skayser at opencsw.org Fri Dec 18 20:37:52 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 18 Dec 2009 20:37:52 +0100 Subject: [csw-maintainers] Incompatible packages? Musing about mtr and mtr-tiny Message-ID: <4B2BDA10.2020905@opencsw.org> Hi, what's the current stance on incompatible packages? We currently have "mtr" in it's GUI version in the catalog which pulls in the whole g* and X11 chain. I would like to update it and also release an additional, non-GUI package (with a reduced dependency chain) as "mtr-tiny" and set it to incompatible with "mtr". The binary name in both cases is the same "mtr". That's the way Debian does it. When one had installed "mtr-tiny" and then installs "mtr" apt-get/aptitude will uninstall "mtr-tiny" first (and vice versa). Simple solution, no dangling symlinks like it just happened with sudo and it's package variants. On servers one usually just installs "mtr-tiny" and doesn't need any X. Do pkg-get/pkgutil support the concept of incompatible packages at all, i.e. would they uninstall an incompatible package before installing the new one? I remember, there were some reservations against incompatible packages because of "pkg-get install all". To cut a long story short: can we do the same as the Debian folks do or do we have another way to achieve what I need to do? Sebastian From phil at bolthole.com Fri Dec 18 20:57:25 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 11:57:25 -0800 Subject: [csw-maintainers] Incompatible packages? Musing about mtr and mtr-tiny In-Reply-To: <4B2BDA10.2020905@opencsw.org> References: <4B2BDA10.2020905@opencsw.org> Message-ID: On Fri, Dec 18, 2009 at 11:37 AM, Sebastian Kayser wrote: > Hi, > > what's the current stance on incompatible packages? We currently have > "mtr" in it's GUI version in the catalog which pulls in the whole g* and > X11 chain. I would like to update it and also release an additional, > non-GUI package (with a reduced dependency chain) as "mtr-tiny" and set > it to incompatible with "mtr". The binary name in both cases is the same > "mtr". >... > Do pkg-get/pkgutil support the concept of incompatible packages at all, > i.e. would they uninstall an incompatible package before installing the > new one? they WOULD uninstall an incompatible package. however, you are only allowed to be "incompatible" with a package that is no longer in "current". Happily, you have other options. [What I had written up, I am now editing, because current mtr pkg is orphaned] So, you have volunteered to take over the mgr package. You thus have a few options that I see. (there may be more,but here are the "obvious" ones that come to mind): A) Take over mgr, publish it with the "tiny" compiled version, but hopefully also release a GUI version, which you can then rename "mtr_x11" or something B) [I would normaly suggest a combined package, but you explicitly want a reduced dependancy package, so this option is scratched] C) publish mtr_tiny and mtr_x11;have a postinstall or something create a symlink from "mtr" to whichever the user prefers. You can pick your own preference as "default", but then in future installs, leave the symlink if it already exists. (This would be an appropriate use of the recently proposed "alternatives" system, if we can agree on implementation and naming of it ;-) From maciej at opencsw.org Fri Dec 18 21:14:05 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 18 Dec 2009 20:14:05 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Dec 11, 2009 at 5:00 PM, Philip Brown wrote: > I like the concept of the alternatives system. I'm suggesting we > implement debian normal behavior, and then *augment* it, to be better. > Such as, including a short-command invocation. If I sent CSWalternatives as is for release, what would you say? From skayser at opencsw.org Fri Dec 18 21:54:20 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 18 Dec 2009 21:54:20 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> Message-ID: <4B2BEBFC.4040601@opencsw.org> Peter Bonivart wrote on 10.12.2009 15:06: > On Thu, Dec 10, 2009 at 2:05 PM, Sebastian Kayser wrote: >> Peter, did you experiment with the approach that we came up with during >> summer camp? Put dummy CAS scripts in the package which hand over to the >> real CAS scripts in /opt/csw/somewhere. This way we wouldn't need to >> have our CAS scripts beneath /usr. > > No, I haven't had time to yet but if that approach works it's the only > sane way to go if we're not to take a giant step backwards. > >> Does the user get prompted with "do you really want the package to do >> things that you probably don't care about"? > > Yes. Couldn't we simply ship pkgutil/pkg-get with a admin(4) file that suppresses CAS warnings and then call pkgadd with it per default? Then we could have: - cswclassutils: Eventually move from /usr to /opt/csw/somewhere. While not all been packages have been converted, maintain the CAS twice for /usr and /opt/csw/somewhere. - GAR: For each requested CAS "cswfoo", include a stub CAS {i,r}.cswfoo in the package which only hands over to /opt/csw/somehwere/{i,r}.cswfoo. Current packages need to be rebuilt, so that we can get rid of /usr eventually. - pkg-get/pkgutil: On package installation call pkgadd with a admin file to suppress CAS prompts. Sebastian From phil at bolthole.com Fri Dec 18 22:11:07 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 13:11:07 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Dec 18, 2009 at 12:14 PM, Maciej (Matchek) Blizinski wrote: > On Fri, Dec 11, 2009 at 5:00 PM, Philip Brown wrote: >> I like the concept of the alternatives system. I'm suggesting we >> implement debian normal behavior, and then *augment* it, to be better. >> Such as, including a short-command invocation. > > If I sent CSWalternatives as is for release, what would you say? > I would say, "please add a symlink for a shorter name to type, and I'd be happy to drop it in" :-) Otherwise, if you wished to argue aobut it, then things get complicated. Given that this is a proposed addition to the standard CSW toolset, its very important to make at "all it can be", as it were :-) It's not my decision alone, but I'd want to have a decent open discussion/vote on it. either via the board, or the maintainer list. As a pre-argument I would mention: what strong argument do you have for specifically NOT putting it in? It in no way detracts from the functionality, and it definately enhances it. It also allows us to give it a bit more csw personality at the same time, which is an additional bonus. Not to mention it is a trivial amount of work to do. Just add a symlink. ************ Erm... now that I'm taking a deeper look at it though... are you sure this thing is going to work ok for us? Its got a whoole lot of stuff, rather explicitly labeled "Dpkg". Virtually the whole thing, seems to be a bunch of perl modules under /opt/csw/share/perl/csw/Dpkg That makes me worried. A whole bunch of extra code that "isnt needed" but still laying around, has a tendancy to bite you in the rear later when you least expect it. The concept doesnt sound too terribly difficult. If I had more time, I would simply write a clean 'workalike', as I did when I created pkg-get to stand in for apt-get. I would guess it shouldnt take a competant shellscript programmer more than a few hours. However, I have 3 children to take care of this weekend, so I dont HAVE "a few hours" myself to spare. PS: if you dont realize how seriously I take user-level compatibility in "workalikes", you probably havent compared output of "apt-get moo" vs "pkg-get moo" ;-) From phil at bolthole.com Fri Dec 18 22:22:19 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 13:22:19 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <4B2BEBFC.4040601@opencsw.org> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> Message-ID: On Fri, Dec 18, 2009 at 12:54 PM, Sebastian Kayser wrote: > > > Couldn't we simply ship pkgutil/pkg-get with a admin(4) file that > suppresses CAS warnings and then call pkgadd with it per default? I would guess you mean "suppress postinstall scripts" warnings. pkg-get already ships with an OPTIONAL admin file to do just that. However, sysadmins who care about security (or sysadmins who just want to know very closely, what random install scripts mess with) tend to not appreciate that sort of behaviour by default. > Then we could have: > > - cswclassutils: Eventually move from /usr to /opt/csw/somewhere. > ?While not all been packages have been converted, maintain the > ?CAS twice for /usr and /opt/csw/somewhere. I thought of this when I first proposed the class action script approach, years ago now. However... have you tested whether class action scripts WORK anywhere other than /usr/sadm/blah, if they are not in the same package? As far as I recall, they do not. They must be in either /usr/blah, or in each individual package that uses it. Thus, there are TWO major benefits to our existing classactions scripts: 1. user doesnt get prompted about routine boring stuff from a postinstall script 2. There is a COMMON utility across all our packages, deployed to a SINGLE place. This means that if we update a class action script, we update it ONE time,and all packages get the benefit. The alternative, would mean that, if we bundled class action scripts individually in every package that used them... then every time we find, "oh dear, there's a bug in [classactionscriptfoo]", we would need to repackage and release EVERY PACKAGE that used it!! Take a look at http://www.opencsw.org/packages/cswclassutils I would guestimate there are... 100? packages that use cswclassutils now. I will propose an alternative, that came to me today while pondering this problem. An alternative, would be for us to publish our own version of the SVR4 pkg utils. This version would respect class action scripts elsewhere, such as /opt/csw/[whereever]. We could then do the "dual publish" mechanism that you propose, and which I am actually in favour of. If it actually WORKED :-} Sadly, I myself do not have the time to do this. I imagine it would be a considerable effort for someone to do this. Allegedly, the source is out there somewhere... but you'd have to track it down and make it useable. From skayser at opencsw.org Fri Dec 18 23:08:40 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 18 Dec 2009 23:08:40 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> Message-ID: <4B2BFD68.6090301@opencsw.org> Philip Brown wrote on 18.12.2009 22:22: > On Fri, Dec 18, 2009 at 12:54 PM, Sebastian Kayser wrote: >> >> Couldn't we simply ship pkgutil/pkg-get with a admin(4) file that >> suppresses CAS warnings and then call pkgadd with it per default? > > I would guess you mean "suppress postinstall scripts" warnings. No, I specifically meant suppress CAS warnings. Please see below. >> Then we could have: >> >> - cswclassutils: Eventually move from /usr to /opt/csw/somewhere. >> While not all been packages have been converted, maintain the >> CAS twice for /usr and /opt/csw/somewhere. > > I thought of this when I first proposed the class action script > approach, years ago now. However... have you tested whether class action > scripts WORK anywhere other than /usr/sadm/blah, if they are not in > the same package? As far as I recall, they do not. They must be > in either /usr/blah, or in each individual package that uses it. Correct. My thought was to add _CAS stubs_ for required functionality to our packages. These would be added by GAR and do nothing more than something similar to exec /opt/csw/somewhere/{i,r}.cswfoo plus some logic for Jumpstart and zone environments where /opt/csw/somewhere is /$someprefix/opt/csw/somewhere. So our whole suite of CAS would be centrally maintained at /opt/csw/somewhere. Combined with the admin file to suppress CAS prompts (for the CAS stubs in the package) this would free us from /usr and not incur any additional prompts to the user. > Thus, there are TWO major benefits to our existing classactions scripts: > > 1. user doesnt get prompted about routine boring stuff from a postinstall script > > 2. There is a COMMON utility across all our packages, deployed to a > SINGLE place. > This means that if we update a class action script, we update it ONE > time,and all packages get the benefit. > The alternative, would mean that, if we bundled class action scripts > individually in every package that used them... then every time we > find, "oh dear, there's a bug in [classactionscriptfoo]", we would > need to repackage and release EVERY PACKAGE that used it!! With the suggested approach, the main intelligence is kept in /opt/csw/somewhere. The CAS bundled with the packages are simple stubs so that the likelihood of bugs in these stubs is minimized. Still, you are right, if there were a bug in one of these stubs each dependent pkg would need to be repackaged (not rebuilt). > I will propose an alternative, that came to me today while pondering > this problem. An alternative, would be for us to publish our own > version of the SVR4 pkg utils. This version would respect class action > scripts elsewhere, such as /opt/csw/[whereever]. [...] I imagine it > would be a considerable effort for someone to do this. Allegedly, > the source is out there somewhere... but you'd have to track it down > and make it useable. Sounds like a substantial effort to deliver/maintain and honestly, I as a sysadmin would not be willing to install 3rd party repackaged pkg* tools which directly deal with my package database. Currently, I am not sure whether either options is a viable one. Sebastian From skayser at opencsw.org Fri Dec 18 23:28:43 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 18 Dec 2009 23:28:43 +0100 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: <4B2C021B.50800@opencsw.org> Philip Brown wrote on 18.12.2009 22:11: > On Fri, Dec 18, 2009 at 12:14 PM, Maciej (Matchek) Blizinski > wrote: >> On Fri, Dec 11, 2009 at 5:00 PM, Philip Brown wrote: >>> I like the concept of the alternatives system. I'm suggesting we >>> implement debian normal behavior, and then *augment* it, to be better. >>> Such as, including a short-command invocation. >> If I sent CSWalternatives as is for release, what would you say? >> > > I would say, "please add a symlink for a shorter name to type, and I'd > be happy to drop it in" :-) > > Otherwise, if you wished to argue aobut it, then things get complicated. > Given that this is a proposed addition to the standard CSW toolset, > its very important to make at "all it can be", as it were :-) > It's not my decision alone, but I'd want to have a decent open > discussion/vote on it. either via the board, or the maintainer list. > > As a pre-argument I would mention: what strong argument do you have > for specifically NOT putting it in? It in no way detracts from the > functionality, and it definately enhances it. It also allows us to > give it a bit more csw personality at the same time, which is an > additional bonus. > > Not to mention it is a trivial amount of work to do. Just add a symlink. A slight concern of mine would be: besides the symlink, it is another invocation method that one has to keep in mind. update-alternatives on it's own is canonical and well-known from Debian, add cswua (or similar) to the mix and it will introduce ambiguity when people start talking about tools. In the end I would bet you a crate of beer that there are more OpenCSW users who would potentially be exposed to update-alternatives/cswua and ambiguity than there are OpenCSW users who are currently exposed to non-autocompletion-shells. ;) Sebastian From phil at bolthole.com Fri Dec 18 23:34:38 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 14:34:38 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <4B2BFD68.6090301@opencsw.org> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> Message-ID: On Fri, Dec 18, 2009 at 2:08 PM, Sebastian Kayser wrote: > Philip Brown wrote on 18.12.2009 22:22: >> >> >> I would guess you mean "suppress postinstall scripts" warnings. > > No, I specifically meant suppress CAS warnings. Please see below. Hm. things are getting long, so I think it would be beneficial to restate in full your proposal, and perhaps it will actually take up less space that way :) What I believe you are suggesting, is as follows: - We still use things such as f cswpreserveconf /etc/opt/csw/yourprog.cnf.CSW 0444 root bin however, the class action "cswpreserveconf", you are proposing be a very dumb stub, included in every package, which would somehow hand things off to /opt/csw/share/CSWUTILS/[...] Since these are no longer "bundled/installed" class actions, they would trigger class action warnings. Which you are then suggesting we suppress by forcing an admin file, "dont prompt user about questionable-security activities of packages". that about sum it up? I have two comments on this: 1. In some respects that seems only slightly different, from just doing everything in postinstall scripts, that call "standard" csw utils, rather than having everything inline. I'm not sure it is strictly better than the simplistic postinstall way. 2. It requires having an admin disable LEGITIMATE warnings, to be spared the prescreened trivial warnings. (ie: you propose disable ALL class action script warnings, not just warnings about the official csw pre-screened actions) So, while your proposal does address the "single point of update" issue, it still leaves the security issue open. I will point out,that one of the reasons sun chose /usr/sadm to be the official residence of approved class action utils, is exactly BECAUSE it is often mounted read-only, in security-sensitive installations!! it is expected, and encouraged, to only very rarely update things in there, and thus to have detailed inspections and approvals for it when they are. (which as a side note, should serve as a reminder to us, to only update cswclassutils infrequently, and to ensure 100% backward compatibility for it) >> I will propose an alternative, that came to me today while pondering >> this problem. An alternative, would be for us to publish our own >> version of the SVR4 pkg utils. This version would respect class action >> scripts elsewhere, such as /opt/csw/[whereever]. [...] I imagine it >> would be a considerable effort for someone to do this. Allegedly, >> the source is out there somewhere... but you'd have to track it down >> and make it useable. > > Sounds like a substantial effort to deliver/maintain and honestly, I as > a sysadmin would not be willing to install 3rd party repackaged pkg* > tools which directly deal with my package database. you are not open to that, but you ARE perfectly happy with turning off all security warnings when you add a package? This policy seems to be a little... lacking.. to me :-} From phil at bolthole.com Fri Dec 18 23:44:17 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 14:44:17 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: <4B2C021B.50800@opencsw.org> References: <4B2C021B.50800@opencsw.org> Message-ID: On Fri, Dec 18, 2009 at 2:28 PM, Sebastian Kayser wrote: > Philip Brown wrote on 18.12.2009 22:11: >> >> >> As a pre-argument I would mention: what strong argument do you have >> for specifically NOT putting it in? ?It in no way detracts from the >> functionality, and it definately enhances it. It also allows us to >> give it a bit more csw personality at the same time, which is an >> additional bonus. >> >> Not to mention it is a trivial amount of work to do. Just add a symlink. > > A slight concern of mine would be: besides the symlink, it is another > invocation method that one has to keep in mind. update-alternatives on > it's own is canonical and well-known from Debian, add cswua (or similar) > to the mix and it will introduce ambiguity when people start talking > about tools. by that argument, you might say that me naming "pkg-get" as such, and not "apt-get", was just too confusing, because since the userland syntax is the same, and it IS a 90% clone of apt-get, I should have kept the name as apt-get. I posit this argument to be false :-) Taking some of what you said into account, however: I would further suggest, that our OFFICIAL name, for it, be the shorter name, and the longer name of "update-alternatives" be present only for people whose minds are not flexible enough to realize they arent running debian any more. (if people want to pretend they are EXACTLY the same as debian.. that's what nexenta is for, after all? ;-) There, we have resolved the "ambiguity problem" :-D Besides which, it is more than likely down the road, that at some point, we will want the finer points of our alternatives system to be a little different from the debian one. At which point, if we have trained users to refer to it as the debian name, it will be all the more confusing. > In the end I would bet you a crate of beer that there are more OpenCSW > users who would potentially be exposed to update-alternatives/cswua and > ambiguity than there are OpenCSW users who are currently exposed to > non-autocompletion-shells. ;) I would be more willing to take you up on that bet, if we had a decent short-name alternative to put to a vote ;) besides which: you have conflicts even with "autocompletion shells", all the way out to "update". try this: grep bin/update /var/sadm/install/contents |nawk '{print $1}' or worse, grep bin/up /var/sadm/install/contents |nawk '{print $1}' From bwalton at opencsw.org Sat Dec 19 01:27:35 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 18 Dec 2009 19:27:35 -0500 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <4B2C021B.50800@opencsw.org> Message-ID: <1261181863-sup-5150@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Dec 18 17:44:17 -0500 2009: > by that argument, you might say that me naming "pkg-get" as such, and > not "apt-get", was just too confusing, because since the userland > syntax is the same, and it IS a 90% clone of apt-get, I should have > kept the name as apt-get. The difference being pkg-get is an apt-get workalike. The package Maciej has put forward is the 'real deal[1].' While the name used in Debian is long and annoying to type, even with auto-completion, it's really not something you interact with often, if at all. So, my 'vote' is that if we don't do a ground up reimplementation, we stick with the name from Debian. If somebody wants to invest the time tailoring a solution to CSW, pick a new name. Is anyone else out there not making use of auto-completion shell features? Life feels too short for that! :) -Ben [1] It's the identical code/functionality split out from a larger Debian package. -- 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 Dec 19 17:41:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 19 Dec 2009 17:41:26 +0100 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <4B2C021B.50800@opencsw.org> Message-ID: <00611D04-93AA-423F-B656-EE6A512A9190@opencsw.org> Hi Phil, Am 18.12.2009 um 23:44 schrieb Philip Brown: > On Fri, Dec 18, 2009 at 2:28 PM, Sebastian Kayser > wrote: >> Philip Brown wrote on 18.12.2009 22:11: >>> >>> >>> As a pre-argument I would mention: what strong argument do you have >>> for specifically NOT putting it in? It in no way detracts from the >>> functionality, and it definately enhances it. It also allows us to >>> give it a bit more csw personality at the same time, which is an >>> additional bonus. >>> >>> Not to mention it is a trivial amount of work to do. Just add a >>> symlink. >> >> A slight concern of mine would be: besides the symlink, it is another >> invocation method that one has to keep in mind. update-alternatives >> on >> it's own is canonical and well-known from Debian, add cswua (or >> similar) >> to the mix and it will introduce ambiguity when people start talking >> about tools. > > by that argument, you might say that me naming "pkg-get" as such, and > not "apt-get", was just too confusing, because since the userland > syntax is the same, and it IS a 90% clone of apt-get, I should have > kept the name as apt-get. No, because it is not apt-get, but a 90% clone. cswua is 100% update-alternatives. If you as a admin-user do this seldom you won't bother typing it and if you do it regularly then you'll add a shell alias. Or would you also argument to have a "ll" (or "cswll") binary for "ls -l" in GNU coreutils? Best regards -- Dago From rupert at opencsw.org Sat Dec 19 21:24:43 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 19 Dec 2009 21:24:43 +0100 Subject: [csw-maintainers] trac-0.11.6 now in testing Message-ID: <6af4270912191224o187cadadma02e5f7e51ac3590@mail.gmail.com> hi, trac-0.11.6 is now in testing. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Sun Dec 20 02:39:46 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 02:39:46 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? Message-ID: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> hi, while trying to upgrade apache2 i thought it uses the apr package and so i tried to upgrade this as well, and it gives an error while testing: ... testsockets : FAILED 1 of 7 ... Failed Tests Total Fail Failed % =================================================== testsockets 7 1 14.29% gmake[1]: *** [test-work/solaris8-sparc/build-isa-sparcv8/apr-1.3.9/Makefile] Error 2 gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' gmake: *** [merge-isa-sparcv8] Error 2 was this always like this or it is new? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Sun Dec 20 05:40:26 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 05:40:26 +0100 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ Message-ID: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> hi, dagobert filed a subversion bug saying the config file should go in a different place: The configuration for the svn commandline-client is at /etc/subversion/servers instead of /etc/opt/csw/subversion/servers isn't this a standard configuration option and gar should do this? an excerpt from the subversion configure is below: rupert at build8s: ... build-isa-sparcv8/subversion-1.6.6 $ ./configure --help `configure' configures subversion 1.6.6 to adapt to many kinds of systems. ... an installation prefix other than `/usr/local' using `--prefix', for instance `--prefix=$HOME'. For better control, use the options below. Fine tuning of the installation directories: .... --sysconfdir=DIR read-only single-machine data [PREFIX/etc] ... rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Dec 20 12:10:28 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 20 Dec 2009 11:10:28 +0000 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> Message-ID: On Sun, Dec 20, 2009 at 4:40 AM, rupert THURNER wrote: > hi, > > dagobert filed a subversion bug saying the config file should go in a > different place: > > The configuration for the svn commandline-client is at > ??/etc/subversion/servers > instead of > ??/etc/opt/csw/subversion/servers > > isn't this a standard configuration option and gar should do this? It depends on the kind of the operating system. On Solaris, the convention is that if you're not Sun, you have to install everything under a custom prefix. Nothing, if at all possible, goes into /usr or /etc without a prefix. We use /opt/csw for everything, except the directories that must be writable. Those go into /var/opt/csw and /etc/opt/csw. See here, these are files already in this directory put there by other packages: http://www.opencsw.org/search.php?filename=/etc/opt/csw&searchfiles=1&matchtype=partial At the same time, these need to be migrated: http://www.opencsw.org/search.php?filename=/opt/csw/etc&searchfiles=1&matchtype=partial Maciej From maciej at opencsw.org Sun Dec 20 12:26:18 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 20 Dec 2009 11:26:18 +0000 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> References: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> Message-ID: On Sat, Dec 12, 2009 at 2:53 AM, Ben Walton wrote: > Use the dynamic adm script capability in GAR. > > See docbook-style-xsl: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/docbook-style-xsl/trunk/Makefile > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/docbook-style-xsl/trunk/files/CSWdocbookxsl.postinstall > > Just be careful to $$ when you need to use a shell variable as the > script is subject to regular Makefile expansion rules. ?Also, the > final product will be much less readable than a normal script. > > Is this what you're after? Yes, this is it. I have some more questions: - At which stage (fetch, extract, install, merge, package) does the expansion take place? - What if the pkgname contains a dash? Will "define CSWfoo-bar_postinstall" work? From rupert at opencsw.org Sun Dec 20 12:52:24 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 12:52:24 +0100 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> Message-ID: <6af4270912200352pee36f58ge14b8a8ee183f907@mail.gmail.com> On Sun, Dec 20, 2009 at 12:10, Maciej (Matchek) Blizinski < maciej at opencsw.org> wrote: > On Sun, Dec 20, 2009 at 4:40 AM, rupert THURNER > wrote: > > hi, > > > > dagobert filed a subversion bug saying the config file should go in a > > different place: > > > > The configuration for the svn commandline-client is at > > /etc/subversion/servers > > instead of > > /etc/opt/csw/subversion/servers > > > > isn't this a standard configuration option and gar should do this? > > It depends on the kind of the operating system. On Solaris, the > convention is that if you're not Sun, you have to install everything > under a custom prefix. Nothing, if at all possible, goes into /usr or > /etc without a prefix. We use /opt/csw for everything, except the > directories that must be writable. Those go into /var/opt/csw and > /etc/opt/csw. > > the default says " [PREFIX/etc]" which in my understanding means /opt/csw/etc. and i was really wondering who changes this where to make it /etc ? is this a bug in the subversion configure description or implementation, or gar does something? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sun Dec 20 13:30:59 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 20 Dec 2009 07:30:59 -0500 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> Message-ID: <1261312122-sup-4951@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sun Dec 20 06:26:18 -0500 2009: > - At which stage (fetch, extract, install, merge, package) does the > expansion take place? The scripts should be expanded into $(DOWNLOADDIR) during the extract stage. > - What if the pkgname contains a dash? Will "define > CSWfoo-bar_postinstall" work? That should still work. The scripts are activated on seeing variables named like $(PKG)_$(ADMSCRIPT), so the - shouldn't cause problems. Let me know if it does. 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 bwalton at opencsw.org Sun Dec 20 13:32:58 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 20 Dec 2009 07:32:58 -0500 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: <6af4270912200352pee36f58ge14b8a8ee183f907@mail.gmail.com> References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> <6af4270912200352pee36f58ge14b8a8ee183f907@mail.gmail.com> Message-ID: <1261312324-sup-3751@ntdws12.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sun Dec 20 06:52:24 -0500 2009: > /etc ? is this a bug in the subversion configure description or > implementation, or gar does something? I'd suspect subversion's configure here. You should be able to see what it's doing in config.log -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 rupert at opencsw.org Sun Dec 20 14:42:47 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 14:42:47 +0100 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: <1261312324-sup-3751@ntdws12.chass.utoronto.ca> References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> <6af4270912200352pee36f58ge14b8a8ee183f907@mail.gmail.com> <1261312324-sup-3751@ntdws12.chass.utoronto.ca> Message-ID: <6af4270912200542u1313eebav882a32669c2fcf52@mail.gmail.com> On Sun, Dec 20, 2009 at 13:32, Ben Walton wrote: > Excerpts from rupert THURNER's message of Sun Dec 20 06:52:24 -0500 2009: > > > /etc ? is this a bug in the subversion configure description or > > implementation, or gar does something? > > I'd suspect subversion's configure here. You should be able to see > what it's doing in config.log > > config.log says: prefix='/opt/csw' sysconfdir='/opt/csw/etc' but i cannot find sysconfdir in the code. so i guess i do not understand something here. grepping for servers and etc is returning too many files so i am not sure rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Sun Dec 20 17:04:40 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 20 Dec 2009 17:04:40 +0100 Subject: [csw-maintainers] [csw-buildfarm] Out of swap space on build8x In-Reply-To: <4B2E4873.6040003@opencsw.org> References: <4B2E4873.6040003@opencsw.org> Message-ID: Hi Roger, Am 20.12.2009 um 16:53 schrieb Roger H?kansson: > I keep getting "ube: error: Cannot exec '/opt/studio/SOS11/SUNWspro/prod/bin/fbe' : Not enough space" on build8x and there isn't that much free swap space left. > Maybe someone could move /tmp/mbuffer-20091122 and /tmp/doxygen-apptrace out of the way so 400+MB would become free Done. To other maintainers: - Please use your homedirectory for specific stuff. As ZIL flushing is turned off it is as fast as writing to /tmp. - There is now also current8x/9x/10x. Please give them a try. Bets regards -- Dago From rupert at opencsw.org Sun Dec 20 17:48:40 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 17:48:40 +0100 Subject: [csw-maintainers] rebuild kde? In-Reply-To: <6af4270912200845i2206834dmc3cf1dab710f034d@mail.gmail.com> References: <6af4270912200845i2206834dmc3cf1dab710f034d@mail.gmail.com> Message-ID: <6af4270912200848h7ef0188sbeae96ba42e8967b@mail.gmail.com> would it be possible to rebuild kde? i tried to just rebuild kdesdk because of http://www.opencsw.org/bugtrack/view.php?id=3792 - but somehow it seems all kde needs to be built at once and i could not figure out what to start. rupert. From rupert at opencsw.org Sun Dec 20 17:50:11 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 17:50:11 +0100 Subject: [csw-maintainers] [csw-buildfarm] Out of swap space on build8x In-Reply-To: References: <4B2E4873.6040003@opencsw.org> Message-ID: <6af4270912200850t62e83493x31470f814d254646@mail.gmail.com> On Sun, Dec 20, 2009 at 17:04, Dagobert Michelsen wrote: > Hi Roger, > > Am 20.12.2009 um 16:53 schrieb Roger H?kansson: >> I keep getting "ube: error: Cannot exec '/opt/studio/SOS11/SUNWspro/prod/bin/fbe' : Not enough space" on build8x and there isn't that much free swap space left. >> Maybe someone could move /tmp/mbuffer-20091122 and /tmp/doxygen-apptrace out of the way so 400+MB would become free > > Done. To other maintainers: > - Please use your homedirectory for specific stuff. As ZIL flushing > ?is turned off it is as fast as writing to /tmp. > - There is now also current8x/9x/10x. Please give them a try. > rupert at current8x:~ $ PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" rupert at current8x:~ $ echo $PARALLELMFLAGS -l -j 1 is there only one thread, or did the way of querying it change? From skayser at opencsw.org Sun Dec 20 17:55:38 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 20 Dec 2009 17:55:38 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> Message-ID: <4B2E570A.3080708@opencsw.org> Hi Rupert, rupert THURNER wrote on 20.12.2009 02:39: > while trying to upgrade apache2 i thought it uses the apr package are you sure that this is the case, i.e. apache2 using a standalone apr runtime package? I just had a brief look and couldn't find a released apr package in our catalog. Doesn't apache2 ship with a bundled apr? > ... and so > i tried to upgrade this as well, and it gives an error while testing: > > ... > testsockets : FAILED 1 of 7 > ... > Failed Tests Total Fail Failed % > =================================================== > testsockets 7 1 14.29% > > gmake[1]: *** > [test-work/solaris8-sparc/build-isa-sparcv8/apr-1.3.9/Makefile] Error 2 > gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' > gmake: *** [merge-isa-sparcv8] Error 2 > > was this always like this or it is new? Presuming there are some sort of test logfiles, have a look in there so that you know what exactly fails. Maybe it's just IPv6 tests (the build boxes are not yet configure for IPv6). Sebastian From dam at opencsw.org Sun Dec 20 17:57:11 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 20 Dec 2009 17:57:11 +0100 Subject: [csw-maintainers] rebuild kde? In-Reply-To: <6af4270912200848h7ef0188sbeae96ba42e8967b@mail.gmail.com> References: <6af4270912200845i2206834dmc3cf1dab710f034d@mail.gmail.com> <6af4270912200848h7ef0188sbeae96ba42e8967b@mail.gmail.com> Message-ID: <2B41EBA1-A944-4D7D-9304-3A126B5D167D@opencsw.org> Hi Rupert, Am 20.12.2009 um 17:48 schrieb rupert THURNER : > would it be possible to rebuild kde? i tried to just rebuild kdesdk > because of http://www.opencsw.org/bugtrack/view.php?id=3792 - but > somehow it seems all kde needs to be built at once and i could not > figure out what to start. Just add the libs. Rebuilding KDE is a major task. Best regards -- Dago From dam at opencsw.org Sun Dec 20 18:02:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 20 Dec 2009 18:02:28 +0100 Subject: [csw-maintainers] [csw-buildfarm] Out of swap space on build8x In-Reply-To: <6af4270912200850t62e83493x31470f814d254646@mail.gmail.com> References: <4B2E4873.6040003@opencsw.org> <6af4270912200850t62e83493x31470f814d254646@mail.gmail.com> Message-ID: Hi Rupert, Am 20.12.2009 um 17:50 schrieb rupert THURNER : > On Sun, Dec 20, 2009 at 17:04, Dagobert Michelsen > wrote: >> Hi Roger, >> >> Am 20.12.2009 um 16:53 schrieb Roger H?kansson: >>> I keep getting "ube: error: Cannot exec '/opt/studio/SOS11/ >>> SUNWspro/prod/bin/fbe' : Not enough space" on build8x and there >>> isn't that much free swap space left. >>> Maybe someone could move /tmp/mbuffer-20091122 and /tmp/doxygen- >>> apptrace out of the way so 400+MB would become free >> >> Done. To other maintainers: >> - Please use your homedirectory for specific stuff. As ZIL flushing >> is turned off it is as fast as writing to /tmp. >> - There is now also current8x/9x/10x. Please give them a try. >> > > rupert at current8x:~ > $ PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" > > rupert at current8x:~ > $ echo $PARALLELMFLAGS > -l -j 1 > > is there only one thread, or did the way of querying it change? There is only one thread. Build8x is a VM on VMware workstation on Linux where current8x is a vSphere 4 VM, which has experimental support for Solaris 8 which ESX 3.5 didn't have. Unfortunately the idle detection doesn't work with #CPU > 1 on this environment where it does work on workstation. As I want to turn some boxes off I can offer to add current8x2, but that won't speed up your single build. Best regards -- Dago From skayser at opencsw.org Sun Dec 20 18:06:21 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 20 Dec 2009 18:06:21 +0100 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> Message-ID: <4B2E598D.5000806@opencsw.org> rupert THURNER wrote on 20.12.2009 05:40: > dagobert filed a subversion bug saying the config file should go in a > different place: > > The configuration for the svn commandline-client is at > /etc/subversion/servers > instead of > /etc/opt/csw/subversion/servers > > isn't this a standard configuration option and gar should do this? In theory you are right and GAR should pre-set --sysconfdir to /etc/opt/csw (currently it is /opt/csw/etc). Nevertheless, AFAIR this was considered a major change, possibly breaking existing build descriptions. Thus, it was decided to leave it to the maintainer to change his build descriptions. > an > excerpt from the subversion configure is below: > > rupert at build8s: ... build-isa-sparcv8/subversion-1.6.6 > $ ./configure --help > `configure' configures subversion 1.6.6 to adapt to many kinds of systems. > ... > an installation prefix other than `/usr/local' using `--prefix', > for instance `--prefix=$HOME'. > > For better control, use the options below. > > Fine tuning of the installation directories: > .... > --sysconfdir=DIR read-only single-machine data [PREFIX/etc] > ... While sysconfdir defaults to $prefix/etc it is perfectly fine to adjust it when required. Simply add sysconfdir = /etc/opt/csw to your Makefile. Have a look at the orca Makefile [1] for an example. Sebastian [1] https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/orca/trunk/Makefile From skayser at opencsw.org Sun Dec 20 18:09:57 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 20 Dec 2009 18:09:57 +0100 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: <4B2E598D.5000806@opencsw.org> References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> <4B2E598D.5000806@opencsw.org> Message-ID: <4B2E5A65.4070805@opencsw.org> Sebastian Kayser wrote on 20.12.2009 18:06: > rupert THURNER wrote on 20.12.2009 05:40: >> dagobert filed a subversion bug saying the config file should go in a >> different place: >> >> The configuration for the svn commandline-client is at >> /etc/subversion/servers >> instead of >> /etc/opt/csw/subversion/servers >> >> isn't this a standard configuration option and gar should do this? > > In theory you are right and GAR should pre-set --sysconfdir to > /etc/opt/csw (currently it is /opt/csw/etc). Nevertheless, AFAIR this > was considered a major change, possibly breaking existing build > descriptions. Thus, it was decided to leave it to the maintainer to > change his build descriptions. As a related question. Dago, is there a target similar to "modev" or "ccenv" which displays the default ./configure args? Sebastian From skayser at opencsw.org Sun Dec 20 18:17:16 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 20 Dec 2009 18:17:16 +0100 Subject: [csw-maintainers] [csw-buildfarm] Out of swap space on build8x In-Reply-To: References: <4B2E4873.6040003@opencsw.org> <6af4270912200850t62e83493x31470f814d254646@mail.gmail.com> Message-ID: <4B2E5C1C.3010802@opencsw.org> Dagobert Michelsen wrote on 20.12.2009 18:02: > There is only one thread. Build8x is a VM on VMware workstation on > Linux where current8x is a vSphere 4 VM, which has experimental > support for Solaris 8 which ESX 3.5 didn't have. Unfortunately the > idle detection doesn't work with #CPU > 1 on this environment where it > does work on workstation. Interesting. Do you have a KB or release notes reference for this? Sebastian From dam at opencsw.org Sun Dec 20 18:22:09 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 20 Dec 2009 18:22:09 +0100 Subject: [csw-maintainers] [csw-buildfarm] Out of swap space on build8x In-Reply-To: <4B2E5C1C.3010802@opencsw.org> References: <4B2E4873.6040003@opencsw.org> <6af4270912200850t62e83493x31470f814d254646@mail.gmail.com> <4B2E5C1C.3010802@opencsw.org> Message-ID: Hi Sebastian, Am 20.12.2009 um 18:17 schrieb Sebastian Kayser : > Dagobert Michelsen wrote on 20.12.2009 18:02: >> There is only one thread. Build8x is a VM on VMware workstation on >> Linux where current8x is a vSphere 4 VM, which has experimental >> support for Solaris 8 which ESX 3.5 didn't have. Unfortunately the >> idle detection doesn't work with #CPU > 1 on this environment where >> it >> does work on workstation. > > Interesting. Do you have a KB or release notes reference for this? No, that is just my observation and as Solaris 8 support is marked experimental I can't open a bug report. Best regards -- Dago From rupert at opencsw.org Sun Dec 20 18:25:03 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 18:25:03 +0100 Subject: [csw-maintainers] subversion sysconfdir='/opt/csw/etc' - servers file anyway created in /etc/ ? Message-ID: <6af4270912200925lc81f6dex455386c4e730b8a@mail.gmail.com> fyi. ---------- Forwarded message ---------- From: Branko ?ibej Date: Sun, Dec 20, 2009 at 18:16 Subject: Re: sysconfdir='/opt/csw/etc' - servers file anyway created in /etc/ ? To: "rupert.thurner" Cc: dev at subversion.apache.org rupert.thurner wrote: > while compiling subversion-1.6.6 for http://opencsw.org we noticed > that the servers file is created in the /etc directory, even if > configure.log shows the sysconfdir is /opt/csw/etc, and the prefix is / > opt/csw. where in the code do you expect to configure this directory? > Oh my ... it's hardcoded in subversion/libsvh_subr/config_impl.h. Some build system twiddling will be necessary to fix that. -- Brane From dam at opencsw.org Sun Dec 20 20:54:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 20 Dec 2009 20:54:45 +0100 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: <4B2E5A65.4070805@opencsw.org> References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> <4B2E598D.5000806@opencsw.org> <4B2E5A65.4070805@opencsw.org> Message-ID: Hi Sebastian, Am 20.12.2009 um 18:09 schrieb Sebastian Kayser: > Sebastian Kayser wrote on 20.12.2009 18:06: >> rupert THURNER wrote on 20.12.2009 05:40: >>> dagobert filed a subversion bug saying the config file should go >>> in a >>> different place: >>> >>> The configuration for the svn commandline-client is at >>> /etc/subversion/servers >>> instead of >>> /etc/opt/csw/subversion/servers >>> >>> isn't this a standard configuration option and gar should do this? >> >> In theory you are right and GAR should pre-set --sysconfdir to >> /etc/opt/csw (currently it is /opt/csw/etc). Nevertheless, AFAIR this >> was considered a major change, possibly breaking existing build >> descriptions. Thus, it was decided to leave it to the maintainer to >> change his build descriptions. > > As a related question. Dago, is there a target similar to "modev" or > "ccenv" which displays the default ./configure args? Unfortunately not. Care to add it? Best regards -- Dago From dam at opencsw.org Sun Dec 20 20:55:23 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 20 Dec 2009 20:55:23 +0100 Subject: [csw-maintainers] subversion sysconfdir='/opt/csw/etc' - servers file anyway created in /etc/ ? In-Reply-To: <6af4270912200925lc81f6dex455386c4e730b8a@mail.gmail.com> References: <6af4270912200925lc81f6dex455386c4e730b8a@mail.gmail.com> Message-ID: <6E823751-C36A-4E91-87FA-F9751ED8D9F8@opencsw.org> Hi Rupert, Am 20.12.2009 um 18:25 schrieb rupert THURNER: > fyi. Thanks. Did you open a bug report upstream? Would they accept a bug report? Best regards -- Dago > > > ---------- Forwarded message ---------- > From: Branko ?ibej > Date: Sun, Dec 20, 2009 at 18:16 > Subject: Re: sysconfdir='/opt/csw/etc' - servers file anyway created > in /etc/ ? > To: "rupert.thurner" > Cc: dev at subversion.apache.org > > > rupert.thurner wrote: >> while compiling subversion-1.6.6 for http://opencsw.org we noticed >> that the servers file is created in the /etc directory, even if >> configure.log shows the sysconfdir is /opt/csw/etc, and the prefix >> is / >> opt/csw. where in the code do you expect to configure this directory? >> > Oh my ... it's hardcoded in subversion/libsvh_subr/config_impl.h. Some > build system twiddling will be necessary to fix that. > > -- Brane > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers From rupert at opencsw.org Sun Dec 20 21:33:35 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 21:33:35 +0100 Subject: [csw-maintainers] subversion sysconfdir='/opt/csw/etc' - servers file anyway created in /etc/ ? In-Reply-To: <6E823751-C36A-4E91-87FA-F9751ED8D9F8@opencsw.org> References: <6af4270912200925lc81f6dex455386c4e730b8a@mail.gmail.com> <6E823751-C36A-4E91-87FA-F9751ED8D9F8@opencsw.org> Message-ID: <6af4270912201233g3e083175j4651738189b1cf0b@mail.gmail.com> On Sun, Dec 20, 2009 at 20:55, Dagobert Michelsen wrote: > Hi Rupert, > > Am 20.12.2009 um 18:25 schrieb rupert THURNER: >> >> fyi. > > Thanks. Did you open a bug report upstream? Would they accept a bug > report? no, i did not. in former tigris times somebody asked to open a bug report. but i am unsure how apache this now, so i thought maybe wait a little what happens. i patched it in opencsw for the moment. rupert. >> ---------- Forwarded message ---------- >> From: Branko ?ibej >> Date: Sun, Dec 20, 2009 at 18:16 >> Subject: Re: sysconfdir='/opt/csw/etc' - servers file anyway created in >> /etc/ ? >> To: "rupert.thurner" >> Cc: dev at subversion.apache.org >> >> >> rupert.thurner wrote: >>> >>> while compiling subversion-1.6.6 for http://opencsw.org we noticed >>> that the servers file is created in the /etc directory, even if >>> configure.log shows the sysconfdir is /opt/csw/etc, and the prefix is / >>> opt/csw. where in the code do you expect to configure this directory? >>> >> Oh my ... it's hardcoded in subversion/libsvh_subr/config_impl.h. Some >> build system twiddling will be necessary to fix that. >> >> -- Brane >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers From rupert at opencsw.org Mon Dec 21 11:59:22 2009 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 21 Dec 2009 11:59:22 +0100 Subject: [csw-maintainers] debug output - all variables Message-ID: <6af4270912210259n23144253pbf65dfc692626721@mail.gmail.com> hi, is there a possibility to display all the defined variables for a debug output? i find it particularly difficult to see through all the variables used in the subversion makefile. just to give you some randomly picked out examples which finally makes then libsvn_ra_dav go into /opt/csw/lib instead of /opt/csw/lib/svn. $(libdir) $(SVNLIB) $(DESTDIR) $(prefix) $(WORKDIR) SVNLIB = $(prefix)/lib/svn CONFIGURE_ARGS = $(DIRPATHS) --libdir=$(SVNLIB) --libexecdir=$(SVNLIB) fix-ra_dav: @# libsvn_ra_dav-1* has been renamed to libsvn_ra_neon-1* @# in the new versions of subversion, @# we need to link for backward compatability @(gln -s $(DESTDIR)$(libdir)/libsvn_ra_neon-1.so.0.0.0 \ $(DESTDIR)$(libdir)/libsvn_ra_dav-1.so.0) @(gln -s $(DESTDIR)$(libdir)/libsvn_ra_neon-1.so.0.0.0 \ $(DESTDIR)$(libdir)/libsvn_ra_dav-1.so) @$(MAKECOOKIE) other usages include: @(grm -fr $(DESTDIR)$(prefix)/lib/perl/5.8.8) i tried "gmake -d" but the output is enourmous - and i could not see the variables. rupert. ---------- Forwarded message ---------- From: Mantis Bug Tracker Date: Mon, Dec 21, 2009 at 10:12 Subject: [subversion 0003792]: libsvn_fs_base-1.so.0 and libsvn_ra_dav-1.so.0 missing To: rupert at opencsw.org A NOTE has been added to this issue. ====================================================================== http://www.opencsw.org/bugtrack/view.php?id=3792 ====================================================================== Reported By: ? ? ? ? ? ? ? ?james Assigned To: ====================================================================== Project: ? ? ? ? ? ? ? ? ? ?subversion Issue ID: ? ? ? ? ? ? ? ? ? 3792 Category: ? ? ? ? ? ? ? ? ? packaging Reproducibility: ? ? ? ? ? ?sometimes Severity: ? ? ? ? ? ? ? ? ? crash Priority: ? ? ? ? ? ? ? ? ? normal Status: ? ? ? ? ? ? ? ? ? ? feedback ====================================================================== Date Submitted: ? ? ? ? ? ? 2009-07-30 16:52 CEST Last Modified: ? ? ? ? ? ? ?2009-12-21 10:12 CET ====================================================================== Summary: ? ? ? ? ? ? ? ? ? ?libsvn_fs_base-1.so.0 and libsvn_ra_dav-1.so.0 missing Description: Previouly svn included libsvn_fs_base-1.so.0 and libsvn_ra_dav-1.so.0. These are no longer in svn but stil needed by 2 dependants. ?Suggest svn packs the old files until the dependants are rebuilt, if that is not possible please expedite the rebuild of the depends. ====================================================================== ---------------------------------------------------------------------- ?(0007114) james (reporter) - 2009-12-21 10:12 ?http://www.opencsw.org/bugtrack/view.php?id=3792#c7114 ---------------------------------------------------------------------- With ldd. If you have fixed this please say so. "please address this to CSWkdesdk and CSWkdevelop if it is still valid." says to me "This is not fixed in SVN, the depends will have to be fixed if they are not fixed already". ?Sorry if that is not the correct interpretation of your words, please qualify what you have done. From dam at opencsw.org Mon Dec 21 13:12:39 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 21 Dec 2009 13:12:39 +0100 Subject: [csw-maintainers] debug output - all variables In-Reply-To: <6af4270912210259n23144253pbf65dfc692626721@mail.gmail.com> References: <6af4270912210259n23144253pbf65dfc692626721@mail.gmail.com> Message-ID: <69CF9F9A-C9C7-4A54-BCDD-BE3BB368DCDF@opencsw.org> Hi Rupert, Am 21.12.2009 um 11:59 schrieb rupert THURNER: > is there a possibility to display all the defined variables for a > debug output? No, you can only output specific variables where the names of the variables must be known. > i find it particularly difficult to see through all the > variables used in the subversion makefile. just to give you some > randomly picked out examples which finally makes then libsvn_ra_dav go > into /opt/csw/lib instead of /opt/csw/lib/svn. > > $(libdir) > $(SVNLIB) > $(DESTDIR) > $(prefix) > $(WORKDIR) Ok, so you want to print out basically the values for the variables in gar.conf.mk or the GAR variable reference, right? > SVNLIB = $(prefix)/lib/svn > > CONFIGURE_ARGS = $(DIRPATHS) --libdir=$(SVNLIB) --libexecdir=$ > (SVNLIB) > > fix-ra_dav: > @# libsvn_ra_dav-1* has been renamed to libsvn_ra_neon-1* > @# in the new versions of subversion, > @# we need to link for backward compatability > @(gln -s $(DESTDIR)$(libdir)/libsvn_ra_neon-1.so.0.0.0 \ > $(DESTDIR)$(libdir)/libsvn_ra_dav-1.so.0) > @(gln -s $(DESTDIR)$(libdir)/libsvn_ra_neon-1.so.0.0.0 \ > $(DESTDIR)$(libdir)/libsvn_ra_dav-1.so) > @$(MAKECOOKIE) This does not work as you don't change the libdir variable. You could do libdir_install = $(prefix)/lib/svn > other usages include: > @(grm -fr $(DESTDIR)$(prefix)/lib/perl/5.8.8) > > i tried "gmake -d" but the output is enourmous - and i could not see > the variables. That does not work, right. I am currently looking at the GNU make debugger "remake" if it would help. Best regards -- Dago From skayser at opencsw.org Mon Dec 21 13:18:49 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 21 Dec 2009 13:18:49 +0100 Subject: [csw-maintainers] debug output - all variables In-Reply-To: <69CF9F9A-C9C7-4A54-BCDD-BE3BB368DCDF@opencsw.org> References: <6af4270912210259n23144253pbf65dfc692626721@mail.gmail.com> <69CF9F9A-C9C7-4A54-BCDD-BE3BB368DCDF@opencsw.org> Message-ID: <20091221121849.GG7667@sebastiankayser.de> * Dagobert Michelsen wrote: > Am 21.12.2009 um 11:59 schrieb rupert THURNER: > >is there a possibility to display all the defined variables for a > >debug output? > > No, you can only output specific variables where the names of the > variables > must be known. > > >i find it particularly difficult to see through all the > >variables used in the subversion makefile. just to give you some > >randomly picked out examples which finally makes then libsvn_ra_dav go > >into /opt/csw/lib instead of /opt/csw/lib/svn. > > > >$(libdir) > >$(SVNLIB) > >$(DESTDIR) > >$(prefix) > >$(WORKDIR) > > Ok, so you want to print out basically the values for the variables in > gar.conf.mk > or the GAR variable reference, right? > > >SVNLIB = $(prefix)/lib/svn > > > >CONFIGURE_ARGS = $(DIRPATHS) --libdir=$(SVNLIB) --libexecdir=$ > >(SVNLIB) > > > >fix-ra_dav: > > @# libsvn_ra_dav-1* has been renamed to libsvn_ra_neon-1* > > @# in the new versions of subversion, > > @# we need to link for backward compatability > > @(gln -s $(DESTDIR)$(libdir)/libsvn_ra_neon-1.so.0.0.0 \ > > $(DESTDIR)$(libdir)/libsvn_ra_dav-1.so.0) > > @(gln -s $(DESTDIR)$(libdir)/libsvn_ra_neon-1.so.0.0.0 \ > > $(DESTDIR)$(libdir)/libsvn_ra_dav-1.so) > > @$(MAKECOOKIE) > > This does not work as you don't change the libdir variable. You could do > libdir_install = $(prefix)/lib/svn It doesn't really answer your question, but as a general rule of thumb: what I found to be helpful (not only when it comes to debugging) is to just drop the @ signs in front of the command lines. This way, you can at least see right away how variables expand when each command is called. Nowadays, I only leave the @ in front of $(MAKECOOKIE). Sebastian From maciej at opencsw.org Mon Dec 21 15:03:14 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 21 Dec 2009 14:03:14 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: I've worked on this program some more. I'm working on incorporating the subversion commit messages. The idea is to include all commit messages since the previous version of the package was released. Here's an example of a larger submission. It's generated with some hand-added content. * new package: pius * It's a small application to assist with tedious GPG key signing. - commit messages: - 'Added archall and a build dep Python' - 'initial commit' + bender:/home/newpkgs/pius-2.0.3,REV=2009.11.29-SunOS5.8-all-CSW.pkg.gz * pysvn: minor version upgrade * replaces the old subversion bindings with the pysvn project files. - commit messages: - 'using CSWbash, disabling tests on Solaris 8 due to lack of UTF-8 locale support' - 'Removed template comments from the Makefile, added blurb' - 'Initial commit' - from: 1.6.2,REV=2009.06.13 - to: 1.7.1,REV=2009.12.17 + bender:/home/newpkgs/pysvn-1.7.1,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/pysvn-1.7.1,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz * python: patchlevel upgrade * Patched it to fix the getpass() issue. - commit messages: - 'Adding the patch from http://bugs.python.org/issue7208' - 'Upgrading to 2.6.4, removing content from CSWpython-rt with the intention to kill it, moving the distutils module to CSWpython, moving smtpd.py to the -devel package.' - from: 2.6.2,REV=2009.05.28 - to: 2.6.4,REV=2009.12.17 + bender:/home/newpkgs/python-2.6.4,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/python-2.6.4,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/python_devel-2.6.4,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/python_devel-2.6.4,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/python_rt-2.6.4,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/python_rt-2.6.4,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/python_tk-2.6.4,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/python_tk-2.6.4,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/idle-2.6.4,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/idle-2.6.4,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz * new package: python_test * Since the install target installs those files, the upstream presumably wants it to be installable. + bender:/home/newpkgs/python_test-2.6.4,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/python_test-2.6.4,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz * mysql5: patchlevel upgrade * First release with the source-controlled build. - commit messages - 'mysql-5.0.x: Using post-install instead of post-install-modulated' - 'mysql5: 5.0 version bump up to 5.0.87' - 'mysql-5.0.x: Added CSWperl as a dependency for CSWmysql5devel' - 'mysql5-5.0.x: Fixing a problem with the runtime library path.' - 'mysql5-5.0.x: Adjusting the quick start file, adjusting the startup script, shuffling files around the packages (mysql_config in mysql5devel), adding symlinks from /opt/csw/include/mysql and /opt/csw/lib/mysql' - dmichelsen 'mysql-5.0.x: Tweak Makefile' - 'mysql-5.0.x: Fixed runtime library paths, fixed the quickstart file, added a postinstall file.' - 'mysql5: Fixing the cswusergroup path (changing to /etc/opt/csw)' - 'mysql5: Runtime libraries can live together with mysql4.' - 'mysql5: cswusergroup must be listed as well' - 'mysql5: Defined incompatible packages, set runtime dependencies, set the ownership of /var/opt/csw/mysql directory, added a preinstall script with a warning.' - 'mysql5: Better prototypes for mysql5 subpackages.' - 'mysql5: First iteration of slicing it into separate packages. Things left to do: Creating mysql user and group, pre/post install/remove scripts, a check if MySQL database exists' - 'mysql5: Copying mysql-5.1 to branches/mysql-5.0.x\n' - from: 5.0.51,REV=2008.01.20 - to: 5.0.87,REV=2009.11.13 + bender:/home/newpkgs/mysql5-5.0.87,REV=2009.11.13-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/mysql5-5.0.87,REV=2009.11.13-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/mysql5devel-5.0.87,REV=2009.11.13-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/mysql5devel-5.0.87,REV=2009.11.13-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/mysql5rt-5.0.87,REV=2009.11.13-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/mysql5rt-5.0.87,REV=2009.11.13-SunOS5.8-sparc-CSW.pkg.gz - from: 5.0.51,REV=2007.12.19 - to: 5.0.87,REV=2009.11.13 + bender:/home/newpkgs/mysql5bench-5.0.87,REV=2009.11.13-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/mysql5bench-5.0.87,REV=2009.11.13-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/mysql5client-5.0.87,REV=2009.11.13-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/mysql5client-5.0.87,REV=2009.11.13-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/mysql5test-5.0.87,REV=2009.11.13-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/mysql5test-5.0.87,REV=2009.11.13-SunOS5.8-sparc-CSW.pkg.gz -- $Id: opencsw.py 111 2009-12-17 10:59:16Z $ To use it for your package submissions, you can run submitpkg on the login host as follows: svn co https://opencsw.svn.sourceforge.net/svnroot/opencsw/utilities cd utilities ./submit_to_newpkgs.py -h ls -l /home/testing | grep ${LOGNAME} ./submit_to_newpkgs.py -p catalogname1,catalogname2,... Maciej From maciej at opencsw.org Mon Dec 21 16:00:24 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 21 Dec 2009 15:00:24 +0000 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: Message-ID: I can't run cssh with perl from testing: $ cssh ld.so.1: perl: fatal: relocation error: file /opt/csw/lib/perl/csw/auto/Tk/Event /Event.so: symbol Perl_Tstack_sp_ptr: referenced symbol not found Killed This is on Solaris 10 x86. Has anyone else observed it? Maciej From dam at opencsw.org Mon Dec 21 16:11:09 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 21 Dec 2009 16:11:09 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: Message-ID: Hi Maciej, Am 21.12.2009 um 16:00 schrieb Maciej (Matchek) Blizinski: > I can't run cssh with perl from testing: > > $ cssh > ld.so.1: perl: fatal: relocation error: file > /opt/csw/lib/perl/csw/auto/Tk/Event /Event.so: symbol > Perl_Tstack_sp_ptr: referenced symbol not found > Killed > > This is on Solaris 10 x86. > > Has anyone else observed it? Yes. Cited from [1]: "As far as I saw in the source of perl 5.8.8 and 5.10.0 there is a renaming of all Symbols from Perl_T... to Perl_I, in this case in 5.10.0 it's called Perl_Istack_sp_Ptr." It looks like that this one is something we must just accept and rebuild all failing packages. Gary, I installed Perl 5.10.1 on build8st, would you mind giving clusterssh a try against the updated Perl? Best regards -- Dago [1] http://forum.parallels.com/showthread.php?p=343647#post343647 From maciej at opencsw.org Mon Dec 21 16:16:12 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 21 Dec 2009 15:16:12 +0000 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: Message-ID: On Mon, Dec 21, 2009 at 3:11 PM, Dagobert Michelsen wrote: > Gary, I installed Perl 5.10.1 on build8st, would you mind giving clusterssh > a try against the updated Perl? It's not that, at least in this case. clusterssh doesn't contain any shared objects, the package consists only of a perl script and a man page: http://www.opencsw.org/search/clusterssh From skayser at opencsw.org Mon Dec 21 16:20:01 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 21 Dec 2009 16:20:01 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: Message-ID: <20091221152001.GH7667@sebastiankayser.de> * Maciej (Matchek) Blizinski wrote: > On Mon, Dec 21, 2009 at 3:11 PM, Dagobert Michelsen wrote: > > Gary, I installed Perl 5.10.1 on build8st, would you mind giving clusterssh > > a try against the updated Perl? > > It's not that, at least in this case. clusterssh doesn't contain any > shared objects, the package consists only of a perl script and a man > page: > > http://www.opencsw.org/search/clusterssh It relies on pm_tk which in turn is compiled against the previous perl version. We should set up some automated way of re-building all perl modules with shared objects files against the new perl. Sebastian From dam at opencsw.org Mon Dec 21 16:23:14 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 21 Dec 2009 16:23:14 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: Message-ID: <61C77CC1-FA40-4386-8210-602A52B63494@opencsw.org> Hi Maciej, Am 21.12.2009 um 16:16 schrieb Maciej (Matchek) Blizinski: > On Mon, Dec 21, 2009 at 3:11 PM, Dagobert Michelsen > wrote: >> Gary, I installed Perl 5.10.1 on build8st, would you mind giving >> clusterssh >> a try against the updated Perl? > > It's not that, at least in this case. clusterssh doesn't contain any > shared objects, the package consists only of a perl script and a man > page: > > http://www.opencsw.org/search/clusterssh Umh, your right. Gary, sorry to have woken you ;-) No, wait: clusterssh has NO dependencies defined. This is obviously wrong. Looks like there are already bugs reported about this, though: http://www.opencsw.org/mantis/set_project.php?project_id=1661 Looks like it is pm_tk: > ld.so.1: perl: fatal: relocation error: file /opt/csw/lib/perl/csw/ > auto/Tk/Event/Event.so: symbol Perl_Tstack_sp_ptr: referenced symbol > not found > zsh: killed cssh > build8st% grep /opt/csw/lib/perl/csw/auto/Tk/Event/Event.so /var/ > sadm/install/contents > /opt/csw/lib/perl/csw/auto/Tk/Event/Event.so f none 0555 root bin > 114988 15756 1130401998 CSWpmtk This is maintained by Murray Jensen, who is unfortunately not fluent in GAR yet. Murray: Would you mind giving it a look with Perl 5.10.1 from testing/ anyway? Best regards -- Dago From dam at opencsw.org Mon Dec 21 16:26:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 21 Dec 2009 16:26:31 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: <20091221152001.GH7667@sebastiankayser.de> References: <20091221152001.GH7667@sebastiankayser.de> Message-ID: <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> Hi Sebastian, Am 21.12.2009 um 16:20 schrieb Sebastian Kayser: > * Maciej (Matchek) Blizinski wrote: >> On Mon, Dec 21, 2009 at 3:11 PM, Dagobert Michelsen >> wrote: >>> Gary, I installed Perl 5.10.1 on build8st, would you mind giving >>> clusterssh >>> a try against the updated Perl? >> >> It's not that, at least in this case. clusterssh doesn't contain any >> shared objects, the package consists only of a perl script and a man >> page: >> >> http://www.opencsw.org/search/clusterssh > > It relies on pm_tk which in turn is compiled against the previous perl > version. We should set up some automated way of re-building all perl > modules with shared objects files against the new perl. The easiest way would be to update cpan2pkg from CSWcswutils to output GAR Makefile and then mass-update the modules. I won't have much time over christmas as I won a Live Upgrade migration from U6 UFS to U8 ZFS for an 8-machine Sun Ray cluster which will suck up most of my "spare" time... Sebastian, would you mind giving it a look? Best regards -- Dago From bwalton at opencsw.org Mon Dec 21 16:38:55 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 21 Dec 2009 10:38:55 -0500 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: <1261312122-sup-4951@ntdws12.chass.utoronto.ca> References: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> <1261312122-sup-4951@ntdws12.chass.utoronto.ca> Message-ID: <1261409593-sup-7603@ntdws12.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Dec 20 07:30:59 -0500 2009: Hi Maciej, > The scripts should be expanded into $(DOWNLOADDIR) during the extract > stage. I realized yesterday after I'd left the house that this was incorrect. I'd meant to type 'during the fetch' stage. It is expanded as it's placed in $(DOWNLOADDIR), at the same point where the source tarballs, etc are retrieved. Sorry about the typo. -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. From glaw at blastwave.org Wed Dec 2 11:51:51 2009 From: glaw at blastwave.org (Gary Law) Date: Wed, 02 Dec 2009 10:51:51 -0000 Subject: [csw-maintainers] CSWcswclassutils wants to write in /usr Message-ID: Hi all Been chatting with Maciej about a bug/feature I've hit where I can't properly install CSWcswclassutils, as it wants to write in /usr, and that's mounted readonly (it's a non-global zone). Does this mean CSWcswclassutils violates policy? I thought we had to confine ourselves to /opt, /etc/opt/csw and /var/opt/csw Maciej suggested non-global zones and/or non-writable /usr aren't supported by CSW, which may be correct, but is news to me. Thoughts? Gary From blizinski at google.com Mon Dec 21 15:50:06 2009 From: blizinski at google.com (Maciej (Matchek) Blizinski) Date: Mon, 21 Dec 2009 14:50:06 +0000 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh Message-ID: I can't run cssh with perl from testing: $ cssh ld.so.1: perl: fatal: relocation error: file /opt/csw/lib/perl/csw/auto/Tk/Event /Event.so: symbol Perl_Tstack_sp_ptr: referenced symbol not found Killed This is on Solaris 10 x86. Has anyone else observed it? Maciej From phil at bolthole.com Mon Dec 21 20:58:05 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Dec 2009 11:58:05 -0800 Subject: [csw-maintainers] rebuild kde? In-Reply-To: <2B41EBA1-A944-4D7D-9304-3A126B5D167D@opencsw.org> References: <6af4270912200845i2206834dmc3cf1dab710f034d@mail.gmail.com> <6af4270912200848h7ef0188sbeae96ba42e8967b@mail.gmail.com> <2B41EBA1-A944-4D7D-9304-3A126B5D167D@opencsw.org> Message-ID: On Sunday, December 20, 2009, Dagobert Michelsen wrote: > Hi Rupert, > > Just add the libs. Rebuilding KDE is a major task. > it is indeed a major task... that being said, it would be a very very good thing for opencsw if someone would take on this task From phil at bolthole.com Mon Dec 21 21:02:07 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Dec 2009 12:02:07 -0800 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: oh let's NOT include all svn messages please. too much information potentially From phil at bolthole.com Mon Dec 21 21:07:52 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Dec 2009 12:07:52 -0800 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: <4B2E570A.3080708@opencsw.org> References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> <4B2E570A.3080708@opencsw.org> Message-ID: btw as a reminder: while apache2 "can" use the bundled apr there are some benefits to having it use a standalone external package it would be a very nice thing if we had one, and in fact there was some package in recent months that needed one? From glaw at opencsw.org Mon Dec 21 22:27:02 2009 From: glaw at opencsw.org (Gary Law) Date: Mon, 21 Dec 2009 21:27:02 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <4B2BFD68.6090301@opencsw.org> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> Message-ID: All We seem to be stuck here with a choice, and to avoid lots of quoting I'll summarise: 1) Use CSWcswclassutils and stop those with read-only /usr using our packages; 2) Migrate away from CSWcswclassutils and build another mechanism that's similar. Primary problem with (1) is it rules out using CSW packages on a significant number of machines which have read-only /usr. I'd call that a major issue, a showstopper bug in the case of the package I'm trying to get into GAR. Primary problem with (2) is that we might end up having users have to answer 'yes' to postinstall script questions if they don't have the right sort of admin file set up. Minor issue IMHO. I'd say the benefits of fixing (1) massively outweigh the disbenefits of (2). Thoughts? Gary -- glaw at opencsw.org From maciej at opencsw.org Mon Dec 21 22:28:33 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 21 Dec 2009 21:28:33 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Dec 21, 2009 at 8:02 PM, Philip Brown wrote: > oh let's NOT include all svn messages please. > too much information potentially I'll first explain why I was thinking of including them. I'm aiming at automating all the bits that don't absolutely require human intervention. I assume that as the release manager, you would like to know what has changed since the last release. Compiling a list of commit messages can provide a nice chronological description of changes made to the package. In the future one might envision an automated system in which the maintainer doesn't write an e-mail, but simply states the decision "I want X to be submitted for release" and the rest pf the process, up to the point when the release candidate files are presented to the release manager, is automated. I think that the rest of the crew has a similar vision, please chime in. Since it's impossible to write such a system in one go, I'm working on small bits, and making the commit messages part of the process was one of the things I wanted to do. If you don't care about any sort of comments about the submitted files, we can skip over this functionality, no problem. It was my intuition that you'd want them. There could also be a different solution in which there would be an optional view with the details. E-mail is not suited for that, unfortunately. Perhaps there could be a generated link associated with each piece of software, showing the differences between the build files, such as: http://tinyurl.com/ygvbh7v (A side note: this would be build-system independent. The only requirement would be for the software in question to point at the URL from which it was built and provide the revision number.) What do you think? From maciej at opencsw.org Mon Dec 21 22:47:21 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 21 Dec 2009 21:47:21 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> Message-ID: On Mon, Dec 21, 2009 at 9:27 PM, Gary Law wrote: > All > > We seem to be stuck here with a choice, and to avoid lots of quoting > I'll summarise: > > 1) Use CSWcswclassutils and stop those with read-only /usr using our packages; > > 2) Migrate away from CSWcswclassutils and build another mechanism > that's similar. > > Primary problem with (1) is it rules out using CSW packages on a > significant number of machines which have read-only /usr. I'd call > that a major issue, a showstopper bug in the case of the package I'm > trying to get into GAR. Sad to hear that. > Primary problem with (2) is that we might end up having users have to > answer 'yes' to postinstall script questions if they don't have the > right sort of admin file set up. Minor issue IMHO. > > I'd say the benefits of fixing (1) massively outweigh the disbenefits > of (2). Thoughts? I agree on the point that answering 'yes' to the postinstall scripts is a minor issue. If one maintains numerous of Solaris machines, automated package installs are a must. Maciej From phil at bolthole.com Mon Dec 21 22:51:19 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Dec 2009 13:51:19 -0800 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: On Monday, December 21, 2009, Maciej (Matchek) Blizinski wrote: > On Mon, Dec 21, 2009 at 8:02 PM, Philip Brown wrote: >> oh let's NOT include all svn messages please. >> too much information potentially > > I'll first explain why I was thinking of including them. ?I'm aiming > at automating all the bits that don't absolutely require human > intervention. ?I assume that as the release manager, you would like to > know what has changed since the last release. as release manager, I might like t know if anythng IMPORTANT has changed. parsing all those entries is the antithesis of automaton. it requires detailed human scrutiny, if the maintained has been writng detailed change logs. perhaps it might be beneficial if the tool optionally displayed the logs to the mantainer only. then they can determine if there is anything important to pass on to the release manager? From phil at bolthole.com Mon Dec 21 23:05:28 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Dec 2009 14:05:28 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: <00611D04-93AA-423F-B656-EE6A512A9190@opencsw.org> References: <4B2C021B.50800@opencsw.org> <00611D04-93AA-423F-B656-EE6A512A9190@opencsw.org> Message-ID: >Or would you also argument to have > a "ll" (or "cswll") binary that is not at all a comperable argument. ls -l. is already short 2chars vs 4 Additionally, noone has yet addressed my concern about it being fully in the "dpkg" namespace. can we get a second party who is competant in perl, give the proposed code an audit please? (and I also think the name sucks. "update-alternatives"? it's very name describes it as an adjunct utility to a separate core software. that is to say, it is an add-on utility to tweak something already set by "the dpkg alternatives system". ie: it's for "updating" only oh hey I've found a command reference in REDHAT. interestingly, they have a manpage that I guess is an alias for "update-alternatives". but the true command is called "alternatives". now that seems more appropriate to me. how about that? (the name, AND possibly the choice of software?) From rupert at opencsw.org Tue Dec 22 00:04:19 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 22 Dec 2009 00:04:19 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> <4B2E570A.3080708@opencsw.org> Message-ID: <6af4270912211504r43f65310t86e00fa22570716e@mail.gmail.com> On Mon, Dec 21, 2009 at 21:07, Philip Brown wrote: > btw as a reminder: while apache2 "can" use the bundled apr there are > some benefits to having it use a standalone external package > > it would be a very nice thing if we had one, and in fact there was > some package in recent months that needed one? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers i commented the tests for the moment, the test code does ipv6. From rupert at opencsw.org Tue Dec 22 00:11:15 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 22 Dec 2009 00:11:15 +0100 Subject: [csw-maintainers] rebuild kde? In-Reply-To: References: <6af4270912200845i2206834dmc3cf1dab710f034d@mail.gmail.com> <6af4270912200848h7ef0188sbeae96ba42e8967b@mail.gmail.com> <2B41EBA1-A944-4D7D-9304-3A126B5D167D@opencsw.org> Message-ID: <6af4270912211511k79b7bec8v7250faa72fa2510d@mail.gmail.com> On Mon, Dec 21, 2009 at 20:58, Philip Brown wrote: > On Sunday, December 20, 2009, Dagobert Michelsen wrote: >> Hi Rupert, > >> >> Just add the libs. Rebuilding KDE is a major task. >> > > it is indeed a major task... that being said, it would be a very very > good thing for opencsw if someone would take on this task could somebody make a short description what needs to be done, and even more basic, how to compile kde on the build farm? rupert. From skayser at opencsw.org Tue Dec 22 00:16:08 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Dec 2009 00:16:08 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: <6af4270912211504r43f65310t86e00fa22570716e@mail.gmail.com> References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> <4B2E570A.3080708@opencsw.org> <6af4270912211504r43f65310t86e00fa22570716e@mail.gmail.com> Message-ID: <4B3001B8.9060408@opencsw.org> Hi Rupert, rupert THURNER wrote on 22.12.2009 00:04: > On Mon, Dec 21, 2009 at 21:07, Philip Brown wrote: >> btw as a reminder: while apache2 "can" use the bundled apr there are >> some benefits to having it use a standalone external package >> >> it would be a very nice thing if we had one, and in fact there was >> some package in recent months that needed one? > > i commented the tests for the moment, the test code does ipv6. glad it helped! There was a similar problem with mbuffer, which also does IPv6 tests. Instead of completely disabling the test suite, it was possible to only skip the IPv6 test. This way one is still alerted (and I already was) if anything else goes wrong. Might be wise to take the same route for apr for future builds. Do any other tests fail right now? Sebastian From skayser at opencsw.org Tue Dec 22 00:22:35 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Dec 2009 00:22:35 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> References: <20091221152001.GH7667@sebastiankayser.de> <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> Message-ID: <4B30033B.6000404@opencsw.org> Dagobert Michelsen wrote on 21.12.2009 16:26: > Am 21.12.2009 um 16:20 schrieb Sebastian Kayser: >> * Maciej (Matchek) Blizinski wrote: >>> On Mon, Dec 21, 2009 at 3:11 PM, Dagobert Michelsen >>> wrote: >>>> Gary, I installed Perl 5.10.1 on build8st, would you mind giving >>>> clusterssh >>>> a try against the updated Perl? >>> It's not that, at least in this case. clusterssh doesn't contain any >>> shared objects, the package consists only of a perl script and a man >>> page: >>> >>> http://www.opencsw.org/search/clusterssh >> It relies on pm_tk which in turn is compiled against the previous perl >> version. We should set up some automated way of re-building all perl >> modules with shared objects files against the new perl. > > The easiest way would be to update cpan2pkg from CSWcswutils to output > GAR Makefile and then mass-update the modules. I won't have much time > over christmas as I won a Live Upgrade migration from U6 UFS to U8 ZFS > for an 8-machine Sun Ray cluster which will suck up most of my "spare" > time... Isn't this perfect training material for apprentices? ;) > Sebastian, would you mind giving it a look? My time is limited also (will be away most of the holidays), but I will have a look. IIRC I even spotted a full blown CPAN-to-build-description utility within another distro. Might well be suitable/adjustable for our purposes. What sort of time pressure do we have with the perl upgrade? Sebastian From rupert at opencsw.org Tue Dec 22 01:27:47 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 22 Dec 2009 01:27:47 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: <4B3001B8.9060408@opencsw.org> References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> <4B2E570A.3080708@opencsw.org> <6af4270912211504r43f65310t86e00fa22570716e@mail.gmail.com> <4B3001B8.9060408@opencsw.org> Message-ID: <6af4270912211627m3e49bc36mbf44ae6a2a4bcb52@mail.gmail.com> On Tue, Dec 22, 2009 at 00:16, Sebastian Kayser wrote: > Hi Rupert, > > rupert THURNER wrote on 22.12.2009 00:04: >> On Mon, Dec 21, 2009 at 21:07, Philip Brown wrote: >>> btw as a reminder: while apache2 "can" use the bundled apr there are >>> some benefits to having it use a standalone external package >>> >>> it would be a very nice thing if we had one, and in fact there was >>> some package in recent months that needed one? >> >> i commented the tests for the moment, the test code does ipv6. > > glad it helped! There was a similar problem with mbuffer, which also > does IPv6 tests. Instead of completely disabling the test suite, it was > possible to only skip the IPv6 test. This way one is still alerted (and > I already was) if anything else goes wrong. Might be wise to take the > same route for apr for future builds. Do any other tests fail right now? > no. i did not find any log file but looked into the code. i do not understand what they really try to do ... but i'd saythe test suite should not test things which are known not to work. the code contains: #if APR_HAVE_IPV6 static void tcp6_socket(abts_case *tc, void *data) and the config log says: configure:34230: checking if APR supports IPv6 configure:34232: result: yes rupert. From bwalton at opencsw.org Tue Dec 22 02:09:29 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 21 Dec 2009 20:09:29 -0500 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: <1261443838-sup-4882@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Dec 21 16:51:19 -0500 2009: > as release manager, I might like t know if anythng IMPORTANT has > changed. parsing all those entries is the antithesis of automaton. it > requires detailed human scrutiny, if the maintained has been writng > detailed change logs. This is a good point... Given the way svn works, I find myself committing things that in a decent VCS, I wouldn't, or, more often, committing a whole bunch of disjoint changes together, making the actual log messages somewhat less useful. Also, I can't correct commit messages if I make a typo, or squash commits together if I forget to update the checksums file after bumping versions, etc. Subversion promotes (or at least doesn't discourage) badness in this area. While I like the overall idea, I agree with Phil that this would become a polluted change log in a hurry. 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 skayser at opencsw.org Tue Dec 22 09:21:35 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Dec 2009 09:21:35 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: <6af4270912211627m3e49bc36mbf44ae6a2a4bcb52@mail.gmail.com> References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> <4B2E570A.3080708@opencsw.org> <6af4270912211504r43f65310t86e00fa22570716e@mail.gmail.com> <4B3001B8.9060408@opencsw.org> <6af4270912211627m3e49bc36mbf44ae6a2a4bcb52@mail.gmail.com> Message-ID: <4B30818F.7030809@opencsw.org> rupert THURNER wrote on 22.12.2009 01:27: > On Tue, Dec 22, 2009 at 00:16, Sebastian Kayser wrote: >> rupert THURNER wrote on 22.12.2009 00:04: >>> i commented the tests for the moment, the test code does ipv6. >> >> glad it helped! There was a similar problem with mbuffer, which also >> does IPv6 tests. Instead of completely disabling the test suite, it was >> possible to only skip the IPv6 test. This way one is still alerted (and >> I already was) if anything else goes wrong. Might be wise to take the >> same route for apr for future builds. Do any other tests fail right now? >> > no. i did not find any log file but looked into the code. i do not > understand what they really try to do ... but i'd saythe test suite > should not test things which are known not to work. Regarding the test suite: There is a bug report about the IPv6 testing problem [1] where the bug reporter would also like to see the IPv6 tests being skipped rather than failed for boxes without IPv6 interfaces. The apr guys take a different stance. Luckily, a configured IPv6 loopback interface is sufficient. @Buildfarm admins: would it be possible to configure IPv6 loopback interfaces for the buildfarm boxes? # ifconfig lo0 inet6 plumb # ifconfig lo0 inet6 ::1 up # touch /etc/hostname6.lo0 > the code contains: > #if APR_HAVE_IPV6 > static void tcp6_socket(abts_case *tc, void *data) > > and the config log says: > configure:34230: checking if APR supports IPv6 > configure:34232: result: yes That's something different. ./configure detects general IPv6 support in the OS and it's libraries and thus build apr with IPv6 support. It is perfectly fine to build apr with IPv6 support - even if the particular build box doesn't have a configured IPv6 interface. This way we end up with an apr package that our users can use, even when they are running it in a configured IPv6 environment. Sebastian [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=45494 From maciej at opencsw.org Tue Dec 22 11:25:52 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Dec 2009 10:25:52 +0000 Subject: [csw-maintainers] Undefined symbol __sync_fetch_and_add_4. In-Reply-To: <4AF6F0A4.60205@opencsw.org> References: <4AF6F0A4.60205@opencsw.org> Message-ID: 2009/11/8 Trygve Laugst?l : > I'm trying to build freehdl on build8s, but when it's linking the final > binary I'm getting an error about a missing symbol "__sync_fetch_and_add_4" > > This seems to be a function that use atomic instructions that's not on i386 > and sparc 8 so i686 has to be used. I assume the problem is similar on > sparc, but I have no idea which flags to use. Does anyone know? > > http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Atomic-Builtins.html#Atomic-Builtins I just saw the same problem: gmake[3]: Entering directory `/home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0' /bin/bash ./libtool --tag=CXX --mode=link /opt/csw/gcc4/bin/g++ -O2 -pipe -mcpu=v8 -L/opt/csw/gcc4/lib/. -mcpu=v8 -L/opt/csw/lib -o samples/sample1_unittest samples/sample1_unittest.o lib/libgtest_main.la samples/libsamples.la /opt/csw/gcc4/bin/g++ -O2 -pipe -mcpu=v8 -mcpu=v8 -o samples/.libs/sample1_unittest samples/sample1_unittest.o -L/opt/csw/gcc4/lib/. -L/opt/csw/lib lib/.libs/libgtest_main.so /home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0/lib/.libs/libgtest.so samples/.libs/libsamples.a /opt/csw/gcc4/lib/libstdc++.so -lm -Wl,-R -Wl,/opt/csw/lib -Wl,-R -Wl,/opt/csw/gcc4/lib ld: warning: file /opt/csw/gcc4/lib/./libstdc++.so: linked to /opt/csw/gcc4/lib/libstdc++.so: attempted multiple inclusion of file Undefined first referenced symbol in file __sync_fetch_and_add_4 /home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0/lib/.libs/libgtest.so ld: fatal: Symbol referencing errors. No output written to samples/.libs/sample1_unittest gmake[3]: *** [samples/sample1_unittest] Error 1 Have you solved it? Maciej From rupert at opencsw.org Tue Dec 22 11:30:24 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 22 Dec 2009 11:30:24 +0100 Subject: [csw-maintainers] Undefined symbol __sync_fetch_and_add_4. In-Reply-To: References: <4AF6F0A4.60205@opencsw.org> Message-ID: <6af4270912220230p200ea3f5rb97ad33f76679b39@mail.gmail.com> On Tue, Dec 22, 2009 at 11:25, Maciej (Matchek) Blizinski wrote: > 2009/11/8 Trygve Laugst?l : >> I'm trying to build freehdl on build8s, but when it's linking the final >> binary I'm getting an error about a missing symbol "__sync_fetch_and_add_4" >> >> This seems to be a function that use atomic instructions that's not on i386 >> and sparc 8 so i686 has to be used. I assume the problem is similar on >> sparc, but I have no idea which flags to use. Does anyone know? >> >> http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Atomic-Builtins.html#Atomic-Builtins > > I just saw the same problem: > > gmake[3]: Entering directory > `/home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0' > /bin/bash ./libtool --tag=CXX ? --mode=link /opt/csw/gcc4/bin/g++ ?-O2 > -pipe -mcpu=v8 ?-L/opt/csw/gcc4/lib/. -mcpu=v8 -L/opt/csw/lib -o > samples/sample1_unittest samples/sample1_unittest.o > lib/libgtest_main.la samples/libsamples.la > /opt/csw/gcc4/bin/g++ -O2 -pipe -mcpu=v8 -mcpu=v8 -o > samples/.libs/sample1_unittest samples/sample1_unittest.o > -L/opt/csw/gcc4/lib/. -L/opt/csw/lib lib/.libs/libgtest_main.so > /home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0/lib/.libs/libgtest.so > samples/.libs/libsamples.a /opt/csw/gcc4/lib/libstdc++.so -lm ?-Wl,-R > -Wl,/opt/csw/lib -Wl,-R -Wl,/opt/csw/gcc4/lib > ld: warning: file /opt/csw/gcc4/lib/./libstdc++.so: linked to > /opt/csw/gcc4/lib/libstdc++.so: attempted multiple inclusion of file > Undefined ? ? ? ? ? ? ? ? ? ? ? first referenced > ?symbol ? ? ? ? ? ? ? ? ? ? ? ? ? ? in file > __sync_fetch_and_add_4 > /home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0/lib/.libs/libgtest.so > ld: fatal: Symbol referencing errors. No output written to > samples/.libs/sample1_unittest > gmake[3]: *** [samples/sample1_unittest] Error 1 > > Have you solved it? maybe use "-march=i486" as compiler flag? rupert. From maciej at opencsw.org Tue Dec 22 11:34:29 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Dec 2009 10:34:29 +0000 Subject: [csw-maintainers] Undefined symbol __sync_fetch_and_add_4. In-Reply-To: <6af4270912220230p200ea3f5rb97ad33f76679b39@mail.gmail.com> References: <4AF6F0A4.60205@opencsw.org> <6af4270912220230p200ea3f5rb97ad33f76679b39@mail.gmail.com> Message-ID: On Tue, Dec 22, 2009 at 10:30 AM, rupert THURNER wrote: > maybe use "-march=i486" as compiler flag? I saw these hints, but this is a sparc processor. From dam at opencsw.org Tue Dec 22 14:01:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Dec 2009 14:01:32 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: <85BE3575-4118-4A28-9D83-E6FCA34ACE15@opencsw.org> Hi Maciej, Am 21.12.2009 um 22:28 schrieb Maciej (Matchek) Blizinski: > In the future one might envision an > automated system in which the maintainer doesn't write an e-mail, but > simply states the decision "I want X to be submitted for release" and > the rest pf the process, up to the point when the release candidate > files are presented to the release manager, is automated. I think > that the rest of the crew has a similar vision, please chime in. Yes. +1 > Perhaps there could be a generated link associated with each piece of > software, showing the differences between the build files, such as: > http://tinyurl.com/ygvbh7v (A side note: this would be build-system > independent. The only requirement would be for the software in > question to point at the URL from which it was built and provide the > revision number.) Sounds promising. I am looking forwards to see this implemented. Best regards -- Dago From dam at opencsw.org Tue Dec 22 14:24:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Dec 2009 14:24:26 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: Hi, Am 21.12.2009 um 22:51 schrieb Philip Brown: > On Monday, December 21, 2009, Maciej (Matchek) Blizinski > wrote: >> On Mon, Dec 21, 2009 at 8:02 PM, Philip Brown >> wrote: >>> oh let's NOT include all svn messages please. >>> too much information potentially >> >> I'll first explain why I was thinking of including them. I'm aiming >> at automating all the bits that don't absolutely require human >> intervention. I assume that as the release manager, you would like >> to >> know what has changed since the last release. > > as release manager, I might like t know if anythng IMPORTANT has > changed. parsing all those entries is the antithesis of automaton. it > requires detailed human scrutiny, if the maintained has been writng > detailed change logs. > > perhaps it might be beneficial if the tool optionally displayed the > logs to the mantainer only. then they can determine if there is > anything important to pass on to the release manager? When we are talking about automation it may be useful to work towards automatic build: When someone makes a tag the comment to the tag may include the relevant message what has changed since the last tag only. Best regards -- Dago From dam at opencsw.org Tue Dec 22 14:27:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Dec 2009 14:27:19 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: <4B30033B.6000404@opencsw.org> References: <20091221152001.GH7667@sebastiankayser.de> <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> <4B30033B.6000404@opencsw.org> Message-ID: Hi Sebastian, Am 22.12.2009 um 00:22 schrieb Sebastian Kayser: >> Sebastian, would you mind giving it a look? > > My time is limited also (will be away most of the holidays), but I > will > have a look. IIRC I even spotted a full blown CPAN-to-build- > description > utility within another distro. Might well be suitable/adjustable for > our > purposes. What sort of time pressure do we have with the perl upgrade? Well, the Perl in current is broken to the point that some packages can't be compiled due to conflict in current vs. shipped MakeMaker. Perl 5.10.1 solves this, so timely shipping would certainly be good. BTW, the cpan2pkg script I mentioned is based on the script you cited, but already has all the stuff from CSW in it with the exception of producing packages instead of GAR Makefiles. Best regards -- Dago From dam at opencsw.org Tue Dec 22 15:50:16 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Dec 2009 15:50:16 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: <4B30818F.7030809@opencsw.org> References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> <4B2E570A.3080708@opencsw.org> <6af4270912211504r43f65310t86e00fa22570716e@mail.gmail.com> <4B3001B8.9060408@opencsw.org> <6af4270912211627m3e49bc36mbf44ae6a2a4bcb52@mail.gmail.com> <4B30818F.7030809@opencsw.org> Message-ID: <53850355-EA7E-4B2A-A23F-EEBBEA937ACB@opencsw.org> Hi Sebastian, Am 22.12.2009 um 09:21 schrieb Sebastian Kayser: > Regarding the test suite: There is a bug report about the IPv6 testing > problem [1] where the bug reporter would also like to see the IPv6 > tests > being skipped rather than failed for boxes without IPv6 interfaces. > The > apr guys take a different stance. > > Luckily, a configured IPv6 loopback interface is sufficient. > @Buildfarm > admins: would it be possible to configure IPv6 loopback interfaces for > the buildfarm boxes? > > # ifconfig lo0 inet6 plumb > # ifconfig lo0 inet6 ::1 up > # touch /etc/hostname6.lo0 Done on all build machines. Best regards -- Dago From dam at opencsw.org Tue Dec 22 16:01:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Dec 2009 16:01:17 +0100 Subject: [csw-maintainers] Package naming of splitting of library-packages Message-ID: Hi, I am currently packaging up libcdio and libcddb. Both packages consist of some libraries and some binaries. The libraries are somewhat self-contained and do not depend on each other while the binaries of both packages require each their and the other library. The upstream author recommended splitting up the library from the binaries. In terms of OpenCSW that would mean having two build recipes libcddbrt libcdiort which produce the CSWlibcddbrt and CSWlibcdiort packages. Then two other build descriptions libcddb libcdio will produce CSWlibcddb and CSWlibcdio containing the binaries. Now the question: library-packages usually don't have runtime-subpackages, but in this case it would IMHO be useful. Thoughts? Phil? Best regards -- Dago From maciej at opencsw.org Tue Dec 22 16:15:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Dec 2009 15:15:46 +0000 Subject: [csw-maintainers] Package naming of splitting of library-packages In-Reply-To: References: Message-ID: On Tue, Dec 22, 2009 at 3:01 PM, Dagobert Michelsen wrote: > Now the question: library-packages usually don't have > runtime-subpackages, but in this case it would IMHO be > useful. Thoughts? Phil? The solutions I've seen in other places were to create a *-tools optional package with the binaries. For example, Debian has libnss3 with the libraries and libnss3-tools with the binaries. In the case of libcddb it would make something along the lines of: CSWlibcddb CSWlibcddb-tools Maciej From phil at bolthole.com Tue Dec 22 16:35:48 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 22 Dec 2009 07:35:48 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> Message-ID: On Monday, December 21, 2009, Gary Law wrote: > ... > 1) Use CSWcswclassutils and stop those with read-only /usr using our packages; > > Primary problem with (1) is it rules out using CSW packages on a > significant number of machines which have read-only /usr. I'd call > that a major issue, a showstopper bug in the case of the package I'm > trying to get into GAR. > I'd say that you are overestimating this "significant number". nor is it usually a "showstopper" First of all, most places that have "read only usr" still have mechanisms for needed updates. Secondly, there are direct workarounds even for difficult cases, as I have pointed out. Thirdly, there are sometimes Indirect workarounds. for example, Rupert has found a workarounds in his situation I believe. lastly; this is not our Only deployment into /usr. We deploy under /opt/csw , except when the nature of solaris requires us to deploy in a specific location elsewhere. For example, our dtlogin integration packages, which deploy under /usr/dt From phil at bolthole.com Tue Dec 22 16:42:26 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 22 Dec 2009 07:42:26 -0800 Subject: [csw-maintainers] rebuild kde? In-Reply-To: <6af4270912211511k79b7bec8v7250faa72fa2510d@mail.gmail.com> References: <6af4270912200845i2206834dmc3cf1dab710f034d@mail.gmail.com> <6af4270912200848h7ef0188sbeae96ba42e8967b@mail.gmail.com> <2B41EBA1-A944-4D7D-9304-3A126B5D167D@opencsw.org> <6af4270912211511k79b7bec8v7250faa72fa2510d@mail.gmail.com> Message-ID: unfortunately it is a very multilayer process. 21 packages not counting the i18n packages. one way to handle this might be to build a "dry run" set of packages on one of our test machines. (you get root that way so can install test packages yourself) once you have a working proceedure then do it "for real". On Monday, December 21, 2009, rupert THURNER wrote: > On Mon, Dec 21, 2009 at 20:58, Philip Brown wrote: >> On Sunday, December 20, 2009, Dagobert Michelsen wrote: >>> Hi Rupert, >> >>> >>> Just add the libs. Rebuilding KDE is a major task. >>> >> >> it is indeed a major task... that being said, it would be a very very >> good thing for opencsw if someone would take on this task > > could somebody make a short description what needs to be done, and > even more basic, how to compile kde on the build farm? > > rupert. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > From james at opencsw.org Tue Dec 22 17:05:13 2009 From: james at opencsw.org (James Lee) Date: Tue, 22 Dec 2009 16:05:13 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> Message-ID: <20091222.16051300.3754394574@gyor.oxdrove.co.uk> On 22/12/09, 15:35:48, Philip Brown wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > We deploy under /opt/csw , except when the nature of solaris requires > us to deploy in a specific location elsewhere. For example, our > dtlogin integration packages, which deploy under /usr/dt /etc/dt can be used and most CSW dtlogins do. CSWicewm is the only one that does not, bug report: http://www.opencsw.org/bugtrack/view.php?id=1120 Other (ab)users of /usr/... CSWdialog (REV=2003.03.18) and CSWsambawb (REV=2006.08.09b) are old and have pending bug reports. CSWpmmailspf, updates existing /usr/ directories, bug report: http://www.opencsw.org/bugtrack/view.php?id=4079 CSWtun, CSWtop and CSWdosexec are drivers and write to /usr/kernal. Leaving only CSWclassutils. From bwalton at opencsw.org Tue Dec 22 17:38:53 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 22 Dec 2009 11:38:53 -0500 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091222.16051300.3754394574@gyor.oxdrove.co.uk> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> Message-ID: <1261499782-sup-5582@ntdws12.chass.utoronto.ca> Excerpts from James Lee's message of Tue Dec 22 11:05:13 -0500 2009: > Other (ab)users of /usr/... What about things like CSWexim, and presumably CSWpostfix that might move /usr/lib/sendmail out of the way as part of the postinstall. CSWexim uses a prompt to handle this and has allows you to skip it. I don't know about CSWpostfix and I don't use it. This is a somewhat different case, since it's the postinstall script, but there is still potential for 'partially installed' status here. -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 Tue Dec 22 17:40:56 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 22 Dec 2009 11:40:56 -0500 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: <20091221152001.GH7667@sebastiankayser.de> <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> <4B30033B.6000404@opencsw.org> Message-ID: <1261499988-sup-5699@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Dec 22 08:27:19 -0500 2009: > BTW, the cpan2pkg script I mentioned is based on the script you cited, > but already has all the stuff from CSW in it with the exception of > producing packages instead of GAR Makefiles. The GAR support for quickly building a CPAN module is quite good too though. Updating any of the pm_* packages should be trivial if they're already in GAR and near-so[1] if not. -Ben [1] Barring any solaris specific issues that have popped up in newer versions. -- 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 james at opencsw.org Tue Dec 22 18:09:08 2009 From: james at opencsw.org (James Lee) Date: Tue, 22 Dec 2009 17:09:08 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <1261499782-sup-5582@ntdws12.chass.utoronto.ca> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> Message-ID: <20091222.17090800.2208031977@gyor.oxdrove.co.uk> On 22/12/09, 16:38:53, Ben Walton wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > What about things like CSWexim, and presumably CSWpostfix that might > move /usr/lib/sendmail out of the way as part of the postinstall. > CSWexim uses a prompt to handle this and has allows you to skip it. They might but needn't and maybe shouldn't. My exim works with /usr/sendmail in place although it needs manual "svcadm disable sendmail" to get access to port 25. A reason not to move system files might be that system patches can't work. e.g. If you move sendmail, patch it, move it back you have an unpatched sendmail (or maybe an error in the patch process, not sure, I've never actually done it). James. From maciej at opencsw.org Tue Dec 22 18:14:23 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Dec 2009 17:14:23 +0000 Subject: [csw-maintainers] CSWpython-rt is now deprecated Message-ID: Executive summary: CSWpython-rt is deprecated, please re-point your dependencies at CSWpython. The upcoming release of Python (2.6.4) has a change related to packaging. The CSWpython-rt package is now an empty, deprecated package. It used to contain shared objects from Python. It was a confusing package, because it made the impression that it's enough for other Python-dependent packages to only depend on CSWpython-rt. In fact, in all the cases, the whole Python package is necessary. It was necessary to declare dependencies to both CSWpython and CSWpython-rt, even though CSWpython required CSWpython-rt, so there was redundancy involved. In python-2.6.4, all the shared objects are in the CSWpython package. Bugs will be filed against all the dependent projects to remove the dependency on CSWpython-rt. When all the dependencies are removed, the -rt package will be removed too. If there is a package which does depend on CSWpython-rt but doesn't depend on CSWpython, it can get into trouble if CSWpython happens to be uninstalled. The potentially affected packages are: pymysql pysqlite ooocore trac silvercity pysqlite2 genshi graphvizpython I think that in the case of most these packages it's dead obvious that CSWpython is necessary, since they're Python libraries. The package that may be the most affected here is ooocore. Maciej From phil at bolthole.com Tue Dec 22 18:15:30 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 22 Dec 2009 09:15:30 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091222.17090800.2208031977@gyor.oxdrove.co.uk> References: <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> Message-ID: I was just reminded of something that I hadn't mentioned much on the list before now. When I first came up with the idea of us using class action scripts, I had always thought that it would be beneficial to also provide some utils to run needful things manually (primarily for the case of nfs shared /opt/csw) Before now, this has not been seen as important. But now would seem to be a good time to bring this up again :) if we provide an alternative CSWcswclassutils package, whose function is, "go run actions that normally get done at pkgadd time", then we could cover the very small amount of people who are "blocked" by our regular version of the package deploying to /usr. This would be an ALTERNATIVE to our regular ?package, rather than replacing it. the major changes required would be: 1 making sure all cswclassutils input files are homed under /opt/csw instead of /etc 2 providing an alternative implementation script, for each of our class actions in use. ( and possibly 3: providing some sort of automated hook for scanning for "new" packages that haven't had their class actions run for them ) From james at opencsw.org Tue Dec 22 18:43:58 2009 From: james at opencsw.org (James Lee) Date: Tue, 22 Dec 2009 17:43:58 GMT Subject: [csw-maintainers] CSWpython-rt is now deprecated In-Reply-To: References: Message-ID: <20091222.17435800.1351067935@gyor.oxdrove.co.uk> On 22/12/09, 17:14:23, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] CSWpython-rt is now deprecated: > Executive summary: CSWpython-rt is deprecated, please re-point your > dependencies at CSWpython. ... > In python-2.6.4, all the shared objects are in the CSWpython package. > Bugs will be filed against all the dependent projects to remove the > dependency on CSWpython-rt. I presume you have made CSWpython-rt depend on CSWpython so there is no urgency to the change. James. From bwalton at opencsw.org Tue Dec 22 19:10:13 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 22 Dec 2009 13:10:13 -0500 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091222.17090800.2208031977@gyor.oxdrove.co.uk> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> Message-ID: <1261505240-sup-8636@ntdws12.chass.utoronto.ca> Excerpts from James Lee's message of Tue Dec 22 12:09:08 -0500 2009: > They might but needn't and maybe shouldn't. My exim works with > /usr/sendmail in place although it needs manual "svcadm disable > sendmail" to get access to port 25. That's all well and good until something wants to inject mail via /usr/lib/sendmail. At that point, it's fairly important to have /usr/lib/sendmail be the CSW file and not the SUNW one. Replacing mailq and aliases is also useful (creature comfort-wise) but not essential. I'd actually consider CSWexim broken if it didn't at least offer to make the switch. > A reason not to move system files might be that system patches can't > work. e.g. If you move sendmail, patch it, move it back you have an > unpatched sendmail (or maybe an error in the patch process, not > sure, I've never actually done it). I have cfengine was this file and ensure it stays 'right.' Patching will trample it unless your provide the correct admin files or options, etc. It's a pita, but a small price to pay to be rid of sendmail. -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 Dec 22 19:30:05 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Dec 2009 18:30:05 +0000 Subject: [csw-maintainers] CSWpython-rt is now deprecated In-Reply-To: <20091222.17435800.1351067935@gyor.oxdrove.co.uk> References: <20091222.17435800.1351067935@gyor.oxdrove.co.uk> Message-ID: On Tue, Dec 22, 2009 at 5:43 PM, James Lee wrote: > I presume you have made CSWpython-rt depend on CSWpython so there is > no urgency to the change. I haven't made CSWpython-rt depend on CSWpython initially, but I've followed this suggestion and I've sent the updated CSWpython-rt to Phil. From maciej at opencsw.org Tue Dec 22 21:18:51 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Dec 2009 20:18:51 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: On Tue, Dec 22, 2009 at 1:24 PM, Dagobert Michelsen wrote: > When we are talking about automation it may be useful to work towards > automatic build: When someone makes a tag the comment to the tag may > include the relevant message what has changed since the last tag only. I tend to disagree with the tagging idea. Tags are good when you want to preserve a version of the build before making major changes. You can argue that tags are good for marking certain revisions of interest, and package releases could count. But it strikes me as a model which doesn't take into account other factors playing role in how we work with subversion. There are two main problems with it. One is that we don't have the habit of using tags and I don't think we'll acquire it unless it's mandatory. If you make it mandatory, it will be annoying to people and will do more harm than good. If it won't be mandatory, nobody will use it, because it will make no benefit to the maintainer. The second problem is that if we start tagging every release, our source repository will quickly become so crowded, that doing a checkout of the gar/pkg directory will take forever. You can even try to estimate the time based on current checkout speed and the projected number of files after, say, a year. I really like the current setup in which the package has an embedded information about the subversion path from which it was built, and the revision number. You don't need more. If you have this information, you can work out which release was built from which revision. If we want something faster than downloading and dissecting a package, we can cache this information in a database. I think we can achieve the same functionality (automated builds) in a more transparent, non-intrusive way. Maciej From glaw at opencsw.org Tue Dec 22 23:28:35 2009 From: glaw at opencsw.org (Gary Law) Date: Tue, 22 Dec 2009 22:28:35 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> Message-ID: Hi all What a can of worms I've opened, sorry... anyway... 2009/12/22 Philip Brown : > I was just reminded of something that I hadn't mentioned much on the > list before now. > > When I first came up with the idea of us using class action scripts, I > had always thought that it would be beneficial to also provide some > utils to run needful things manually (primarily for the case of nfs > shared /opt/csw) I have to say the number of installations with shared nfs /opt/csw would -- I guess -- be far fewer than the number with zones with read only /usr. > Before now, this has not been seen as important. But now would seem to > be a good time to bring this up again :) > > if we provide an alternative CSWcswclassutils package, whose function > is, "go run actions that normally get done at pkgadd time", then we > could cover the very small amount of people who are "blocked" by our > regular version of the package deploying to /usr. > > This would be an ALTERNATIVE to our regular ?package, rather than replacing it. That gets my vote if there's a way to handle the dependencies. Gary -- glaw at opencsw.org From glaw at opencsw.org Tue Dec 22 23:30:36 2009 From: glaw at opencsw.org (Gary Law) Date: Tue, 22 Dec 2009 22:30:36 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091222.17090800.2208031977@gyor.oxdrove.co.uk> References: <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> Message-ID: 2009/12/22 James Lee : > On 22/12/09, 16:38:53, Ben Walton wrote regarding Re: > [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > >> What about things like CSWexim, and presumably CSWpostfix that might >> move /usr/lib/sendmail out of the way as part of the postinstall. >> CSWexim uses a prompt to handle this and has allows you to skip it. > > They might but needn't and maybe shouldn't. +1 -- glaw at opencsw.org From skayser at opencsw.org Tue Dec 22 23:36:41 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Dec 2009 23:36:41 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> Message-ID: <4B3149F9.5060109@opencsw.org> Gary Law wrote on 22.12.2009 23:30: > 2009/12/22 James Lee : >> On 22/12/09, 16:38:53, Ben Walton wrote regarding Re: >> [csw-maintainers] CSWcswclassutils: it wants to write in /usr: >> >>> What about things like CSWexim, and presumably CSWpostfix that might >>> move /usr/lib/sendmail out of the way as part of the postinstall. >>> CSWexim uses a prompt to handle this and has allows you to skip it. >> They might but needn't and maybe shouldn't. > > +1 What's the alternative then? Don't do anything, put instructions in README.CSW and let the user do whatever he wants/needs to do? Sebastian From james at opencsw.org Wed Dec 23 10:28:39 2009 From: james at opencsw.org (James Lee) Date: Wed, 23 Dec 2009 09:28:39 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <1261505240-sup-8636@ntdws12.chass.utoronto.ca> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> <1261505240-sup-8636@ntdws12.chass.utoronto.ca> Message-ID: <20091223.9283900.1782552105@gyor.oxdrove.co.uk> On 22/12/09, 18:10:13, Ben Walton wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > > They might but needn't and maybe shouldn't. My exim works with > > /usr/sendmail in place although it needs manual "svcadm disable > > sendmail" to get access to port 25. > That's all well and good until something wants to inject mail via > /usr/lib/sendmail. At that point, it's fairly important to have > /usr/lib/sendmail be the CSW file and not the SUNW one. Replacing > mailq and aliases is also useful (creature comfort-wise) but not > essential. I'd actually consider CSWexim broken if it didn't at least > offer to make the switch. I'd consider anything that directly used /usr/lib/sendmail to be broken and I realise that includes system functions like cron output. However, it does work, this gets to my normal IMAP account on another zone/machine with exim but using sendmail as the first local hop: $ echo "hello me" | mailx -s "test" $USER It's not important to me because sendmail does work. The reason I use exim is because I want to do more than just deliver locally generated mail and exim is easier to configure and do the advanced things like use SQL for routing variables. It would be best if mailx etc. were more aware, eg, the system looked for "mailhost" in the hosts list and used SMTP (analogous to loghost and syslog). James. From glaw at opencsw.org Wed Dec 23 11:24:10 2009 From: glaw at opencsw.org (Gary Law) Date: Wed, 23 Dec 2009 10:24:10 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <4B3149F9.5060109@opencsw.org> References: <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> <4B3149F9.5060109@opencsw.org> Message-ID: 2009/12/22 Sebastian Kayser : >>>> What about things like CSWexim, and presumably CSWpostfix that might >>>> move /usr/lib/sendmail out of the way as part of the postinstall. >>>> CSWexim uses a prompt to handle this and has allows you to skip it. >>> They might but needn't and maybe shouldn't. >> >> +1 > > What's the alternative then? Don't do anything, put instructions in > README.CSW and let the user do whatever he wants/needs to do? I would really not expect a CSW install to move, delete or link things that are already in /usr/lib. Especially something as core to many admins assumptions as sendmail. It just doesn't follow the 'least surprise' approach, never mind the 'nothing in /usr' policy. What if I have a working sendmail setup I'm happy with, but want to test CSW sendmail or exim or postfix? I'd be very unhappy if something came along and blatted default sendmail. Perhaps I'm in a minority of one on this. As for alternatives, a big fat message echoing to the console on install would be handy, and the documentation you suggest explaining why the link might be needed in some cases, but I don't think it should be automatically created. There's perhaps a case for creating the link if /usr/lib doesn't already have a sendmail in it, but I'd prefer it didn't*. Gary * And of course the link could point to the newly proposed alternative selection mechanism, for those crazy admins who want the full selection of available CSW MTAs installed. -- glaw at opencsw.org From bwalton at opencsw.org Wed Dec 23 13:40:11 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Dec 2009 07:40:11 -0500 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091223.9283900.1782552105@gyor.oxdrove.co.uk> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> <1261505240-sup-8636@ntdws12.chass.utoronto.ca> <20091223.9283900.1782552105@gyor.oxdrove.co.uk> Message-ID: <1261571233-sup-6117@ntdws12.chass.utoronto.ca> Excerpts from James Lee's message of Wed Dec 23 04:28:39 -0500 2009: > I'd consider anything that directly used /usr/lib/sendmail to be > broken and I realise that includes system functions like cron > output. Yes, but we've got a _lot_ of years of history here that aren't about to be corrected any time soon. exim and postfix emulate sendmail options for a reason. This isn't an issue on solaris only, either. It extends to any *nix I've encountered, although we now typically look for sendmail in /usr/bin elsewhere. > However, it does work, this gets to my normal IMAP account on another > zone/machine with exim but using sendmail as the first local hop: ...but this is only by chance, and is site/setup dependent. What if you only allow relay internally using LMTP or submission(587) w/tls? Your setup would then fail unless you also maintained a separate sendmail config...at which point, why replace it in the first place? It's fragile at best. > It's not important to me because sendmail does work. The reason I > use exim is because I want to do more than just deliver locally > generated mail and exim is easier to configure and do the advanced > things like use SQL for routing variables. I use it for the same reasons. > It would be best if mailx etc. were more aware, eg, the system looked > for "mailhost" in the hosts list and used SMTP (analogous to loghost > and syslog). Without something like this, there is a lot of opportunity for mail policy problems. Say you need all mail routed out via a designated relay machine, or qualified with your $tld. The default sendmail config will talk directly to the world and doesn't do 'good things' with qualification of local addresses without a bit of hand holding. You now need to maintain a separate sendmail.cf to match what you're doing with the exim config. Somewhat self defeating. The other thing to consider with a setup like this, straddling two mailers, is that you've now got two queues and if sendmail isn't active, you'd need to push it's queue manually in the event that there are hiccups on the initial delivery. Two mailers is just plain broken. A bug, if you will. -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 Wed Dec 23 13:46:39 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Dec 2009 07:46:39 -0500 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> <4B3149F9.5060109@opencsw.org> Message-ID: <1261572054-sup-10@ntdws12.chass.utoronto.ca> Excerpts from Gary Law's message of Wed Dec 23 05:24:10 -0500 2009: > I would really not expect a CSW install to move, delete or link things > that are already in /usr/lib. Especially something as core to many > admins assumptions as sendmail. It just doesn't follow the 'least > surprise' approach, never mind the 'nothing in /usr' policy. What if I > have a working sendmail setup I'm happy with, but want to test CSW > sendmail or exim or postfix? I'd be very unhappy if something came > along and blatted default sendmail. Yes, and in this case, CSWexim (and CSWpostfix?) does the right thing. It's an interactive (which sucks for jumpstart/automation) postinstall script, giving you the choice. You can leave the sendmail binaries in place or replace them, at your choosing. > As for alternatives, a big fat message echoing to the console on > install would be handy, and the documentation you suggest explaining > why the link might be needed in some cases, but I don't think it > should be automatically created. There's perhaps a case for creating It's not automatically created. You need to select the right option in the postinstall and can certainly opt to leave it alone. The bigger picture here is that no matter how superior the CSW packages are (CSWsendmail included), we're still trespassing on the system. Solaris doesn't provide the functionality to transparently replace important system functions like the mailer. I used to leverage the RHEL alternatives system to redirect mail functions to use exim until I modified our kickstart to omit sendmail and provide only exim. Unfortunately, we can't do that here since the solaris side of things would remain ignorant of the feature. -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 Dec 23 15:39:08 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 23 Dec 2009 15:39:08 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <1261499782-sup-5582@ntdws12.chass.utoronto.ca> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 22.12.2009 um 17:38 schrieb Ben Walton: > Excerpts from James Lee's message of Tue Dec 22 11:05:13 -0500 2009: > >> Other (ab)users of /usr/... > > What about things like CSWexim, and presumably CSWpostfix that might > move /usr/lib/sendmail out of the way as part of the postinstall. > CSWexim uses a prompt to handle this and has allows you to skip it. I > don't know about CSWpostfix and I don't use it. > > This is a somewhat different case, since it's the postinstall script, > but there is still potential for 'partially installed' status here. As we already talked about it the best solution is to have a separate "Sun Functionality Replacement Package" in a different catalog which is incompatible with the Sun package and doesn't break "install-all". Best regards -- Dago From dam at opencsw.org Wed Dec 23 15:40:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 23 Dec 2009 15:40:19 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: <1261499988-sup-5699@ntdws12.chass.utoronto.ca> References: <20091221152001.GH7667@sebastiankayser.de> <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> <4B30033B.6000404@opencsw.org> <1261499988-sup-5699@ntdws12.chass.utoronto.ca> Message-ID: <53CA2294-0E21-4B25-9970-D528D61D6FA9@opencsw.org> Hi Ben, Am 22.12.2009 um 17:40 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Tue Dec 22 08:27:19 > -0500 2009: > >> BTW, the cpan2pkg script I mentioned is based on the script you >> cited, >> but already has all the stuff from CSW in it with the exception of >> producing packages instead of GAR Makefiles. > > The GAR support for quickly building a CPAN module is quite good too > though. Updating any of the pm_* packages should be trivial if > they're already in GAR and near-so[1] if not. Manually updating a package with GAR takes about 10 minutes whereas a package update with a modified cpan2pkg will most certainly take about 1 minute. As we have 100+ package to update this is something. Best regards -- Dago From bwalton at opencsw.org Wed Dec 23 15:55:00 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Dec 2009 09:55:00 -0500 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: <53CA2294-0E21-4B25-9970-D528D61D6FA9@opencsw.org> References: <20091221152001.GH7667@sebastiankayser.de> <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> <4B30033B.6000404@opencsw.org> <1261499988-sup-5699@ntdws12.chass.utoronto.ca> <53CA2294-0E21-4B25-9970-D528D61D6FA9@opencsw.org> Message-ID: <1261579955-sup-6008@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Dec 23 09:40:19 -0500 2009: > Manually updating a package with GAR takes about 10 minutes whereas > a package update with a modified cpan2pkg will most certainly take > about 1 minute. As we have 100+ package to update this is something. Ok. I didn't realize there was that much difference in time required. When you count 100+ though, I assume you're counting all pm_* packages. This breakage only affects modules that provide .so files correct? That would make the number much less, most likely[1]. I'm not advocating either way here, I just thought that GAR was a good option for this too. Thanks -Ben [1] No, I haven't looked at package contents. -- 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 Wed Dec 23 16:12:38 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Dec 2009 10:12:38 -0500 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> Message-ID: <1261581091-sup-9562@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Dec 23 09:39:08 -0500 2009: > As we already talked about it the best solution is to have a separate > "Sun Functionality Replacement Package" in a different catalog which > is incompatible with the Sun package and doesn't break > "install-all". Ah yes, I'd forgotten about the cups discussion. Hoops++. :) -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 Dec 23 18:10:44 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Dec 2009 17:10:44 +0000 Subject: [csw-maintainers] Determining shared object dependencies Message-ID: Let's suppose there's a shared object which depends on libstdc++.so.6. I'd like to determine its dependencies. Unfortunately, libstdc++.so.6 exists in more than one place in the filesystem: maciej at build8s [build8s]:~ > ls -l /opt/csw/{,gcc4/}lib/libstdc++.so.6 lrwxrwxrwx 1 root other 19 May 11 2009 /opt/csw/gcc4/lib/libstdc++.so.6 -> libstdc++.so.6.0.10 lrwxrwxrwx 1 root other 20 Aug 7 11:50 /opt/csw/lib/libstdc++.so.6 -> ./libstdc++.so.6.0.3 How am I supposed to tell which one is the right one? (Without trussing the running program, of course.) The best idea I have is looking at the RUNPATH property of the library and assuming that the first one is the right one. For example, if the RUNPATH was ['/opt/csw/gcc4/lib', '/opt/csw/lib/$ISALIST', '/opt/csw/lib', '/opt/csw/lib', '/opt/csw/lib/svn'], I would assume that /opt/csw/gcc4/lib/libstdc++.so.6 is the right one, because '/opt/csw/gcc4/lib' appears first on the RUNPATH list. Do you this this is a reliable method? From maciej at opencsw.org Wed Dec 23 18:16:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Dec 2009 17:16:13 +0000 Subject: [csw-maintainers] Determining shared object dependencies In-Reply-To: References: Message-ID: I think my previous e-mail lacked a clarification of what is the task about. It's about mapping from a list of SONAMEs to a list of corresponding files on the filesystem. (Which will be later mapped to the list of installed packages.) From phil at bolthole.com Wed Dec 23 18:47:39 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Dec 2009 09:47:39 -0800 Subject: [csw-maintainers] Determining shared object dependencies In-Reply-To: References: Message-ID: On Wed, Dec 23, 2009 at 9:10 AM, Maciej (Matchek) Blizinski wrote: > Let's suppose there's a shared object which depends on libstdc++.so.6. > ?I'd like to determine its dependencies. ?Unfortunately, > libstdc++.so.6 exists in more than one place in the filesystem: > > maciej at build8s [build8s]:~ > ls -l /opt/csw/{,gcc4/}lib/libstdc++.so.6 > lrwxrwxrwx ? 1 root ? ? other ? ? ? ? 19 May 11 ?2009 > /opt/csw/gcc4/lib/libstdc++.so.6 -> libstdc++.so.6.0.10 > lrwxrwxrwx ? 1 root ? ? other ? ? ? ? 20 Aug ?7 11:50 > /opt/csw/lib/libstdc++.so.6 -> ./libstdc++.so.6.0.3 > > How am I supposed to tell which one is the right one? ?(Without > trussing the running program, of course.) ?The best idea I have is > looking at the RUNPATH property of the library and assuming that the > first one is the right one. ?For example, if the RUNPATH was > ['/opt/csw/gcc4/lib', '/opt/csw/lib/$ISALIST', '/opt/csw/lib', > '/opt/csw/lib', '/opt/csw/lib/svn'], I would assume that > /opt/csw/gcc4/lib/libstdc++.so.6 is the right one, because > '/opt/csw/gcc4/lib' appears first on the RUNPATH list. > > Do you this this is a reliable method? It is in theory what will actually get loaded at runtime. so yes :-) From phil at bolthole.com Wed Dec 23 18:57:37 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Dec 2009 09:57:37 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> Message-ID: On Tue, Dec 22, 2009 at 2:28 PM, Gary Law wrote: > > I have to say the number of installations with shared nfs /opt/csw > would -- I guess -- be far fewer than the number with zones with read > only /usr. The problem set isnt "all zones that have read only /usr". The problem set is "all zones that have read only /usr, AND the sysadmin is unwilling/unable to update it". Which is a much smaller set. I would guess comparable in size to the "nfs shared, or otherwise replicated /opt/csw". Rupert, for one, counts as a thousand installs of the "otherwise replicated /opt/csw" case ;-) But anyways, moving on to some implementation details... >> if we provide an alternative CSWcswclassutils package, whose function >> is, "go run actions that normally get done at pkgadd time", then we >> could cover the very small amount of people who are "blocked" by our >> regular version of the package deploying to /usr. >> >> This would be an ALTERNATIVE to our regular ?package, rather than replacing it. > > That gets my vote if there's a way to handle the dependencies. sure, no problem. The "alternative" package, would be outside the regular catalog, but have the exact same name. So things would work as follows: regular catalog offers CSWcswclassutils, REV=2009.12.23 "alternative" download url/catalog, offers the "alternative workaround" package, that is ALSO NAMED, "CSWcswclassutils, REV=2009.12.23". Neither pkg-get nor pkgutil do any fancy checks about point of origin, of an already installed package. So, installing "lftp", the util would say to itself, "Hmm. this program need CSWcswclassutils. My catalog says I need REV=2009.12.23 of that. Checking current installed version.... version number matches. Ok, moving on..." no problem. We just need to keep updates of cswclassutils infrequent, to avoid inconveniencing the manual updaters. From bwalton at opencsw.org Thu Dec 24 00:18:55 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Dec 2009 18:18:55 -0500 Subject: [csw-maintainers] Determining shared object dependencies In-Reply-To: References: Message-ID: <1261610257-sup-6818@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Dec 23 12:47:39 -0500 2009: > It is in theory what will actually get loaded at runtime. so yes :-) Alternately, you could compare the NEEDED (soname) items from dump with the output from ldd. Not perfect, but the resolution is handled there. The only trick is that ldd will resolve things recursively, so you need to know what you're after 'up front.' 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 james at opencsw.org Thu Dec 24 11:23:52 2009 From: james at opencsw.org (James Lee) Date: Thu, 24 Dec 2009 10:23:52 GMT Subject: [csw-maintainers] Determining shared object dependencies In-Reply-To: References: Message-ID: <20091224.10235200.1408762620@gyor.oxdrove.co.uk> On 23/12/09, 17:10:44, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] Determining shared object dependencies: > Let's suppose there's a shared object which depends on libstdc++.so.6. > I'd like to determine its dependencies. Unfortunately, > libstdc++.so.6 exists in more than one place in the filesystem: > maciej at build8s [build8s]:~ > ls -l /opt/csw/{,gcc4/}lib/libstdc++.so.6 > lrwxrwxrwx 1 root other 19 May 11 2009 > /opt/csw/gcc4/lib/libstdc++.so.6 -> libstdc++.so.6.0.10 > lrwxrwxrwx 1 root other 20 Aug 7 11:50 > /opt/csw/lib/libstdc++.so.6 -> ./libstdc++.so.6.0.3 > How am I supposed to tell which one is the right one? The one that was used to build it. /opt/csw/lib/libstdc++.so.6 comes with gcc3 /opt/csw/gcc4/lib/libstdc++.so.6.0.10 come with gcc4 ldd shows which will be used and served with a side dish of -s explains why. The one that will be used isn't always right due to changes/bugs in gcc4. Compare this output from 2 different installations: $ ldd /opt/csw/bin/aspell libaspell.so.15 => /opt/csw/lib/libaspell.so.15 libcurses.so.1 => /lib/libcurses.so.1 libdl.so.1 => /lib/libdl.so.1 libstdc++.so.6 => /opt/csw/gcc4/lib/libstdc++.so.6 libintl.so.3 => /opt/csw/lib/libintl.so.3 libiconv.so.2 => /opt/csw/lib/libiconv.so.2 libm.so.1 => /lib/libm.so.1 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1 libgcc_s.so.1 (GCC_4.3.0) => (version not found) libm.so.2 => /lib/libm.so.2 /platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1 $ ldd /opt/csw/bin/aspell libaspell.so.15 => /opt/csw/lib/libaspell.so.15 libcurses.so.1 => /usr/lib/libcurses.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libstdc++.so.6 => /opt/csw/lib/libstdc++.so.6 libintl.so.3 => /opt/csw/lib/libintl.so.3 libiconv.so.2 => /opt/csw/lib/libiconv.so.2 libm.so.1 => /usr/lib/libm.so.1 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1 /usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1 Ref: http://www.opencsw.org/bugtrack/view.php?id=4040 From rupert at opencsw.org Thu Dec 24 11:24:23 2009 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 24 Dec 2009 11:24:23 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <4B3149F9.5060109@opencsw.org> References: <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> <4B3149F9.5060109@opencsw.org> Message-ID: <6af4270912240224m64ca038cld50c05b7b83929bd@mail.gmail.com> On Tue, Dec 22, 2009 at 23:36, Sebastian Kayser wrote: > Gary Law wrote on 22.12.2009 23:30: >> 2009/12/22 James Lee : >>> On 22/12/09, 16:38:53, Ben Walton wrote regarding Re: >>> [csw-maintainers] CSWcswclassutils: it wants to write in /usr: >>> >>>> What about things like CSWexim, and presumably CSWpostfix that might >>>> move /usr/lib/sendmail out of the way as part of the postinstall. >>>> CSWexim uses a prompt to handle this and has allows you to skip it. >>> They might but needn't and maybe shouldn't. >> >> +1 > > What's the alternative then? Don't do anything, put instructions in > README.CSW and let the user do whatever he wants/needs to do? that would be fine. or provide an "enable" script like debian apache does for enabling sites? rupert. From james at opencsw.org Thu Dec 24 11:27:34 2009 From: james at opencsw.org (James Lee) Date: Thu, 24 Dec 2009 10:27:34 GMT Subject: [csw-maintainers] CSWpython-rt is now deprecated In-Reply-To: References: <20091222.17435800.1351067935@gyor.oxdrove.co.uk> Message-ID: <20091224.10273400.2125556663@gyor.oxdrove.co.uk> On 22/12/09, 18:30:05, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] CSWpython-rt is now deprecated: > On Tue, Dec 22, 2009 at 5:43 PM, James Lee wrote: > > I presume you have made CSWpython-rt depend on CSWpython so there is > > no urgency to the change. > I haven't made CSWpython-rt depend on CSWpython initially, but I've > followed this suggestion and I've sent the updated CSWpython-rt to > Phil. Thanks for the change. That's save me repackaging 400MB of files. 3.2 is coming soon and I'll make the change at upgrade time. James. From rupert at opencsw.org Thu Dec 24 11:56:04 2009 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 24 Dec 2009 11:56:04 +0100 Subject: [csw-maintainers] Change the dependency from CSWpython-rt to CSWpython - decommit silvercity Message-ID: <6af4270912240256g701aaa1t9fbea5e051702ec8@mail.gmail.com> hi, is it possible to remove / decommit silvercity instead of fixing it? it was there because of trac, but they changed their mind quite a while ago, see http://trac.edgewall.org/wiki/SilverCity. rupert. ---------- Forwarded message ---------- From: Mantis Bug Tracker Date: Tue, Dec 22, 2009 at 18:19 Subject: [trac 0004091]: Change the dependency from CSWpython-rt to CSWpython To: rupert at opencsw.org The following issue has been SUBMITTED. ====================================================================== http://www.opencsw.org/bugtrack/view.php?id=4091 ====================================================================== Reported By: ? ? ? ? ? ? ? ?maciej Assigned To: ====================================================================== Project: ? ? ? ? ? ? ? ? ? ?trac Issue ID: ? ? ? ? ? ? ? ? ? 4091 Category: ? ? ? ? ? ? ? ? ? packaging Reproducibility: ? ? ? ? ? ?always Severity: ? ? ? ? ? ? ? ? ? major Priority: ? ? ? ? ? ? ? ? ? normal Status: ? ? ? ? ? ? ? ? ? ? new ====================================================================== Date Submitted: ? ? ? ? ? ? 2009-12-22 18:19 CET Last Modified: ? ? ? ? ? ? ?2009-12-22 18:19 CET ====================================================================== Summary: ? ? ? ? ? ? ? ? ? ?Change the dependency from CSWpython-rt to CSWpython Description: Executive summary: CSWpython-rt is deprecated, please re-point your dependencies at CSWpython. ====================================================================== From phil at bolthole.com Thu Dec 24 18:27:22 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Dec 2009 09:27:22 -0800 Subject: [csw-maintainers] Change the dependency from CSWpython-rt to CSWpython - decommit silvercity In-Reply-To: <6af4270912240256g701aaa1t9fbea5e051702ec8@mail.gmail.com> References: <6af4270912240256g701aaa1t9fbea5e051702ec8@mail.gmail.com> Message-ID: On Thu, Dec 24, 2009 at 2:56 AM, rupert THURNER wrote: > hi, > > is it possible to remove / decommit silvercity instead of fixing it? > it was there because of trac, but they changed their mind quite a > while ago, see http://trac.edgewall.org/wiki/SilverCity. > huh. well, if silvercity was only in our packages because of trac, and if trac no longer uses it... then yes it is possible. however... Im' confused.. we donthave a pygments package... ? > rupert. > > > > ---------- Forwarded message ---------- > From: Mantis Bug Tracker > Date: Tue, Dec 22, 2009 at 18:19 > Subject: [trac 0004091]: Change the dependency from CSWpython-rt to CSWpython > To: rupert at opencsw.org > > > > The following issue has been SUBMITTED. > ====================================================================== > http://www.opencsw.org/bugtrack/view.php?id=4091 > ====================================================================== > Reported By: ? ? ? ? ? ? ? ?maciej > Assigned To: > ====================================================================== > Project: ? ? ? ? ? ? ? ? ? ?trac > Issue ID: ? ? ? ? ? ? ? ? ? 4091 > Category: ? ? ? ? ? ? ? ? ? packaging > Reproducibility: ? ? ? ? ? ?always > Severity: ? ? ? ? ? ? ? ? ? major > Priority: ? ? ? ? ? ? ? ? ? normal > Status: ? ? ? ? ? ? ? ? ? ? new > ====================================================================== > Date Submitted: ? ? ? ? ? ? 2009-12-22 18:19 CET > Last Modified: ? ? ? ? ? ? ?2009-12-22 18:19 CET > ====================================================================== > Summary: ? ? ? ? ? ? ? ? ? ?Change the dependency from CSWpython-rt to CSWpython > Description: > Executive summary: CSWpython-rt is deprecated, please re-point your > dependencies at CSWpython. > > ====================================================================== > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers From maciej at opencsw.org Thu Dec 24 19:46:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 24 Dec 2009 18:46:46 +0000 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing Message-ID: I've spent some time hacking away at checkpkg, the one to which I have write access. I've created a v2-checkpkg branch in gar and re-implemented the part of checkpkg which analyzes shared library dependencies. My implementation takes into account the RPATH set in the analyzed shared libraries, which allows it to correctly identify GCC runtime dependencies. To test it, set the svn:externals property on the 'trunk' directory to https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2-checkpkg The output of the modified checkpkg is slightly different. When it checks multiple packages, it prints the dependency report at the end of the run, reporting each package in a separate section. For example: CSWgnupg-agent: SUGGESTION: you may want to add some or all of the following as depends: (Feel free to ignore SUNW or SPRO packages) > SUNWcsl The following dependencies might be unnecessary: < CSWpinentry CSWgnupg2: SUGGESTION: you may want to add some or all of the following as depends: (Feel free to ignore SUNW or SPRO packages) > SUNWcsl The following dependencies might be unnecessary: < CSWlibidn < CSWosslrt < CSWgnupg-agent < CSWlibassuan The potentially unnecessary dependencies are a new feature. I'd be happy if people tested this change to see if it works with their builds. I'd also like to ask Dago for review if he's happy with the change. Here's the diff: http://tinyurl.com/yj9pgr9 I talked with Ben who was also working on a checkpkg replacement. He didn't mind me coding up an update to checkpkg, and offered his code if I wanted to use it. I've looked at it and I think there's a large portion of design views that we share, and I think that I'll be able to use some parts of his code. The main difference in approach is that Ben wanted to remove the existing code and deploy a complete rewrite. I took a more gradual approach, where I started to make smaller changes, which allow to gradually replace old code with new one. It also allows to easily write new, isolated tests which don't need any changes to the main checkpkg code. I've tested my new code against a number of builds, but I guess there will be some corner cases, and the sooner we find them, the better. If there are no objections, I'll merge the change to the v2 branch in few days. Maciej From phil at bolthole.com Thu Dec 24 19:59:56 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Dec 2009 10:59:56 -0800 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Thu, Dec 24, 2009 at 10:46 AM, Maciej (Matchek) Blizinski wrote: > I've spent some time hacking away at checkpkg, the one to which I have > write access. ?I've created a v2-checkpkg branch in gar and > re-implemented the part of checkpkg which analyzes shared library > dependencies. ?My implementation takes into account the RPATH set in > the analyzed shared libraries, which allows it to correctly identify > GCC runtime dependencies. >...(n more!) Wow, great! I'm really glad someone has sat down to code this. Thanks From james at opencsw.org Fri Dec 25 13:18:42 2009 From: james at opencsw.org (James Lee) Date: Fri, 25 Dec 2009 12:18:42 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <1261571233-sup-6117@ntdws12.chass.utoronto.ca> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> <1261505240-sup-8636@ntdws12.chass.utoronto.ca> <20091223.9283900.1782552105@gyor.oxdrove.co.uk> <1261571233-sup-6117@ntdws12.chass.utoronto.ca> Message-ID: <20091225.12184200.360440408@gyor.oxdrove.co.uk> On 23/12/09, 12:40:11, Ben Walton wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > > However, it does work, this gets to my normal IMAP account on another > > zone/machine with exim but using sendmail as the first local hop: > ...but this is only by chance, and is site/setup dependent. It's not chance, I know it works. > What if > you only allow relay internally using LMTP or submission(587) w/tls? I don't, which isn't chance either. > Your setup would then fail unless you also maintained a separate > sendmail config...at which point, No, it's the default sendmail config used to relay the dregs one hop only. Not ideal but it's my comprise solution that works. > Two mailers is just plain broken. A bug, if you will. Risking the wrath of the Unix gods, anyone using /usr/lib/sendmail directly deserves to fail. James. From pfelecan at opencsw.org Fri Dec 25 17:10:21 2009 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 25 Dec 2009 17:10:21 +0100 Subject: [csw-maintainers] the catalog is corrupted Message-ID: The catalog is corrupted since yesterday: - the catalog shows (end of lines trimmed): openssh 5.3,REV=2009.10.10_rev=p1 CSWossh openssh-5.3,REV=2009.10.10_rev=p1-SunOS5.8-i386-CSW.pkg.gz openssh_client 5.3,REV=2009.10.10_rev=p1 CSWosshclient openssh_client-5.3,REV=2009.10.10_rev=p1-SunOS5.8-i386-CSW.pkg.gz - the file system shows: openssh-5.3p1,REV=2009.12.16-SunOS5.8-i386-CSW.pkg.gz openssh_client-5.3p1,REV=2009.12.16-SunOS5.8-i386-CSW.pkg.gz -- Peter From maciej at opencsw.org Fri Dec 25 18:05:19 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 25 Dec 2009 17:05:19 +0000 Subject: [csw-maintainers] the catalog is corrupted In-Reply-To: References: Message-ID: On Fri, Dec 25, 2009 at 4:10 PM, Peter FELECAN wrote: > The catalog is corrupted since yesterday: I saw the same thing. There was also an anomaly in the GPG signature near the top of the file. - -----BEGIN instead of: -----BEGIN From bonivart at opencsw.org Fri Dec 25 19:43:19 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 25 Dec 2009 19:43:19 +0100 Subject: [csw-maintainers] the catalog is corrupted In-Reply-To: References: Message-ID: <625385e30912251043r430c140dsd026640292975e95@mail.gmail.com> On Fri, Dec 25, 2009 at 6:05 PM, Maciej (Matchek) Blizinski wrote: > On Fri, Dec 25, 2009 at 4:10 PM, Peter FELECAN wrote: >> The catalog is corrupted since yesterday: > > I saw the same thing. There was also an anomaly in the GPG signature > near the top of the file. > > - -----BEGIN > > instead of: > > -----BEGIN How is the catalog produced during updates? Is it hand-edited or is it produced from a package database? I think the latter should make for a higher quality catalog and also allow for different catalog formats produced at the same time without extra effort. -- /peter From william at wbonnet.net Fri Dec 25 20:16:35 2009 From: william at wbonnet.net (William Bonnet) Date: Fri, 25 Dec 2009 20:16:35 +0100 Subject: [csw-maintainers] Merry X-Mas Message-ID: <4B350F93.9000601@wbonnet.net> Hi guys Merry Christmas everyone :) cheers W. From phil at bolthole.com Sat Dec 26 04:54:46 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 25 Dec 2009 19:54:46 -0800 Subject: [csw-maintainers] the catalog is corrupted In-Reply-To: References: Message-ID: thanks for noticing . I have refreshed catalog , pushed it out, and added an extra check in the push script From maciej at opencsw.org Sun Dec 27 02:00:29 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 27 Dec 2009 01:00:29 +0000 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) In-Reply-To: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> References: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> Message-ID: On Tue, Sep 1, 2009 at 3:32 PM, Dagobert Michelsen wrote: > (...) > I guess I'll switch package compression in GAR to pigz after > release. What's the status of pigz usage/deployment? Some packages I work with, take quite a long time to gzip. Maciej From maciej at opencsw.org Sun Dec 27 02:09:11 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 27 Dec 2009 01:09:11 +0000 Subject: [csw-maintainers] Building MySQL 5.1.x In-Reply-To: <48E837C1-8FC2-41D0-9379-6BEABF129BD4@opencsw.org> References: <48E837C1-8FC2-41D0-9379-6BEABF129BD4@opencsw.org> Message-ID: On Fri, Dec 4, 2009 at 11:03 AM, Dagobert Michelsen wrote: > Hi Maciej, > >> libtool: Version mismatch error. ?This is libtool 2.2.6, but the >> libtool: definition of this LT_INIT comes from libtool 2.2.6b. >> libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 >> libtool: and run autoconf again. >> gmake[4]: *** [conf_to_src] Error 63 >> gmake[4]: *** Waiting for unfinished jobs.... >> gmake[4]: Leaving directory >> >> `/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/strings' >> >> This is a completely clean build, no preexisting files. ?Has anyone >> seen this problem before? > > *Sigh* I did update libtool to 2.2.6b a couple of days ago. > Most certainly this is the cause for the problem. However, > I don't understand why it actually *is* a problem as the > macros should only be pulled in when the autoconf-files are > regenerated. I can offer to look at the problem but won't > consider myself a libtool wizard. The problem appears to be in MySQL sources rather than our installation. Rerunning autoconf fixes the issue. Meanwhile, I've got a question about the 5.1 version: do we release CSWmysql51* as a new set of packages or do we upgrade CSWmysql5 with the 5.1 version? From rupert at opencsw.org Sun Dec 27 16:59:18 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 27 Dec 2009 16:59:18 +0100 Subject: [csw-maintainers] Building MySQL 5.1.x In-Reply-To: References: <48E837C1-8FC2-41D0-9379-6BEABF129BD4@opencsw.org> Message-ID: <6af4270912270759n100696e2r45e2d5fd940814ed@mail.gmail.com> On Sun, Dec 27, 2009 at 02:09, Maciej (Matchek) Blizinski wrote: > On Fri, Dec 4, 2009 at 11:03 AM, Dagobert Michelsen wrote: >> Hi Maciej, >> >>> libtool: Version mismatch error. ?This is libtool 2.2.6, but the >>> libtool: definition of this LT_INIT comes from libtool 2.2.6b. >>> libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 >>> libtool: and run autoconf again. >>> gmake[4]: *** [conf_to_src] Error 63 >>> gmake[4]: *** Waiting for unfinished jobs.... >>> gmake[4]: Leaving directory >>> >>> `/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/strings' >>> >>> This is a completely clean build, no preexisting files. ?Has anyone >>> seen this problem before? >> >> *Sigh* I did update libtool to 2.2.6b a couple of days ago. >> Most certainly this is the cause for the problem. However, >> I don't understand why it actually *is* a problem as the >> macros should only be pulled in when the autoconf-files are >> regenerated. I can offer to look at the problem but won't >> consider myself a libtool wizard. > > The problem appears to be in MySQL sources rather than our > installation. ?Rerunning autoconf fixes the issue. > > Meanwhile, I've got a question about the 5.1 version: do we release > CSWmysql51* as a new set of packages or do we upgrade CSWmysql5 with > the 5.1 version? the upgrade and incompatible change list is quite impressing: http://dev.mysql.com/doc/refman/5.1/en/upgrading-from-previous-series.html rupert. From phil at bolthole.com Mon Dec 28 15:24:56 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Dec 2009 06:24:56 -0800 Subject: [csw-maintainers] vacation, package releases... Message-ID: <20091228142456.GA61726@bolthole.com> Please note; I'll be going on a bit of a vacation today, so package releases will be slow at best. For anything *critical* that needs to be released, please nudge James. Otherwise, you might wait until friday. From maciej at opencsw.org Mon Dec 28 17:05:24 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 28 Dec 2009 16:05:24 +0000 Subject: [csw-maintainers] GAR: isaexec symlink loop Message-ID: I ran a MySQL 5.0 build and I've taken a look at the symlink/isaexec structure. > grep mysqlimport work/solaris8-sparc/build-global/CSWmysql5client.prototype-sparc s none /opt/csw/bin/mysqlimport=../mysql5/bin/mysqlimport l none /opt/csw/mysql5/bin/mysqlimport=/opt/csw/bin/isaexec 0755 root bin f none /opt/csw/mysql5/bin/sparcv8/mysqlimport=/opt/csw/mysql5/bin/mysqlimport 0755 root bin f none /opt/csw/mysql5/bin/sparcv9/mysqlimport 0755 root bin f none /opt/csw/mysql5/share/man/man1/mysqlimport.1 0644 root bin Let's consider a sparcv8 system. We want to execute "mysqlimport". /opt/csw/bin/mysqlimport is a symlink to /opt/csw/mysql5/bin/mysqlimport, which is a symlink to /opt/csw/bin/isaexec, which will attempt to execute /opt/csw/mysql5/bin/sparcv8/mysqlimport. All would be good if /opt/csw/mysql5/bin/sparcv8/mysqlimport was a binary, but it's a symlink to /opt/csw/mysql5/bin/mysqlimport (which is a symlink to isaexec). It looks to me as if there was a circle of symlinks. Isaexec would basically try to run itself. The sparcv9 binary runs fine, because /opt/csw/mysql5/bin/sparcv9/mysqlimport is an actual binary, not a symlink. Dago, what do you think? Is there a problem during merge? The code is at https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.0.x Maciej From skayser at opencsw.org Mon Dec 28 23:35:39 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 28 Dec 2009 23:35:39 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: <20091221152001.GH7667@sebastiankayser.de> <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> <4B30033B.6000404@opencsw.org> Message-ID: <4B3932BB.6030807@opencsw.org> Dagobert Michelsen wrote on 22.12.2009 14:27: > Am 22.12.2009 um 00:22 schrieb Sebastian Kayser: >>> Sebastian, would you mind giving it a look? >> My time is limited also (will be away most of the holidays), but I >> will >> have a look. IIRC I even spotted a full blown CPAN-to-build- >> description >> utility within another distro. Might well be suitable/adjustable for >> our >> purposes. What sort of time pressure do we have with the perl upgrade? > > Well, the Perl in current is broken to the point that some packages > can't be compiled due to conflict in current vs. shipped MakeMaker. Perl > 5.10.1 solves this, so timely shipping would certainly be good. > > BTW, the cpan2pkg script I mentioned is based on the script you cited, > but already has all the stuff from CSW in it with the exception of > producing packages instead of GAR Makefiles. Time flies. Will be away until the 02.01. and didn't get to do anything aside from the "family schedule" so far, sorry. If anyone feels like hacking away on the cpan2pkg/cpan2gar script in the meantime, please give it a go. Dago, for reference purposes, was this script inspired by Gentoo's g-cpan [1] or something else? Couldn't find a reference in the script itself. Sebastian [1] http://www.gentoo.org/proj/en/perl/g-cpan.xml From maciej at opencsw.org Wed Dec 30 00:58:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 29 Dec 2009 23:58:47 +0000 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Thu, Dec 24, 2009 at 6:59 PM, Philip Brown wrote: > On Thu, Dec 24, 2009 at 10:46 AM, Maciej (Matchek) Blizinski > wrote: >> I've spent some time hacking away at checkpkg, the one to which I have >> write access. ?I've created a v2-checkpkg branch in gar and >> re-implemented the part of checkpkg which analyzes shared library >> dependencies. ?My implementation takes into account the RPATH set in >> the analyzed shared libraries, which allows it to correctly identify >> GCC runtime dependencies. >>...(n more!) > > Wow, great! > > I'm really glad someone has sat down to code this. Thanks It needed a fair bit of work to get it to work properly. I used my MySQL and PostgreSQL builds to test it some more, and squashed more bugs. Two main things I've added since: 1. expanding the $ISALIST from the runtime search path 2. emulating the /opt/csw/lib/64 --> amd64 symlink There are also smaller changes, mainly related to the output formatting. For instance, the most basic SUNW libraries aren't reported as missing, since they're needed by virtually any package, so they don't carry any signal; they're noise. Here's a sample output from the current version: libmysqlclient.so.15 is provided by the package itself libCstd.so.1 is provided by u'*SUNWlibC' and required by: mysql mysql_tzinfo_to_sql mysqladmin mysqlbinlog mysqld mysqlmanager libCrun.so.1 is provided by u'*SUNWlibC' and required by: mysql mysql_tzinfo_to_sql mysqladmin mysqlbinlog mysqld mysqlmanager librt.so.1 is provided by u'SUNWcsl' and required by: comp_err innochecksum libmysqlclient.so.15.0.0 my_print_defaults myisam_ftdump myisamchk myisamlog myisampack mysql mysql_client_test mysql_tzinfo_to_sql mysql_upgrade mysql_waitpid mysqladmin mysqlbinlog mysqlcheck mysqld mysqldump mysqlimport mysqlmanager mysqlshow mysqltest mysqltestmanager-pwgen mysqltestmanagerc perror replace resolve_stack_dump (...) CSWmysql5rt: + Dependencies of CSWmysql5rt look good. CSWmysql5client: + Dependencies of CSWmysql5client look good. CSWmysql5: The following packages might be unnecessary dependencies: ? CSWmysql5client The reason why it thinks that CSWmysql5 might not need to depend on CSWmysql5client is that there are no libraries in CSWmysql5client that CSWmysql5 would use. We know that if one runs a server, client binaries are also necessary. There's no obvious way in which this could be automated. Other dependencies can be automated, for instance the checker will guess that CSWfoo-devel should depend on CSWfoo, and will suggest adding the dependency. The main worry I have about the code is that has grew in line count beyond what I initially anticipated, and I doubt that it's easy to understand at the first glance. There is a number of unit tests, which should make code refactoring easier. I have one more bit to implement: checking the data modification timestamp of /var/sadm/install/contents and updating the cache. I should be able to implement it this week. I'd be interested to hear if anybody has tested this code. It should make the biggest difference when used with packages built with gcc. Maciej From dam at opencsw.org Thu Dec 31 12:59:06 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 31 Dec 2009 12:59:06 +0100 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) In-Reply-To: References: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> Message-ID: Hi Maciej, Am 27.12.2009 um 02:00 schrieb Maciej (Matchek) Blizinski: > On Tue, Sep 1, 2009 at 3:32 PM, Dagobert Michelsen > wrote: >> (...) >> I guess I'll switch package compression in GAR to pigz after >> release. > > What's the status of pigz usage/deployment? Some packages I work with, > take quite a long time to gzip. It works fine. The place to patch would be bin/mkpackage. I guess it would be best to add usepigz as extra option, but I haven't gotten around to do so. Would you mind patching it in? Best regards -- Dago From trygvis at opencsw.org Thu Dec 31 13:11:33 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Thu, 31 Dec 2009 13:11:33 +0100 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) In-Reply-To: References: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> Message-ID: <4B3C94F5.1080302@opencsw.org> Dagobert Michelsen wrote: > Hi Maciej, > > Am 27.12.2009 um 02:00 schrieb Maciej (Matchek) Blizinski: >> On Tue, Sep 1, 2009 at 3:32 PM, Dagobert Michelsen >> wrote: >>> (...) >>> I guess I'll switch package compression in GAR to pigz after >>> release. >> >> What's the status of pigz usage/deployment? Some packages I work with, >> take quite a long time to gzip. > > It works fine. The place to patch would be bin/mkpackage. I guess it would > be best to add usepigz as extra option, but I haven't gotten around to > do so. > Would you mind patching it in? I may have asked this before, but is there really a need for compressing the packages before they're sent to testing/? I don't know how you guys work, but I always end up with a long command ala this when I'm developing packages: gunzip -f ~/opencsw/pkgs/CSWfoo-1.2.3*.tar.gz && pkgadd -d ~/opencsw/.. So the first think I'm doing after creating the package is to uncompress it, just so that I can install it. How about getting "make package" create the uncompressed package and "make package.gz" create the compressed one? -- Trygve From dam at opencsw.org Thu Dec 31 13:19:54 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 31 Dec 2009 13:19:54 +0100 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) In-Reply-To: <4B3C94F5.1080302@opencsw.org> References: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> <4B3C94F5.1080302@opencsw.org> Message-ID: <243BFE5C-E361-4A91-85B3-7977BC5CCFEF@opencsw.org> Hi Trygve, Am 31.12.2009 um 13:11 schrieb Trygve Laugst?l: > Dagobert Michelsen wrote: >> Hi Maciej, >> Am 27.12.2009 um 02:00 schrieb Maciej (Matchek) Blizinski: >>> On Tue, Sep 1, 2009 at 3:32 PM, Dagobert Michelsen >>> wrote: >>>> (...) >>>> I guess I'll switch package compression in GAR to pigz after >>>> release. >>> >>> What's the status of pigz usage/deployment? Some packages I work >>> with, >>> take quite a long time to gzip. >> It works fine. The place to patch would be bin/mkpackage. I guess >> it would >> be best to add usepigz as extra option, but I haven't gotten around >> to do so. >> Would you mind patching it in? > > I may have asked this before, but is there really a need for > compressing the packages before they're sent to testing/? > > I don't know how you guys work, but I always end up with a long > command ala this when I'm developing packages: > > gunzip -f ~/opencsw/pkgs/CSWfoo-1.2.3*.tar.gz && pkgadd -d ~/ > opencsw/.. > > So the first think I'm doing after creating the package is to > uncompress it, just so that I can install it. How about getting > "make package" create the uncompressed package and "make package.gz" > create the compressed one? That would mean the package delivery script to newpkgs/ from Maciej would do the compression on the fly? Maybe we should talk about the general workflow in conjunction with this: Best regards -- Dago From trygvis at opencsw.org Thu Dec 31 13:47:23 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Thu, 31 Dec 2009 13:47:23 +0100 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) In-Reply-To: <243BFE5C-E361-4A91-85B3-7977BC5CCFEF@opencsw.org> References: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> <4B3C94F5.1080302@opencsw.org> <243BFE5C-E361-4A91-85B3-7977BC5CCFEF@opencsw.org> Message-ID: <4B3C9D5B.7040702@opencsw.org> Dagobert Michelsen wrote: > Hi Trygve, > > Am 31.12.2009 um 13:11 schrieb Trygve Laugst?l: >> Dagobert Michelsen wrote: >>> Hi Maciej, >>> Am 27.12.2009 um 02:00 schrieb Maciej (Matchek) Blizinski: >>>> On Tue, Sep 1, 2009 at 3:32 PM, Dagobert Michelsen >>>> wrote: >>>>> (...) >>>>> I guess I'll switch package compression in GAR to pigz after >>>>> release. >>>> >>>> What's the status of pigz usage/deployment? Some packages I work with, >>>> take quite a long time to gzip. >>> It works fine. The place to patch would be bin/mkpackage. I guess it >>> would >>> be best to add usepigz as extra option, but I haven't gotten around >>> to do so. >>> Would you mind patching it in? >> >> I may have asked this before, but is there really a need for >> compressing the packages before they're sent to testing/? >> >> I don't know how you guys work, but I always end up with a long >> command ala this when I'm developing packages: >> >> gunzip -f ~/opencsw/pkgs/CSWfoo-1.2.3*.tar.gz && pkgadd -d ~/opencsw/.. >> >> So the first think I'm doing after creating the package is to >> uncompress it, just so that I can install it. How about getting "make >> package" create the uncompressed package and "make package.gz" create >> the compressed one? > > That would mean the package delivery script to newpkgs/ from Maciej > would do the compression on the fly? Maybe we should talk about > the general workflow in conjunction with this: > To me that would be a natural place to compress stuff. It's also quite possible to script the moving from testing/ to testing-compressed/ so that the maintainer doesn't have to do anything (nor do we have to create extra scripts for it). -- Trygve From bwalton at opencsw.org Thu Dec 31 14:45:57 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 31 Dec 2009 08:45:57 -0500 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) In-Reply-To: <4B3C94F5.1080302@opencsw.org> References: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> <4B3C94F5.1080302@opencsw.org> Message-ID: <1262266971-sup-128@ntdws12.chass.utoronto.ca> Excerpts from Trygve Laugst?l's message of Thu Dec 31 07:11:33 -0500 2009: > I don't know how you guys work, but I always end up with a long command > ala this when I'm developing packages: > > gunzip -f ~/opencsw/pkgs/CSWfoo-1.2.3*.tar.gz && pkgadd -d > ~/opencsw/.. I do this, but typically only after a: scp login.bo:staging/CSWfoo-1.2.3*.tar.gz . I don't usually build locally at all since I don't have any sol8 dev boxes and I prefer to do all of my building there first to shake out bugs that might not be found in 10. For some packages, not being zipped would be fine. For others, this would add to my transfer time significantly. I think I'd still upvote the change though, as overall, it makes more sense. Compress for release. It would have a side benefit of making checkpkg faster since it wouldn't need to unzip each package being inspected either. -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 rupert at opencsw.org Thu Dec 31 17:56:01 2009 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 31 Dec 2009 17:56:01 +0100 Subject: [csw-maintainers] how to use the gnu linker? or is there anything else what can be done? Message-ID: <6af4270912310856jdca43b9s5361db04adf5d72d@mail.gmail.com> when trying to build lzip lzlib linking does not work. how can one correct this? rupert at build8s:~/mgar/pkg/lzlib/trunk $ gmake package [===== NOW BUILDING: lzlib-0.8-rc1 =====] [prerequisite] complete for lzlib. [fetch] complete for lzlib. [checksum] complete for lzlib. [checksum-global] complete for lzlib. [checksum-modulated] complete for lzlib. [===== NOW BUILDING: lzlib-0.8-rc1 MODULATION global: ISA= =====] [extract-modulated] complete for lzlib. [===== Building modulation 'isa-sparcv8' on host 'build8s' =====] gmake PLATFORM=solaris8-sparc MODULATION=isa-sparcv8 ISA=sparcv8 merge-modulated gmake[1]: Entering directory `/home/rupert/mgar/pkg/lzlib/trunk' [===== NOW BUILDING: lzlib-0.8-rc1 MODULATION isa-sparcv8: ISA=sparcv8 =====] [extract-modulated] complete for lzlib. [patch-modulated] complete for lzlib. [configure-modulated] complete for lzlib. ==> Running make in work/solaris8-sparc/build-isa-sparcv8/lzlib-0.8-rc1 gmake[2]: Entering directory `/home/rupert/mgar/pkg/lzlib/trunk/work/solaris8-sparc/build-isa-sparcv8/lzlib-0.8-rc1' c++ -shared -Wl,--soname=liblz.so.0 -o liblz.so.0.8-rc1 sh_decoder.o sh_encoder.o sh_lzlib.o /usr/ccs/bin/ld: illegal option -- - ld: warning: option -o appears more than once, first setting taken usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) From bwalton at opencsw.org Thu Dec 31 18:29:05 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 31 Dec 2009 12:29:05 -0500 Subject: [csw-maintainers] how to use the gnu linker? or is there anything else what can be done? In-Reply-To: <6af4270912310856jdca43b9s5361db04adf5d72d@mail.gmail.com> References: <6af4270912310856jdca43b9s5361db04adf5d72d@mail.gmail.com> Message-ID: <1262280366-sup-6237@ntdws12.chass.utoronto.ca> Excerpts from rupert THURNER's message of Thu Dec 31 11:56:01 -0500 2009: Hi Rupert, > c++ -shared -Wl,--soname=liblz.so.0 -o liblz.so.0.8-rc1 sh_decoder.o > sh_encoder.o sh_lzlib.o > /usr/ccs/bin/ld: illegal option -- - > ld: warning: option -o appears more than once, first setting taken > usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) I think what you're seeing here is actually some gcc options being passed to the compiler regardless of the fact you're not using gcc. These are likely hard coded in a Makefile somewhere. I'd suggest first trying GARCOMPILER = GCC4 before trying to make it use gld for linking. Trying to use gld will be an exercise in frustration, so hopefully you don't need to go there. Alternately, you can track down where the bad options sneak in and correct that instead. 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 rupert at opencsw.org Thu Dec 31 18:34:01 2009 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 31 Dec 2009 18:34:01 +0100 Subject: [csw-maintainers] how to use the gnu linker? or is there anything else what can be done? In-Reply-To: <1262280366-sup-6237@ntdws12.chass.utoronto.ca> References: <6af4270912310856jdca43b9s5361db04adf5d72d@mail.gmail.com> <1262280366-sup-6237@ntdws12.chass.utoronto.ca> Message-ID: <6af4270912310934p2a8f9bb9r104b102b49558d4a@mail.gmail.com> On Thu, Dec 31, 2009 at 18:29, Ben Walton wrote: > Excerpts from rupert THURNER's message of Thu Dec 31 11:56:01 -0500 2009: > > Hi Rupert, > >> c++ -shared -Wl,--soname=liblz.so.0 -o liblz.so.0.8-rc1 sh_decoder.o >> sh_encoder.o sh_lzlib.o >> /usr/ccs/bin/ld: illegal option -- - >> ld: warning: option -o appears more than once, first setting taken >> usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) > > I think what you're seeing here is actually some gcc options being > passed to the compiler regardless of the fact you're not using gcc. > These are likely hard coded in a Makefile somewhere. ?I'd suggest > first trying GARCOMPILER = GCC4 before trying to make it use gld for > linking. ?Trying to use gld will be an exercise in frustration, so > hopefully you don't need to go there. i am using GARCOMPILER = GCC, is this different? i think the options are hardcoded, yes. therefor i thought gld might fix this - and it would be easy :) rupert. From rupert at opencsw.org Thu Dec 31 19:04:53 2009 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 31 Dec 2009 19:04:53 +0100 Subject: [csw-maintainers] clean without cleaning the downloaded file, unpackaged file ? Message-ID: <6af4270912311004k73ae3a67m677af8f684c931fc@mail.gmail.com> how can the build result can be cleaned without deleting the downloaded file, or maybe even avoiding unzipping it again? i try to build qt4 as base for kde4, and the download is more than 100 mb. as i got an error on build8s, i also tried to build on build10s, and i am wondering if it is correct that it says "sparvc8": rupert at build10s:~/mgar/pkg/qt4/trunk $ gmake package gar/gar.pkg.mk:682: *** You are building this package on a non-requested platform host 'build10s'. The follow platforms were requested: gar/gar.pkg.mk:682: *** - solaris8-sparc to be build on host 'build8s' rupert at build10s:~/mgar/pkg/qt4/trunk $ gmake build gmake[1]: Entering directory `/home/rupert/mgar/pkg/qt4/trunk' gmake -s MODULATION=global checksum gmake[2]: Entering directory `/home/rupert/mgar/pkg/qt4/trunk' [===== NOW BUILDING: qt4-4.6.0 =====] ... ==> Running configure in work/build-isa-sparcv8/qt-everywhere-opensource-src-4.6.0 rupert. From dam at opencsw.org Tue Dec 1 09:37:44 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Dec 2009 09:37:44 +0100 Subject: [csw-maintainers] Major cleanup of testing/ In-Reply-To: References: Message-ID: Hi Phil, Am 30.11.2009 um 18:45 schrieb Philip Brown: > leave the samba ones please. they're useful, even though they arent > "official". > i did a very nice "proof of concept" thing with them at my work last > month with them. Could you please repackage it with a sane name? Best regards -- Dago From dam at opencsw.org Tue Dec 1 09:46:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Dec 2009 09:46:55 +0100 Subject: [csw-maintainers] New members welcome! Message-ID: Hi, the association welcomes the newly accepted members - Rupert Thurner Rupert already maintains packages including often-requested Mercurial and Trac. Please keep in mind that being a maintainer is not only about fame and glory, but also about tedious work to make the packages as good as possible and remove bugs timely when discovered. Please check regularly at the bottom of your maintainer page if there are any open issues. If you have spare cycles please adopt an orphaned package and help bring the complete software stack to a 100% current state. But enough of morality: A very warm welcome! Your membership is tracked at Please let me know on what are you working or are planning to work like "webpage", "maintainer", etc. Best regards -- Dago From dam at opencsw.org Tue Dec 1 09:53:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Dec 2009 09:53:32 +0100 Subject: [csw-maintainers] Possible splitting of liba52 and mpeg2dec In-Reply-To: References: <2CECC2D9-CA37-4C37-B694-39F6A2101AD9@opencsw.org> <4CAB987C-7DB3-4F97-BC16-E86DC3DEA80D@gmail.com> <1BB4AC5F-7708-4B2F-A96A-A26D5C8E1035@opencsw.org> Message-ID: <3E8DB3D0-21FC-4BFF-A557-46D282F45D61@opencsw.org> Hi Phil, Am 30.11.2009 um 18:06 schrieb Philip Brown: > On Sat, Nov 28, 2009 at 12:22 AM, Dagobert Michelsen > wrote: >> liba52-0.7.4,REV=2009.11.28-SunOS5.8-i386-CSW.pkg.gz >> liba52-0.7.4,REV=2009.11.28-SunOS5.8-sparc-CSW.pkg.gz > > Got it, thanks After some more thought I guess it would be good to split off the a52dec part. The library is from the same project as mpeg2dec, which recently changed the name to libmpeg2: The plan it to factor out the binaries (which will only be used by a fraction of users) in mpeg2dec a52dec and let them depend on libmpeg2 liba52 This way existing packages which depend on *dec won't break (which is CSWvlc only anyway which only uses the lib). Currently we have mpeg2dec CSWmpeg2dec liba52 CSWliba52 being not that much consistent. Best regards -- Dago From dam at opencsw.org Tue Dec 1 11:11:42 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Dec 2009 11:11:42 +0100 Subject: [csw-maintainers] Important change to GAR: include flags no longer passed to CFLAGS/CXXFLAGS Message-ID: <5818E604-12F2-45FD-8ECF-CC5DFAF905B5@opencsw.org> Hi, as discusses earlier the INCLUDE_FLAGS (-I...) are no longer passed to CFLAGS and CXXFLAGS, but only to CPPFLAGS starting with r7514. Additionally, I have added a new section "Important changes to GAR" on the GAR frontpage to list bugfixes that may break existing builds: Best regards -- Dago From dam at opencsw.org Tue Dec 1 14:42:08 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Dec 2009 14:42:08 +0100 Subject: [csw-maintainers] Replacing existing Solaris functionality by OpenCSW packages In-Reply-To: References: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> Message-ID: Hi, Am 24.11.2009 um 17:32 schrieb Philip Brown: > On Tue, Nov 24, 2009 at 7:54 AM, Dagobert Michelsen > wrote: >> >> ... >> As there is a "install all" option in pkg-get which is used it >> is adviseable to not install these replacemenet-packages by >> default. This may be accomplished by one of the following >> solutions: >> >> - Different [SVR4 pkg] prefix >> >> The addons would be named CSWX... to mark that they are Xtra >> to install. >> ... >> >> - Different catalog >> >> The extra packages may be put in a separate catalog. >> ... > > Or by other methods. > > Such as defining additional standard global configs to go in csw.conf > > "replace_sun_pkgs=yes" > or some such? > > Then a postinstall script could check for that, and > rename/disable/replace/whatever as appropriate. > > I suppose we might even support different values. > > replace_sun_pkgs={replace,rename,???} > > (where one could mean simple "mv old binaries to .old", and another > might be "actually put in symlink to our binaries, and yet another > could mean "pkgrm conflicting") No feedback for over a week. Maciej, what would you prefer? Peter, what do you think about a special pkgutil-mode instead of the csw.conf directive? Best regards -- Dago From bonivart at opencsw.org Tue Dec 1 14:49:11 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 1 Dec 2009 14:49:11 +0100 Subject: [csw-maintainers] Replacing existing Solaris functionality by OpenCSW packages In-Reply-To: References: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> Message-ID: <625385e30912010549o53175168x9da74912d5d23e92@mail.gmail.com> On Tue, Dec 1, 2009 at 2:42 PM, Dagobert Michelsen wrote: > Peter, what do you think about a special pkgutil-mode instead of the > csw.conf directive? I don't want to implement any special handling, that's bound to be a mess in the future. I think we should solve this with methods already defined and used, in this case a separate repo could be used just like, e.g., Ubuntu does it with things not belonging in the default repos. An option in csw.conf also gives the power to the end-user but in a more complicated way. -- /peter From phil at bolthole.com Tue Dec 1 17:40:05 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 1 Dec 2009 08:40:05 -0800 Subject: [csw-maintainers] Major cleanup of testing/ In-Reply-To: References: Message-ID: On Tue, Dec 1, 2009 at 12:37 AM, Dagobert Michelsen wrote: > Hi Phil, > > Am 30.11.2009 um 18:45 schrieb Philip Brown: >> >> leave the samba ones please. they're useful, even though they arent >> "official". >> i did a very nice "proof of concept" thing with them at my work last >> month with them. > > Could you please repackage it with a sane name? > if I could find the time to repackage it properly, it wouldnt be in testing any more :-P From william at wbonnet.net Tue Dec 1 22:55:05 2009 From: william at wbonnet.net (William Bonnet) Date: Tue, 01 Dec 2009 22:55:05 +0100 Subject: [csw-maintainers] X11 packaging Message-ID: <4B1590B9.3080702@wbonnet.net> Hi, I've almost finished to build the packages from X11 7.5. These packages are installed on test8s. There are the proto files and the following : libxau libxext libdmx libpthread-stubs xtrans libfs libice libsm libxt libx11 libxv libxmu libxfixes libxcomposite libxdamage libxinerama libxpm libxaw libxft libxdmcp libfontenc libxres xrender libxkbfile libxxf86dga libxxf86vm libxvmc libxfont libxi libxtst libxscrnsaver libxcursor libxrandr libwindowswm both lib and devel I still have to do libAppleWM-1.4.0 and libpciaccess-0.10.9. But i still have a few problems to compile these packages. I will now start to rebuild FF and TB against these libs. Feel free to tests yours :) The two missing libs are not that important 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 Tue Dec 1 23:55:02 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 1 Dec 2009 14:55:02 -0800 Subject: [csw-maintainers] X11 packaging In-Reply-To: <4B1590B9.3080702@wbonnet.net> References: <4B1590B9.3080702@wbonnet.net> Message-ID: On Tue, Dec 1, 2009 at 1:55 PM, William Bonnet wrote: > Hi, > > I've almost finished to build the packages from X11 7.5. These packages are > installed on test8s. There are the proto files and the following : > > libxau > libxext > libdmx ... wow.. that's a lot! Thanks William! From dam at opencsw.org Wed Dec 2 13:36:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Dec 2009 13:36:49 +0100 Subject: [csw-maintainers] Update of T5220 tomorrow Message-ID: <2B417740-7ADB-4DF8-943A-183B1A945A9A@opencsw.org> Dear maintainers, I want to take down the T5220 tomorrow for some hardware changes (install FC HBA) and OBP/Firmware updates. The machine will probably down for the day between 10 AM MET and 5 PM MET. Sorry for the inconvenience -- Dago From dam at opencsw.org Wed Dec 2 16:05:29 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Dec 2009 16:05:29 +0100 Subject: [csw-maintainers] [csw-buildfarm] Building postgresql-8.4.1 In-Reply-To: References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <988C113A-0FD5-4D91-B3DE-8174D2620B61@opencsw.org> Message-ID: Hi Maciej, Am 02.12.2009 um 15:35 schrieb Maciej (Matchek) Blizinski: > On Mon, Nov 30, 2009 at 10:27 AM, Dagobert Michelsen > wrote: >> Hi Maciej, > >>> On build8s the tests pass just fine. Is it something that buildfarm >>> admins can fix? >> >> Yes. I need to turn up SHMMAX on build8x and reboot. As I plan to >> migrate >> that >> on the VMware farm I can just install the new one for you to test. >> Please >> allow >> me some more time to finish it. > > Sure. Please let me know when it's done. I'll build the Intel > architecture packages then. > > Meanwhile, I'd like to continue the 32/64 bit PostgreSQL discussion. > My intuition is that application should run the native architecture > binaries, unless there's a reason to do otherwise. Dago wrote, that > it makes sense to do run 64-bit binaries (where possible) by default, > when: > >> (1) using the proper width is mandatory (e.g. /dev/kmem access) >> (2) using 64 bit always has an advantage >> (3) there is difference in output between 32/64 bit > > I don't agree with the second point, because it's phrased too > strongly. 64-bit will not always be advantageous, because you can > find such data and such criteria that 32-bit binary will do better. > > I understand that for many applications there's no advantage in > running in 64-bit width, and therefore the main policy is "use 32 bit > only unless there are reasons to use 64-bit". In the case of a > database engine, there is one general reason to use 64-bit width: > databases tend to be big and run on big machines, using way more than > just 2GB of RAM. Defaulting to 32-bit is like setting up a trap. > > I understand that the two main arguments against using 64-bit by > default where possible are: > > - it consumes more memory > - it potentially runs slower > > I've got a Netra T1125 2X 440MHZ to experiment with. I've run pgbench > using sparcv8 and sparcv9 binaries. > > sparcv8 > tps = 22.976848 (including connections establishing) > tps = 23.070799 (excluding connections establishing) > > sparcv9: > tps = 25.318832 (including connections establishing) > tps = 25.481666 (excluding connections establishing) > > I also know that Dago didn't want to use isaexec, because somebody > might want to copy raw data directories between 32- and 64-bit > architecture machines. I agree that it might happen, but as far as my > database experience goes, messing with raw data directories is > generally asking for trouble. The way to get the data to or out of a > database is via database dumps, which are architecture independent. > If somebody wants replication, they should use slony. > > We could have a postinstall script which would detect and set the > architecture, but isn't it what isaexec does anyway? Yes, but on every invocation. You can execute the postinstall selecting 32/64 bit with isaexec for optimal selection, but the selection should be static and not be changed between invocations of the database. > One more thing: using isaexec doesn't take the choice away. The user > can still set the path to the exact binary and run 32 or 64-bit > version specifically, if they want to. > > To sum up: I maintain that it's best to: > > 1. Use native architecture width by default > 2. Give the user the choice if they have a preference this or the > other way > > isaexec does both those things. > > There's another way of doing it: Force the user to choose the > architecture before they can run PostgreSQL at all. I think it would > be a user-repellent policy. It's so much nicer when the package runs > out of the box: > > pkgutil -y -i postgresql > sudo -u postgres createuser joe > createdb joe > psql > > The negative impact of the database not working out of the box would > in my opinion by greater than the positive impact of being always > conscious about whether it's possible to copy the data files between > machines with different bit width architectures. > > If people want to, I can draw another table with pros and cons. For me you can just default to 64 bit as almost all systems support it and as you said the advantage is there. Best regards -- Dago From maciej at opencsw.org Wed Dec 2 16:17:31 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 2 Dec 2009 15:17:31 +0000 Subject: [csw-maintainers] [csw-buildfarm] Building postgresql-8.4.1 In-Reply-To: References: <988C113A-0FD5-4D91-B3DE-8174D2620B61@opencsw.org> Message-ID: On Wed, Dec 2, 2009 at 3:05 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 02.12.2009 um 15:35 schrieb Maciej (Matchek) Blizinski: >> We could have a postinstall script which would detect and set the >> architecture, but isn't it what isaexec does anyway? > > Yes, but on every invocation. You can execute the postinstall selecting > 32/64 bit with isaexec for optimal selection, but the selection should > be static and not be changed between invocations of the database. Can I ask a na?ve "why"? Machine's architecture may change overnight? isaexec might become broken? I don't have any other ideas. Maciej From dam at opencsw.org Wed Dec 2 16:28:01 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Dec 2009 16:28:01 +0100 Subject: [csw-maintainers] [csw-buildfarm] Building postgresql-8.4.1 In-Reply-To: References: <988C113A-0FD5-4D91-B3DE-8174D2620B61@opencsw.org> Message-ID: Hi Maciej, Am 02.12.2009 um 16:17 schrieb Maciej (Matchek) Blizinski: > On Wed, Dec 2, 2009 at 3:05 PM, Dagobert Michelsen > wrote: >> Hi Maciej, >> >> Am 02.12.2009 um 15:35 schrieb Maciej (Matchek) Blizinski: >>> We could have a postinstall script which would detect and set the >>> architecture, but isn't it what isaexec does anyway? >> >> Yes, but on every invocation. You can execute the postinstall >> selecting >> 32/64 bit with isaexec for optimal selection, but the selection >> should >> be static and not be changed between invocations of the database. > > Can I ask a na?ve "why"? > > Machine's architecture may change overnight? isaexec might become > broken? I don't have any other ideas. You can boot a Solaris 8 and 9 Sparc in 32 or 64 bit. Yes, this is an artifical example. However, I have a very bad feeling selecting this at runtime. I just don't like the idea of copying an installation from one machine to another and it then doesn't work but I may be too picky here... Best regards -- Dago From maciej at opencsw.org Wed Dec 2 16:47:09 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 2 Dec 2009 15:47:09 +0000 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <4AF48870.2040308@opencsw.org> References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> <4AD1C002.1050409@opencsw.org> <7D96D3D3-FA0A-40E1-9549-9114E56174DC@opencsw.org> <4AF18FE6.9040703@opencsw.org> <4AF1A21C.4060201@opencsw.org> <25FB7213-E65F-4115-8DC9-50D57113E275@opencsw.org> <8853603E-D4FD-4534-8D3C-5781B3FC4286@opencsw.org> <4AF48870.2040308@opencsw.org> Message-ID: What does replatforms do? Which stages does it reset? Perhaps it would be better to have more descriptive target names, for example: gmake platforms-reconfigure gmake platforms-repackage gmake platforms-clean etc. Maciej From maciej at opencsw.org Wed Dec 2 16:55:14 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 2 Dec 2009 15:55:14 +0000 Subject: [csw-maintainers] Building MySQL 5.1.x Message-ID: I'm looking at MySQL 5.1. I'm currently experimenting with building it in /opt/csw, with the support for different versions (5.0, 5.1 and so forth). I'm starting this thread to track everything related to building and testing MySQL 5.1. I've just run into this: source='conf_to_src.c' object='conf_to_src.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../depcomp \ /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I../include -I../include -I../include -I/opt/csw/include -I/opt/csw/include/mysql5/5.1 -g -DSAFE_MUTEX -g -xarch=v8 -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 -DHAVE_CURSES_H -I/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/include -DHAVE_RWLOCK_T -DUNIV_SOLARIS -DUNIV_SOLARIS -c conf_to_src.c /bin/bash ../libtool --preserve-dup-deps --tag=CC --mode=link /opt/studio/SOS11/SUNWspro/bin/cc -g -DSAFE_MUTEX -g -xarch=v8 -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 -DHAVE_CURSES_H -I/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/include -DHAVE_RWLOCK_T -DUNIV_SOLARIS -DUNIV_SOLARIS -static -xarch=v8 -L/opt/csw/lib -L/opt/csw/lib/mysql5/5.1 -L/opt/csw/lib -o conf_to_src conf_to_src.o xml.o ctype.o bcmp.o -lpthread -lposix4 -lresolv -lc -lsocket -lnsl -lm -lpthread libtool: Version mismatch error. This is libtool 2.2.6, but the libtool: definition of this LT_INIT comes from libtool 2.2.6b. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 libtool: and run autoconf again. gmake[4]: *** [conf_to_src] Error 63 gmake[4]: *** Waiting for unfinished jobs.... gmake[4]: Leaving directory `/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/strings' This is a completely clean build, no preexisting files. Has anyone seen this problem before? Maciej From bonivart at opencsw.org Wed Dec 2 17:27:44 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 2 Dec 2009 17:27:44 +0100 Subject: [csw-maintainers] /testing postgrey Message-ID: <625385e30912020827mfc0e9dbh7a468ec2b2776b6c@mail.gmail.com> Upon request I have built postgrey, it implements greylisting in the Postfix mail server. I maintain milter-greylist which is similar and can be run on both Sendmail and Postfix but this one is Postfix only. Since I don't use Postfix I can't test this and I may not be the best maintainer for it so if you feel like maintaining it just tell me, it's in GAR so it's really simple to produce a new package. But first of all we need some people to test it, if you use Postfix I would appreciate it if you could install this and try it out. Reference: http://postgrey.schweikert.ch/ Link to package: http://mirror.opencsw.org/testing/postgrey-1.32,REV=2009.12.02-SunOS5.8-all-CSW.pkg.gz -- /peter From phil at bolthole.com Wed Dec 2 19:27:55 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 2 Dec 2009 10:27:55 -0800 Subject: [csw-maintainers] Building MySQL 5.1.x In-Reply-To: References: Message-ID: Maybe you should follow its suggestion and regenerate those files using autoconf, etc. From william at wbonnet.net Wed Dec 2 20:24:22 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 02 Dec 2009 20:24:22 +0100 Subject: [csw-maintainers] X11 packaging In-Reply-To: References: <4B1590B9.3080702@wbonnet.net> Message-ID: <4B16BEE6.9050600@wbonnet.net> Hi Phil > wow.. that's a lot! > > Thanks William! > You're welcome :) but i have to add that it is also dued since a long long time... (and i mean it was stuck on my side) 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 yann at pleiades.fr.eu.org Wed Dec 2 22:04:38 2009 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Wed, 02 Dec 2009 22:04:38 +0100 Subject: [csw-maintainers] Openssl vulnerability CVE-2009-3555 Message-ID: <4B16D666.9030804@pleiades.fr.eu.org> Hi everybody, A ssl vulnerability has been recently found in openssl, this flaw is difficult to fix because the problem lies in the renegotiation feature which is part of the protocol itself. As a result, the last openssl version disables completely tls renegotiation, which could break some setups. From what I understand, there are few setups which would be impacted but I can't be perfectly sure about that. We can either: - release openssl 0.9.8l with renegotiation disabled and warn our users. It would be nice for users who don't want to upgrade to be able to forbid a package upgrade in pkg-get / pkgutil configuration. - do not release 0.9.8l for now and release a new apache 2 / apache mod ssl / other http servers with client initiated renegotiation disabled.Wed, 02 Dec 2009 21:47:50 +0100 This should fix the vulnerability for most Apache configuration and for now only exploits on the HTTPS protocol have been documented. I was planning to do the former but I welcome advices on this matter. You will find below the email I was planning to send to our users. You can find more information about this flaw at the following urls: http://extendedsubset.com/?p=8 http://www.links.org/?p=780 http://www.links.org/?p=786 http://www.links.org/?p=789 http://www.links.org/?p=804 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 The openssl 0.9.8l packages are in testing: http://buildfarm.opencsw.org/testing/openssl_utils-0.9.8l,REV=2009.11.07-SunOS5.8-sparc-CSW.pkg.gz http://buildfarm.opencsw.org/testing/openssl_rt-0.9.8l,REV=2009.11.07-SunOS5.8-sparc-CSW.pkg.gz http://buildfarm.opencsw.org/testing/openssl_devel-0.9.8l,REV=2009.11.07-SunOS5.8-sparc-CSW.pkg.gz http://buildfarm.opencsw.org/testing/openssl_utils-0.9.8l,REV=2009.11.07-SunOS5.8-i386-CSW.pkg.gz http://buildfarm.opencsw.org/testing/openssl_rt-0.9.8l,REV=2009.11.07-SunOS5.8-i386-CSW.pkg.gz http://buildfarm.opencsw.org/testing/openssl_devel-0.9.8l,REV=2009.11.07-SunOS5.8-i386-CSW.pkg.gz Best regards, Yann --------------------------------------------------------------------------- Dear users, A security vulnerability has been recently found in the TLS and SSL protocol part related to the handling of session renegotiation [1]. This vulnerability allows an attacker to inject arbitrary content at the beginning of a TLS/SSL connection. This problem is caused by a design flaw in the TLS/SSL protocol and is difficult to fix in a clean and backward compatible way. As a result the new openssl release (0.9.8l) which fixes this bug simply completely disables renegotiation. This new package will hit csw unstable mirror very soon. This modification should not have any impact for most setups except for Apache https configurations which use certificate client verification (SSLVerifyClient) or specify a new ssl cipher list (SSLCipherSuite) in a directory or location context. If that's your case, you should try to use these instructions on the server or virtual host level, or avoid upgrading to openssl 0.9.8l, but you will stay vulnerable in the latter. A new protocol extension to TLS is planned to address this issue but the RFC draft is still under review and it will require both the client and the server to implement the extension. Best regards Yann [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 From bonivart at opencsw.org Wed Dec 2 22:56:36 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 2 Dec 2009 22:56:36 +0100 Subject: [csw-maintainers] Openssl vulnerability CVE-2009-3555 In-Reply-To: <4B16D666.9030804@pleiades.fr.eu.org> References: <4B16D666.9030804@pleiades.fr.eu.org> Message-ID: <625385e30912021356j4f3cbc96n26150d62ecedbb5e@mail.gmail.com> On Wed, Dec 2, 2009 at 10:04 PM, Yann Rouillard wrote: > ?- release openssl 0.9.8l with renegotiation disabled and warn our users. > ? It would be nice for users who don't want to upgrade to be able to forbid > a package upgrade in pkg-get / pkgutil configuration. Users of pkgutil 1.9 could add the following in pkgutil.conf: exclude_pattern=CSWossl That should skip the openssl packages. peter at opensolaris:~$ sudo pkgutil -i openssl Parsing catalog, may take a while... CURRENT packages: CSWcacertificates-20091101,REV=2009.11.01 CSWcommon-1.4.7,REV=2009.09.20 CSWcswclassutils-1.30,REV=2009.11.21 EXCLUDED packages: CSWossl CSWossldevel CSWosslrt CSWosslutils Nothing to do. peter at opensolaris:~$ -- /peter From glaw at opencsw.org Wed Dec 2 23:59:14 2009 From: glaw at opencsw.org (Gary Law) Date: Wed, 2 Dec 2009 22:59:14 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr Message-ID: Hi all Been chatting with Maciej about a bug/feature I've hit where I can't properly install CSWcswclassutils, as it wants to write in /usr, and that's mounted readonly (it's a non-global zone). Does this mean CSWcswclassutils violates policy? I thought we had to confine ourselves to /opt, /etc/opt/csw and /var/opt/csw Maciej suggested non-global zones and/or non-writable /usr aren't supported by CSW, which may be correct, but is news to me. Thoughts? Gary -- glaw at opencsw.org From bonivart at opencsw.org Thu Dec 3 00:01:57 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 3 Dec 2009 00:01:57 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: Message-ID: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> On Wed, Dec 2, 2009 at 11:59 PM, Gary Law wrote: > Hi all > > Been chatting with Maciej about a bug/feature I've hit where I can't > properly install CSWcswclassutils, as it wants to write in /usr, and > that's mounted readonly (it's a non-global zone). > > Does this mean CSWcswclassutils violates policy? I thought we had to > confine ourselves to /opt, /etc/opt/csw and /var/opt/csw > > Maciej suggested non-global zones and/or non-writable /usr aren't > supported by CSW, which may be correct, but is news to me. > > Thoughts? It's how Sun designed it. Just install that package from the global zone and be done with it. :-) -- /peter From bwalton at opencsw.org Thu Dec 3 03:49:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 02 Dec 2009 21:49:12 -0500 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> Message-ID: <1259808438-sup-9303@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Nov 26 08:59:48 -0500 2009: > On line 94 from /opt/csw/share/perl/5.8.8/ExtUtils/Install.pm it must > say > my(%from_to) = @$from_to; > I changed this only on build8s, please verify that this works. This was reverted on build8s then? Git is broken by this bug too. Peter, are you patching the CSWperl build or waiting for an upstream fix (5.8.9)? Can we manually correct the issue, as per Dago's sleuthing, in the meantime? 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. From dam at opencsw.org Thu Dec 3 10:13:36 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Dec 2009 10:13:36 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: <1259808438-sup-9303@ntdws12.chass.utoronto.ca> References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> <1259808438-sup-9303@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 03.12.2009 um 03:49 schrieb Ben Walton : > Excerpts from Dagobert Michelsen's message of Thu Nov 26 08:59:48 -0500 2009 > : > >> On line 94 from /opt/csw/share/perl/5.8.8/ExtUtils/Install.pm it must >> say >> my(%from_to) = @$from_to; > >> I changed this only on build8s, please verify that this works. > > This was reverted on build8s then? Git is broken by this bug too. > Peter, are you patching the CSWperl build or waiting for an upstream > fix (5.8.9)? > > Can we manually correct the issue, as per Dago's sleuthing, in the > meantime? Unfortunately some modules require the old line. I guess the only viable solution until 5.10.1 is to not replace the build-in module containing the file. Best regards -- Dago From skayser at opencsw.org Thu Dec 3 12:40:56 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 3 Dec 2009 12:40:56 +0100 Subject: [csw-maintainers] OpenCSW Winter Camp - 23/24 Jan 2010. Who is coming? Message-ID: <20091203114056.GA26420@sebastiankayser.de> Hi, the venue and dates are fixed. Winter Camp will get us together in a cosy seminar hotel near the Bavarian mountains on 23.01./24.01. next year. http://wiki.opencsw.org/wintercamp-2009 I have updated the wiki page with details. The hotel doesn't have a online booking system, so those of you who can make their way please send me an email (by 17.12.2009) so that I can let them know with how many people we are attending and take care of the room bookings. Except for the room rate (approx 60EUR / night for a single) everything will be covered by the company I work for, so you just need to get there. :) Any questions, just let me know. Hope to see you there. Sebastian From maciej at opencsw.org Thu Dec 3 13:31:41 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 3 Dec 2009 12:31:41 +0000 Subject: [csw-maintainers] [csw-buildfarm] Building postgresql-8.4.1 In-Reply-To: References: <988C113A-0FD5-4D91-B3DE-8174D2620B61@opencsw.org> Message-ID: On Wed, Dec 2, 2009 at 3:28 PM, Dagobert Michelsen wrote: > You can boot a Solaris 8 and 9 Sparc in 32 or 64 bit. Yes, this is > an artifical example. However, I have a very bad feeling selecting > this at runtime. I understand this gut feeling. However, there aren't any obvious failure modes (apart from the one where can run Solaris 8 in either 32 or 64 bit mode). Also, there aren't much consequences of attempting to run incompatible executable / data combinarion. I tested that; the database server just won't start up, there's an error message in the log file, you can copy the files to a machine with the right architecture, or you configure the start script to use the right binary. I'll put some information in the postinstall script, and also a README file. > I just don't like the idea of copying an > installation from one machine to another and it then doesn't work > but I may be too picky here... I think you might be too picky. I talked to a PostgreSQL developer today to ask about what practices are common for moving databases. Moving raw data files can be used, but it's only expected to work between machines of the same architecture. Otherwise dump/restore or replication can be used. Meanwhile, I put PostgreSQL 8.4.1 into testing/. It uses a different layout than the current package: - /opt/csw prefix - /opt/csw/bin/postgresql/8.4/ - /var/opt/csw/postgresql/8.4/pgdata for the data - includes contrib (pgbench, etc.) - allows to choose between 32/64 bit - uses isaexec by default Maciej From maciej at opencsw.org Thu Dec 3 15:36:31 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 3 Dec 2009 14:36:31 +0000 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: <83CED7D4-8FCB-4D9D-965F-4D8975BEEF6D@opencsw.org> Message-ID: On Thu, Nov 19, 2009 at 4:56 PM, Eric J Korpela wrote: > Sure. ?I'll do initial builds on machines here. ?I probably won't move > in to /testing until the apparent issues with the libraries are > resolved. wxwidgets in testing is a release candidate. It ships the old binaries ripped from the 2.8.5 package and the new ones built with GAR. Unless there are problems with it, I'm going to submit them for release next week. Maciej From dam at opencsw.org Thu Dec 3 15:57:10 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Dec 2009 15:57:10 +0100 Subject: [csw-maintainers] Update on buildfarm: Takes longer Message-ID: <68AA9784-2EE1-4CDC-9FCB-0A47424DADF4@opencsw.org> Hi, there is some progress on updating the buildfarm. The following tasks have been finished: - HBA has been plugged in - FC array has been set up and new zpool created for user homes - LSI firmware has been updated Unfortunately, some tasks still run and will probably do so until tomorrow: - Copying the user homes to the new zpool - Updating Solaris to Solaris 10U8. After the machine has been rebooted when the above tasks have finished I will also upgrade the firmware for LDom support to finally install OpenSolaris Sparc at some later point. So enjoy one free evening or use build8s.go.opencsw.org instead ;-) Sorry for the inconvenience -- Dago From dam at opencsw.org Thu Dec 3 16:32:20 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Dec 2009 16:32:20 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> <4AD1C002.1050409@opencsw.org> <7D96D3D3-FA0A-40E1-9549-9114E56174DC@opencsw.org> <4AF18FE6.9040703@opencsw.org> <4AF1A21C.4060201@opencsw.org> <25FB7213-E65F-4115-8DC9-50D57113E275@opencsw.org> <8853603E-D4FD-4534-8D3C-5781B3FC4286@opencsw.org> <4AF48870.2040308@opencsw.org> Message-ID: Hi Maciej, Am 02.12.2009 um 16:47 schrieb Maciej (Matchek) Blizinski: > What does replatforms do? Which stages does it reset? All. It does gmake spotless gmake platforms Probably too invasive to be useful. > Perhaps it would be better to have more descriptive target names, > for example: > > gmake platforms-reconfigure > gmake platforms-repackage > gmake platforms-clean Sounds good. Would you mind adding a feature request? I'll have some unpleasent certification things to do until the end of the year, so I will probably not have time to do nice-to-have things at the moment. Best regards -- Dago From dam at opencsw.org Thu Dec 3 23:13:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Dec 2009 23:13:18 +0100 Subject: [csw-maintainers] Update on buildfarm: Finished In-Reply-To: <68AA9784-2EE1-4CDC-9FCB-0A47424DADF4@opencsw.org> References: <68AA9784-2EE1-4CDC-9FCB-0A47424DADF4@opencsw.org> Message-ID: <853E9782-1424-4FFC-9592-A3A1B69BE9BA@opencsw.org> Hi, Am 03.12.2009 um 15:57 schrieb Dagobert Michelsen: > there is some progress on updating the buildfarm. The following tasks > have been finished: > > - HBA has been plugged in > - FC array has been set up and new zpool created for user homes > - LSI firmware has been updated > > Unfortunately, some tasks still run and will probably do so until > tomorrow: > > - Copying the user homes to the new zpool > - Updating Solaris to Solaris 10U8. > > After the machine has been rebooted when the above tasks have > finished I will also upgrade the firmware for LDom support to > finally install OpenSolaris Sparc at some later point. > > So enjoy one free evening or use build8s.go.opencsw.org instead ;-) - Firmware has been patched to support LDoms in the future - All Solaris 10 Sparc Zones are running U8 now with latest patchset - All user homes, mirrors and archives have been migrated from the internal disks to a SATA-FC-JBOD with ZFS freeing up space for the new control domain and OSOL LDom The farm should be fully functional again. Please keep your eyes open if you see anything unusual. Best regards -- Dago From bwalton at opencsw.org Fri Dec 4 03:21:55 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 03 Dec 2009 21:21:55 -0500 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> <1259808438-sup-9303@ntdws12.chass.utoronto.ca> Message-ID: <1259893227-sup-3790@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Dec 03 04:13:36 -0500 2009: Hi Dago, > Unfortunately some modules require the old line. I guess the only > viable solution until 5.10.1 is to not replace the build-in module > containing the file. What packages would that affect then? If it was updated due to requests, presumably we're at a point where either choice will have negative impact on some packaging efforts? 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 Fri Dec 4 10:45:57 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Dec 2009 10:45:57 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: <1259893227-sup-3790@ntdws12.chass.utoronto.ca> References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> <1259808438-sup-9303@ntdws12.chass.utoronto.ca> <1259893227-sup-3790@ntdws12.chass.utoronto.ca> Message-ID: <23FA802C-4C6E-47B8-835E-D7DA6054DA93@opencsw.org> Hi Ben, Am 04.12.2009 um 03:21 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Thu Dec 03 04:13:36 > -0500 2009: > >> Unfortunately some modules require the old line. I guess the only >> viable solution until 5.10.1 is to not replace the build-in module >> containing the file. > > What packages would that affect then? If it was updated due to > requests, presumably we're at a point where either choice will have > negative impact on some packaging efforts? Well, the problem was that some packages needed a more recent version of MakeMaker then the one shipped with Perl 5.8.8. So we replaced the MakeMaker version shipped with Perl 5.8.8 with a current version. This fixes packages which needed an updated version of MakeMaker. This new version seems to use an idiom not understood in all cases by the old version of Perl causing some package using the old idiom to break. The idea is that Perl 5.10.1 already has an updated MakeMaker shipped, which only uses supported idioms as it is tested together with that Perl version. At least this is how I understood what happened. Best regards -- Dago From maciej at opencsw.org Fri Dec 4 11:52:28 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 4 Dec 2009 10:52:28 +0000 Subject: [csw-maintainers] Building MySQL 5.1.x In-Reply-To: References: Message-ID: On Wed, Dec 2, 2009 at 6:27 PM, Philip Brown wrote: > Maybe you should follow its suggestion and regenerate those files > using autoconf, etc. "autoreconf -fi" didn't help. I blame libtool installation on build8s. There must be libtool 2.2.6 lurking somewhere. Maciej From dam at opencsw.org Fri Dec 4 12:03:16 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Dec 2009 12:03:16 +0100 Subject: [csw-maintainers] Building MySQL 5.1.x In-Reply-To: References: Message-ID: <48E837C1-8FC2-41D0-9379-6BEABF129BD4@opencsw.org> Hi Maciej, Am 02.12.2009 um 16:55 schrieb Maciej (Matchek) Blizinski: > I'm looking at MySQL 5.1. I'm currently experimenting with building > it in /opt/csw, with the support for different versions (5.0, 5.1 and > so forth). I'm starting this thread to track everything related to > building and testing MySQL 5.1. > > I've just run into this: > > source='conf_to_src.c' object='conf_to_src.o' libtool=no \ > DEPDIR=.deps depmode=none /bin/bash ../depcomp \ > /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. > -I../include -I../include -I../include -I/opt/csw/include > -I/opt/csw/include/mysql5/5.1 -g -DSAFE_MUTEX -g -xarch=v8 -mt > -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 > -DHAVE_CURSES_H > -I/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/ > work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/include > -DHAVE_RWLOCK_T -DUNIV_SOLARIS -DUNIV_SOLARIS -c conf_to_src.c > /bin/bash ../libtool --preserve-dup-deps --tag=CC --mode=link > /opt/studio/SOS11/SUNWspro/bin/cc -g -DSAFE_MUTEX -g -xarch=v8 -mt > -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 > -DHAVE_CURSES_H > -I/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/ > work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/include > -DHAVE_RWLOCK_T -DUNIV_SOLARIS -DUNIV_SOLARIS -static -xarch=v8 > -L/opt/csw/lib -L/opt/csw/lib/mysql5/5.1 -L/opt/csw/lib -o > conf_to_src conf_to_src.o xml.o ctype.o bcmp.o -lpthread -lposix4 > -lresolv -lc -lsocket -lnsl -lm -lpthread > libtool: Version mismatch error. This is libtool 2.2.6, but the > libtool: definition of this LT_INIT comes from libtool 2.2.6b. > libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 > libtool: and run autoconf again. > gmake[4]: *** [conf_to_src] Error 63 > gmake[4]: *** Waiting for unfinished jobs.... > gmake[4]: Leaving directory > `/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/ > work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/strings' > > This is a completely clean build, no preexisting files. Has anyone > seen this problem before? *Sigh* I did update libtool to 2.2.6b a couple of days ago. Most certainly this is the cause for the problem. However, I don't understand why it actually *is* a problem as the macros should only be pulled in when the autoconf-files are regenerated. I can offer to look at the problem but won't consider myself a libtool wizard. Best regards -- Dago From maciej at opencsw.org Fri Dec 4 12:40:22 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 4 Dec 2009 11:40:22 +0000 Subject: [csw-maintainers] GPG package verification Message-ID: When pkg-get or pkgutil verify the gpg signature of a catalog file, what is it that it's specifically checking for? My guess is that it checks for any good signature from any trusted key from root's keyring. The assumption here is that there isn't any bogus key imported into root's keyring. Otherwise, someone could hijack DNS, and serve their own catalog with their signature. pkg-get or pkgutil would look at the signature and say: "It's a good signature from badguy at evil.com. I have that UID in my keyring, looks good to me!" and let the package install. Debian uses a separate keyring for package verification. Perhaps we should have something similar? What I would like to be able to control there, is: - there's a known set of gpg keys used to verify packages - the set of gpg keyrings is easy to control by running specific scripts or dropping files into directories Thoughts or suggestions? Maciej From maciej at opencsw.org Fri Dec 4 12:37:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 4 Dec 2009 11:37:47 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: On Mon, Nov 30, 2009 at 6:01 PM, Philip Brown wrote: > Maciej, I apologise if you feel "disgruntled" in any way... While I > understand it might be frustrating to redo work, I thought we had > actually found the best way to move forward. > > To resummarize (and recap a bit for the wider audience): > The core issue is that we have 3 packages: > > CSWsudo - ?"minimal" sudo (aka "normal" sudo that most people want) > CSWsudoldap - LDAP enabled sudo > CSWsudo-common ?- common files. > > > The first two packages provide either a "sudo_minimal" or "sudo_ldap" binary. > The issue revolves around how/what creates /opt/csw/bin/sudo. > > we need to be able to have all installed, and not cause conflicts. > We also need to have "sudo" behave as desired by the site admins. > > After discussing various options, I think that the solution that > addresses all of Maciej's concerns, is to have CSWsudo also create a > symlink of /opt/csw/bin/sudo ->sudo_minimal in a postinstall script, > If and only If /opt/csw/bin/sudo does not already exist. > > I suggested that on nov 18th, and did not see any objection, or any > reply at all, after that. > I presumed that meant he was working on the update. But now I guess not...? Sorry for my last grumpy e-mail, I was just frustrated and angry. I started to reply to the last sudo-related e-mail and realized that we have to start from the very beginning, i.e.: what is CSWsudo_ldap for, and how is it supposed to be used. I guess that there's just no other way, so let's go ahead and do it. My best guess about CSWsudo and CSWsudo_ldap is that CSWsudo is a an alternative version of sudo, created so that CSWsudo would not be dependent on the ldap packages, and users would not be forced to install ldap just to have simple sudo. The obvious way of doing it would be to have CSWsudo and CSWsudo_ldap mutually incompatible: user installs one or the other. There's no gain in installing both, as sudo_ldap pulls ldap packages, so all the benefit of CSWsudo (without the dependency) is lost. The current way sudo is packaged is probably a work in progress which become stuck at some point. I don't see any sense of CSWsudo_common installing a dangling symlink from /opt/csw/bin/sudo to /opt/csw/bin/sudo.minimal. I agree that if CSWsudo installed the symlink if it wasn't already there would fix the discussed failure mode. However, it strikes me as an attempt do deal with this one failure mode without looking at the bigger picture, or perhaps Phil and I have different bigger pictures. If I wanted to switch between ldap-enabled and minimal sudo, I would expect the following to work: pkgrm CSWsudo_ldap pkg-get -i CSWsudo or pkgrm CSWsudo pkg-get -i CSWsudo_ldap Anything else is in my opinion unintuitive. If we wanted a solution with both binaries installed at the same time (assuming there's a benefit there), we would need a mechanism for switching the alternatives. I'll be happy to discuss that, and deploy a thought-through solution. I don't want to start messing with symlinks with no design in place. Maciej From dam at opencsw.org Fri Dec 4 13:36:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 4 Dec 2009 13:36:51 +0100 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Hi Phil, Am 04.12.2009 um 12:37 schrieb Maciej (Matchek) Blizinski: > If we wanted a solution with both binaries installed at the same time > (assuming there's a benefit there), we would need a mechanism for > switching the alternatives. I'll be happy to discuss that, and deploy > a thought-through solution. I don't want to start messing with > symlinks with no design in place. This exact same problem is there for tcpwrappers as you stated in the README: > TCP-Wrappers, from http://www.porcupine.org > > Note that the library is compiled to use LOG_LOCAL1 as the > syslog facility, NOT "LOG_MAIL", the default. > > ALSO, it uses /etc/opt/csw/hosts.xxx, NOT /etc/hosts.XXX > > man hosts_access(3), hosts_access(5), hosts_options(5) > for syntax on those. > > The compile has been hacked to provide a shared-library version > instead > of libwrap.a > There is an extra hack, in that there are default variable > definitions of > deny_severity and allow_severity, set to 0. > This is to allow for ./configure style tests, that break in the > transition > from lib.a to lib.so > > > Note also that there are TWO versions of libwrap.so: > libwrap-std.so.1 The "standard" tcp wrapper library > libwrap-ext.so.1 The "extended" tcp wrapper library > > By default, /opt/csw/lib/libwrap.so.1 is linked to the std version. > To use the extended syntax in hosts_options(5), you need to change > the link to point to libwrap-ext.so.1 > Unfortunately, the syntax for the two versions, is slightly > incompatible, > which is why there are two versions. Whatever solution we find for sudo, it should be applied for tcpwrappers too. Best regards -- Dago From maciej at opencsw.org Fri Dec 4 18:36:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 4 Dec 2009 17:36:58 +0000 Subject: [csw-maintainers] SOS12 on build9s Message-ID: I'm trying to build a package with SOS12 on build9s, but it's failing: checking for gcc... /opt/studio/SOS12/SUNWspro/bin/cc checking for C compiler default output file name... configure: error: in `/home/maciej/src/opencsw/pkg/pinentry/trunk/work/solaris9-sparc/build-isa-sparcv8/pinentry-0.7.6': configure: error: C compiler cannot create executables See `config.log' for more details. gmake: *** [configure-work/solaris9-sparc/build-isa-sparcv8/pinentry-0.7.6/configure] Error 77 gmake: Leaving directory `/home/maciej/src/opencsw/pkg/pinentry/trunk' gmake: *** [merge-isa-sparcv8] Error 2 gmake: Leaving directory `/home/maciej/src/opencsw/pkg/pinentry/trunk' Connection to build9s closed. gmake: *** [platforms] Error 2 config.log says: configure:2949: /opt/studio/SOS12/SUNWspro/bin/cc -xO3 -m32 -xarch=v8 -D__EXTENSIONS__ -I/opt/csw/X11/include -I/opt/csw/include -m32 -xarch=v8 -L/opt/csw/lib -L/opt/csw/X11/lib conftest.c >&5 ./configure: /opt/studio/SOS12/SUNWspro/bin/cc: No such file or directory configure:2953: $? = 127 configure:2991: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "pinentry" | #define PACKAGE_TARNAME "pinentry" | #define PACKAGE_VERSION "0.7.6" | #define PACKAGE_STRING "pinentry 0.7.6" | #define PACKAGE_BUGREPORT "gnupg-devel at gnupg.org" | #define PACKAGE "pinentry" | #define VERSION "0.7.6" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2997: error: in `/home/maciej/src/opencsw/pkg/pinentry/trunk/work/solaris9-sparc/build-isa-sparcv8/pinentry-0.7.6': configure:3000: error: C compiler cannot create executables See `config.log' for more details. Checking for the binary: maciej at build9s :~ > ls -l /opt/studio/SOS12/SUNWspro/bin/cc lrwxrwxrwx 1 root other 14 Jan 23 2009 /opt/studio/SOS12/SUNWspro/bin/cc -> ../prod/bin/cc maciej at build9s :~ > ls -l /opt/studio/SOS12/SUNWspro/bin/../prod/bin/cc -rwxr-xr-x 1 root sys 280268 May 1 2009 /opt/studio/SOS12/SUNWspro/bin/../prod/bin/cc It's there. Before I spend time debugging that, do you have any ideas? Maciej From phil at bolthole.com Fri Dec 4 20:38:33 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Dec 2009 11:38:33 -0800 Subject: [csw-maintainers] GPG package verification In-Reply-To: References: Message-ID: On Fri, Dec 4, 2009 at 3:40 AM, Maciej (Matchek) Blizinski wrote: > When pkg-get or pkgutil verify the gpg signature of a catalog file, > what is it that it's specifically checking for? ?My guess is that it > checks for any good signature from any trusted key from root's > keyring. > True. > Debian uses a separate keyring for package verification. ?Perhaps we > should have something similar? err, debian uses gpg completely differently. it has a keyring, because it has each maintainer INDIVIDUALLY sign their packages. Which means you then need a whole keyring/web of trust/blahblah to verify ALL the maintainers. whereas we, at the moment, only sign the catalog, which has hashes of all the packages it knows about. This provides about the same level of non-tamperability, with much less hassle to the maintainers individuallly. (but more hassle for ME as the release manager ;-) Now, that being said,we COULD theoretically have pkgutil and pkg-get explicitly check for a particular signature, instead of just "any signature" I suppose. From phil at bolthole.com Fri Dec 4 20:40:06 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 4 Dec 2009 11:40:06 -0800 Subject: [csw-maintainers] SOS12 on build9s In-Reply-To: References: Message-ID: On Fri, Dec 4, 2009 at 9:36 AM, Maciej (Matchek) Blizinski wrote: > > Checking for the binary: > > maciej at build9s :~ > ls -l /opt/studio/SOS12/SUNWspro/bin/cc > lrwxrwxrwx ? 1 root ? ? other ? ? ? ? 14 Jan 23 ?2009 > /opt/studio/SOS12/SUNWspro/bin/cc -> ../prod/bin/cc > maciej at build9s :~ > ls -l /opt/studio/SOS12/SUNWspro/bin/../prod/bin/cc > -rwxr-xr-x ? 1 root ? ? sys ? ? ? 280268 May ?1 ?2009 > /opt/studio/SOS12/SUNWspro/bin/../prod/bin/cc > > It's there. ?Before I spend time debugging that, do you have any ideas? > you've proved there is a binary. you havent proved it works. show that it works first ;-) start with "cc -V" and then move on to cat >test.c < References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Fri, Dec 4, 2009 at 4:36 AM, Dagobert Michelsen wrote: > > Whatever solution we find for sudo, it should be applied for tcpwrappers > too. I disagree. tcpwrappers is a GLOBALLY SHARED LIBRARY, that has MULTIPLE packages dependant on it. that forces us to provide a single shared lib, and hence its current installtime behaviour. whereas sudo, is just an executable, that has nothing dependant on it. That means that it is perfectly allowable to have BOTH executables present. > There's no >gain in installing both, as sudo_ldap pulls ldap packages, so all the >benefit of CSWsudo (without the dependency) is lost. I would have to disagree here. on multiple levels. But I'll just state the simplest useful reason to allow both: picture an environment where ldap is USUALLY used. in this case, sudo_ldap would be routinely used. however, one day, "something bad happens", where both root login, and ldap information, is messed up. It then becomes very very useful, to have sudo.minimal installed and ready to use, as a fallback cleanup tool. From dam at opencsw.org Sat Dec 5 17:43:33 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 5 Dec 2009 17:43:33 +0100 Subject: [csw-maintainers] SOS12 on build9s In-Reply-To: References: Message-ID: <7E34193F-F569-417C-8AB7-032484C66C25@opencsw.org> Hi Maciej, Am 04.12.2009 um 18:36 schrieb Maciej (Matchek) Blizinski: > It's there. Before I spend time debugging that, do you have any > ideas? Yes, because it tries to build on build8s instead of build9s, and as SOS12 doesn't run on Solaris 8 it is not installed there: > [===== Building modulation 'isa-sparcv8' on host 'build8s' =====] > ssh build8s "PATH=/home/dam/mgar/pkg/pinentry/trunk/gar/bin/sos12- > wrappers:/home/dam/mgar/pkg/pinentry/trunk/work/solaris9-sparc/ > install-global/opt/csw/bin:/home/dam/mgar/pkg/pinentry/trunk/work/ > solaris9-sparc/install-global/opt/csw/bin:/home/dam/mgar/pkg/ > pinentry/trunk/work/solaris9-sparc/install-global/opt/csw/sbin:/home/ > dam/mgar/pkg/pinentry/trunk/work/solaris9-sparc/install-global/opt/ > csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/ > studio/SOS12/SUNWspro/bin:/home/dam/mgar/pkg/pinentry/trunk/gar/bin:/ > usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin gmake - > C /home/dam/mgar/pkg/pinentry/trunk PLATFORM=solaris9-sparc > MODULATION=isa-sparcv8 ISA=sparcv8 merge-modulated" The PACKAGING_PLATFORMS currently only specify on which the hosts the package is assembled. I guess it should also set the minimum OS level where the package is built, but it currently doesn't do that. In the meantime I added a patch as r7558 resetting the default buildhosts for pinetry. Hopefully I can fix this cleanly in GAR on monday. BTW, please make sure you do "gmake garchive" some time so the source files get archived. Best regards -- Dago From maciej at opencsw.org Sat Dec 5 17:11:32 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Dec 2009 16:11:32 +0000 Subject: [csw-maintainers] SOS12 on build9s In-Reply-To: References: Message-ID: On Fri, Dec 4, 2009 at 7:40 PM, Philip Brown wrote: > you've proved there is a binary. you havent proved it works. show that > it works first ;-) > > start with "cc -V" > > and then move on to > > cat >test.c < main(){} > EOF > cc -o t test.c maciej at build9s :~ > /opt/studio/SOS12/SUNWspro/prod/bin/cc -V cc: Sun C 5.9 SunOS_sparc Patch 124867-11 2009/04/30 usage: cc [ options] files. Use 'cc -flags' for details maciej at build9s :~ > cat >test.c < main(){} continued> EOF maciej at build9s :~ > /opt/studio/SOS12/SUNWspro/prod/bin/cc -o t test.c "test.c", line 1: warning: old-style declaration or incorrect type for: main maciej at build9s :~ > echo $? 0 The binary works. Any ideas what else might have gone wrong? From maciej at opencsw.org Sat Dec 5 20:50:20 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 5 Dec 2009 19:50:20 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Fri, Dec 4, 2009 at 7:51 PM, Philip Brown wrote: >> There's no >>gain in installing both, as sudo_ldap pulls ldap packages, so all the >>benefit of CSWsudo (without the dependency) is lost. > > I would have to disagree here. on multiple levels. > But I'll just state the simplest useful reason to allow both: > > picture an environment where ldap is USUALLY used. ?in this case, > sudo_ldap would be routinely used. > > however, one day, "something bad happens", where both root login, and > ldap information, is messed up. ?It then becomes very very useful, to > have sudo.minimal installed and ready to use, as a fallback cleanup > tool. Is it a case that you know how to reproduce, or is it just a hunch? I'm asking, because I can't an obvious case of this problem. If the information that joe has sudo access is stored in ldap and ldap is unavailable, joe will not get root with sudo.ldap nor sudo.minimal. If the information that joe has access is stored locally, sudo.ldap will look in both places and grant joe access. Having sudo.minimal installed doesn't make it any better or worse. Regardless to whether it makes sense to have both packages installed at the same time, we can consider the general case of providing alternatives. Let's suppose functionality baz provided by either foo or bar. We want to type "baz" and have the job done. However, in some cases we want to use foo or bar specifically. How do we handle that? Maciej From maciej at opencsw.org Sun Dec 6 11:07:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 6 Dec 2009 10:07:47 +0000 Subject: [csw-maintainers] SOS12 on build9s In-Reply-To: <7E34193F-F569-417C-8AB7-032484C66C25@opencsw.org> References: <7E34193F-F569-417C-8AB7-032484C66C25@opencsw.org> Message-ID: On Sat, Dec 5, 2009 at 4:43 PM, Dagobert Michelsen wrote: > The PACKAGING_PLATFORMS currently only specify on which the hosts the > package is assembled. I guess it should also set the minimum OS level > where the package is built, but it currently doesn't do that. In the > meantime I added a patch as r7558 resetting the default buildhosts > for pinetry. I've spent some time on it and got pinentry to build with SOS11. I had replace one macro by hand, but this was the easy patch. The next problem was that pinentry used getopt.h, so I had to use gnulib to add getopt support. I haven't built the 64-bit version: Solaris 10 has the file /usr/include/getopt.h which conflicts with the one created by gnulib, which was a problem on build10x. Now that we've got pinentry, I'll try go get it released soon and build gnupg 2.0 with pinentry support. We run into the alternatives problem again: I need gnupg 2.0 to be accessible as /opt/csw/bin/gpg. Maciej From bwalton at opencsw.org Sun Dec 6 14:46:10 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 06 Dec 2009 08:46:10 -0500 Subject: [csw-maintainers] SOS12 on build9s In-Reply-To: References: <7E34193F-F569-417C-8AB7-032484C66C25@opencsw.org> Message-ID: <1260106882-sup-7799@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sun Dec 06 05:07:47 -0500 2009: > Now that we've got pinentry, I'll try go get it released soon and > build gnupg 2.0 with pinentry support. We run into the alternatives > problem again: I need gnupg 2.0 to be accessible as /opt/csw/bin/gpg. GPG seems to be one place where neither Debian nor RHEL use their alternatives functionality. I _believe_ that this is due to the fact that gpg2 is not a pure superset of gpg's functionality. I ran into some issues when using gpg2 as my default gpg. I could sign and verify mail I sent, but others using gpg1 couldn't verify signatures I generated. As with much of the rest of the gpg documentation, tracking down info on this problem wasn't easy. In the end, I reverted to using gpg, as using gpg2 had been an experiment for other reasons only. If you need an app to use 2 by default, my recommendation would be twiddle a config knob if provided or build it with the /path/to/gpg2 built in instead. HTH.[1] -Ben [1] If you have info that makes gpg2 sign things in a way that older gpg can work with, I'd be interested to see it. -- 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 Sun Dec 6 14:48:15 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 6 Dec 2009 13:48:15 +0000 Subject: [csw-maintainers] Alternatives Message-ID: On Sat, Dec 5, 2009 at 7:50 PM, Maciej (Matchek) Blizinski wrote: > Let's suppose functionality baz provided by either foo > or bar. ?We want to type "baz" and have the job done. ?However, in > some cases we want to use foo or bar specifically. ?How do we handle > that? Here's an idea: reuse somebody else's work! We start with no symlink. netra ~ # ls -l /opt/csw/bin/sudo* -rwsr-xr-x 1 root bin 221736 Oct 5 19:26 /opt/csw/bin/sudoedit -rwxr-xr-x 1 root bin 245232 Oct 5 19:30 /opt/csw/bin/sudo.ldap -rwsr-xr-x 1 root bin 221736 Oct 5 19:26 /opt/csw/bin/sudo.minimal Let's tell the alternatives system that we've got something called 'sudo' which is provided by sudo.minimal. netra ~ # update-alternatives --install /opt/csw/bin/sudo sudo /opt/csw/bin/sudo.minimal 40 update-alternatives: using /opt/csw/bin/sudo.minimal to provide /opt/csw/bin/sudo (sudo) in auto mode. netra ~ # ls -l /opt/csw/bin/sudo* lrwxrwxrwx 1 root root 30 Dec 6 14:41 /opt/csw/bin/sudo -> /etc/opt/csw/alternatives/sudo -rwsr-xr-x 1 root bin 221736 Oct 5 19:26 /opt/csw/bin/sudoedit -rwxr-xr-x 1 root bin 245232 Oct 5 19:30 /opt/csw/bin/sudo.ldap -rwsr-xr-x 1 root bin 221736 Oct 5 19:26 /opt/csw/bin/sudo.minimal The alternatives system has chosen the best alternative, the highest priority number. (A bit counterintuitive direction.) Let's see what /etc/opt/csw/alternatives/sudo points at. netra ~ # ls -l /etc/opt/csw/alternatives/sudo lrwxrwxrwx 1 root root 25 Dec 6 14:41 /etc/opt/csw/alternatives/sudo -> /opt/csw/bin/sudo.minimal We can now add the ldap-enabled version of sudo: netra ~ # update-alternatives --install /opt/csw/bin/sudo sudo /opt/csw/bin/sudo.ldap 20 Let's see what the alternatives system says about sudo now. netra ~ # update-alternatives --display sudo sudo - auto mode link currently points to /opt/csw/bin/sudo.minimal /opt/csw/bin/sudo.ldap - priority 20 /opt/csw/bin/sudo.minimal - priority 40 Current `best' version is /opt/csw/bin/sudo.minimal. It has chosen the implementation based on priority. Let's try to modify it by hand. netra ~ # update-alternatives --config sudo There are 2 choices for the alternative sudo (providing /opt/csw/bin/sudo). Selection Path Priority Status ------------------------------------------------------------ * 0 /opt/csw/bin/sudo.minimal 40 auto mode 1 /opt/csw/bin/sudo.ldap 20 manual mode 2 /opt/csw/bin/sudo.minimal 40 manual mode Press enter to keep the current choice[*], or type selection number: 1 update-alternatives: using /opt/csw/bin/sudo.ldap to provide /opt/csw/bin/sudo (sudo) in manual mode. ...and see where the symlink points to now. netra ~ # ls -l /opt/csw/bin/sudo* lrwxrwxrwx 1 root root 30 Dec 6 14:44 /opt/csw/bin/sudo -> /etc/opt/csw/alternatives/sudo -rwsr-xr-x 1 root bin 221736 Oct 5 19:26 /opt/csw/bin/sudoedit -rwxr-xr-x 1 root bin 245232 Oct 5 19:30 /opt/csw/bin/sudo.ldap -rwsr-xr-x 1 root bin 221736 Oct 5 19:26 /opt/csw/bin/sudo.minimal This symlink hasn't changed, but... netra ~ # ls -l /etc/opt/csw/alternatives/sudo lrwxrwxrwx 1 root root 22 Dec 6 14:44 /etc/opt/csw/alternatives/sudo -> /opt/csw/bin/sudo.ldap This one now points at sudo. Thoughts? Maciej From bwalton at opencsw.org Sun Dec 6 15:00:28 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 06 Dec 2009 09:00:28 -0500 Subject: [csw-maintainers] Alternatives In-Reply-To: References: Message-ID: <1260107634-sup-2839@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sun Dec 06 08:48:15 -0500 2009: > Thoughts? I've always enjoyed this functionality on Debian and RHEL systems (implemented slightly differently, but with similar goals). -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 yann at pleiades.fr.eu.org Sun Dec 6 20:19:11 2009 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sun, 06 Dec 2009 20:19:11 +0100 Subject: [csw-maintainers] [Fwd: Re: [csw-users] Openssl vulnerability CVE-2009-3555] Message-ID: <4B1C03AF.7000203@pleiades.fr.eu.org> Hi, I don't know exactly what is the good answer to the following question asked on the csw users mailing list. Can someone enlighten me ? Yann -------- Message original -------- Sujet: Re: [csw-users] Openssl vulnerability CVE-2009-3555 Date: Sun, 6 Dec 2009 11:10:15 -0600 De: Mike Gerdts R?pondre ? :: Questions and discussions Pour :: Questions and discussions R?f?rences: <4B1B9DC4.9050009 at pleiades.fr.eu.org> On Sun, Dec 6, 2009 at 6:04 AM, Yann Rouillard wrote: > Dear users, > > A security vulnerability has been recently found in the TLS and SSL > protocol part related to the handling of session renegotiation [1]. This > vulnerability allows an attacker to inject arbitrary content at the > beginning of a TLS/SSL connection within a Man-in-the-middle attack. > > This problem is caused by a design flaw in the TLS/SSL protocol and is > difficult to fix in a clean and backward compatible way. As a result the > new openssl release (0.9.8l) which fixes this bug simply completely > disables renegotiation. > > This new package will hit csw unstable mirror very soon. What is the plan for updating stable? If there are no plans to maintain stable, is there a documented procedure for me to create a custom branch (e.g. mystable) that contains the fixes and updates that I care about? The current stable seems to be a bit stale. -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ users mailing list users at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/users From maciej at opencsw.org Sun Dec 6 23:41:19 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 6 Dec 2009 22:41:19 +0000 Subject: [csw-maintainers] [Fwd: Re: [csw-users] Openssl vulnerability CVE-2009-3555] In-Reply-To: <4B1C03AF.7000203@pleiades.fr.eu.org> References: <4B1C03AF.7000203@pleiades.fr.eu.org> Message-ID: On Sun, Dec 6, 2009 at 7:19 PM, Yann Rouillard wrote: > Hi, > > I don't know exactly what is the good answer to the following question asked > on the csw users mailing list. > > Can someone enlighten me ? > > Yann > (...) > What is the plan for updating stable? ?If there are no plans to > maintain stable, is there a documented procedure for me to create a > custom branch (e.g. mystable) that contains the fixes and updates that > I care about? ?The current stable seems to be a bit stale. I'd say: use bldcat to create own catalog with newer versions or fixes, then use it on top of the stable catalog using multiple catalogs in pkgutil.conf. I'm not sure if pkg-get can do the same. Maciej From phil at bolthole.com Mon Dec 7 18:05:27 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Dec 2009 09:05:27 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Sat, Dec 5, 2009 at 11:50 AM, Maciej (Matchek) Blizinski wrote: > > Regardless to whether it makes sense to have both packages installed > at the same time, we can consider the general case of providing > alternatives. ?Let's suppose functionality baz provided by either foo > or bar. ?We want to type "baz" and have the job done. ?However, in > some cases we want to use foo or bar specifically. ?How do we handle > that? > Whatever you come up with, needs to still allow all packages to be installed simultaneously. Can we do this with sudo now please? :-) From phil at bolthole.com Mon Dec 7 18:10:03 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 7 Dec 2009 09:10:03 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: References: Message-ID: On Sun, Dec 6, 2009 at 5:48 AM, Maciej (Matchek) Blizinski wrote: > .... > > Here's an idea: reuse somebody else's work! >.... > Let's tell the alternatives system that we've got something called > 'sudo' which is provided by sudo.minimal. > .... > Thoughts? Sounds like it has potential. My two concerns are that 1. you havent spelled out how it would be used by a package, at pkgadd time. (please note that I explicitly used "pkgadd" there) 2. it should probably have some kind of csw-specific naming, rather than "update-alternatives" (not to mentiont that that name is just too durn long!! ;-) From maciej at opencsw.org Mon Dec 7 18:36:27 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 7 Dec 2009 17:36:27 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: References: Message-ID: On Mon, Dec 7, 2009 at 5:10 PM, Philip Brown wrote: > On Sun, Dec 6, 2009 at 5:48 AM, Maciej (Matchek) Blizinski > wrote: >> .... >> >> Here's an idea: reuse somebody else's work! >>.... >> Let's tell the alternatives system that we've got something called >> 'sudo' which is provided by sudo.minimal. >> > > .... >> Thoughts? > > Sounds like it has potential. > My two concerns are that > > 1. you havent spelled out how it would be used by a package, at pkgadd time. > > (please note that I explicitly used "pkgadd" there) You forgot to explicitly mention pkgrm. ;-) It's package's responsibility to register and deregister binaries. Either a post{install,remove} script or a new class action script. > 2. it should probably have some kind of csw-specific naming, rather > than "update-alternatives" Why should it? It's not specific to CSW. It can be used to use alternatives from any package provider. From bwalton at opencsw.org Mon Dec 7 18:48:09 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Dec 2009 12:48:09 -0500 Subject: [csw-maintainers] Alternatives In-Reply-To: References: Message-ID: <1260206340-sup-1423@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Dec 07 12:10:03 -0500 2009: > 1. you havent spelled out how it would be used by a package, at pkgadd time. > > (please note that I explicitly used "pkgadd" there) My suggestion here would be a CAS. The action to take if no current 'altnernative' is in place is to use the default of the package being provided. A package installing a new 'alternative' that finds the link existing already should NOTE this and carry on. So, in the prototype, a file marked class cswalternative /opt/csw/bin/sudo may or may not provide an actual file in the end. At removal, if the target of the link is still there, the link itself should be left in tact. > 2. it should probably have some kind of csw-specific naming, rather > than "update-alternatives" That sounds reasonable, although I don't have anything better to offer right now. -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 Mon Dec 7 18:50:45 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Dec 2009 12:50:45 -0500 Subject: [csw-maintainers] Alternatives In-Reply-To: References: Message-ID: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Dec 07 12:36:27 -0500 2009: > Why should it? It's not specific to CSW. It can be used to use > alternatives from any package provider. No, I think Phil is right here. As much as restricting ourselves to /opt/csw would also restrict overall usefulness, it's the only policy (in my current thinking) that wouldn't open a big nasty can of worms. It'd be great to replace /usr/lib/sendmail using these mechanisms, but if other packages aren't aware of the system, it really wouldn't help much anyway. 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 Mon Dec 7 19:14:53 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 7 Dec 2009 18:14:53 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Dec 7, 2009 at 5:50 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Mon Dec 07 12:36:27 -0500 2009: > >> Why should it? ?It's not specific to CSW. ?It can be used to use >> alternatives from any package provider. > > No, I think Phil is right here. ?As much as restricting ourselves to > /opt/csw would also restrict overall usefulness, it's the only policy > (in my current thinking) that wouldn't open a big nasty can of worms. > > It'd be great to replace /usr/lib/sendmail using these mechanisms, but > if other packages aren't aware of the system, it really wouldn't help > much anyway. What if I have my own in-house built package? It's going to use a different installation prefix, and all will be custom. It will depend CSWalternatives and use it. We would restrict ourselves to /opt/csw, but it doesn't mean that the alternatives mechanism can be used only within /opt/csw, so it's not CSW specific -- in the sense that you can use for any package you want, CSW or not. After all, it's just another program, which wasn't even written with Solaris in mind, not to mention CSW. Maciej From bwalton at opencsw.org Mon Dec 7 19:23:58 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 07 Dec 2009 13:23:58 -0500 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> Message-ID: <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Dec 07 13:14:53 -0500 2009: > What if I have my own in-house built package? It's going to use a > different installation prefix, and all will be custom. It will depend > CSWalternatives and use it. Ok, that'd be fair. As long as you wouldn't be affecting, say, SUNW packages with this mechanism, it's fair to allow it to interoperate among packages that are aware of the functionality, I guess. > We would restrict ourselves to /opt/csw, but it doesn't mean that the > alternatives mechanism can be used only within /opt/csw, so it's not > CSW specific -- in the sense that you can use for any package you > want, CSW or not. After all, it's just another program, which wasn't > even written with Solaris in mind, not to mention CSW. Ok. :) 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 Dec 8 10:12:02 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 8 Dec 2009 09:12:02 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Mon, Dec 7, 2009 at 5:05 PM, Philip Brown wrote: > On Sat, Dec 5, 2009 at 11:50 AM, Maciej (Matchek) Blizinski > wrote: >> >> Regardless to whether it makes sense to have both packages installed >> at the same time, we can consider the general case of providing >> alternatives. ?Let's suppose functionality baz provided by either foo >> or bar. ?We want to type "baz" and have the job done. ?However, in >> some cases we want to use foo or bar specifically. ?How do we handle >> that? >> > > Whatever you come up with, needs to still allow all packages to be > installed simultaneously. > > Can we do this with sudo now please? :-) We don't have to do it now. Here's the reason: # cat /var/sadm/pkg/CSWsudoldap/save/pspool/CSWsudoldap/pkgmap : 1 489 1 f none /opt/csw/bin/sudo.ldap 0755 root bin 245232 16892 1254763822 1 i depend 227 20555 1254763830 1 i pkginfo 487 41164 1254763830 Look at the permissions: "/opt/csw/bin/sudo.ldap 0755". The CSWsudoldap package is contains a binary that is not setuid root. I would like to declare CSWsudoldap useless and ignore it for now. We'll worry about making CSWsudoldap an alternative when it's done properly, and when it actually works. From phil at bolthole.com Tue Dec 8 17:46:50 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 8 Dec 2009 08:46:50 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Tue, Dec 8, 2009 at 1:12 AM, Maciej (Matchek) Blizinski wrote: > > # cat /var/sadm/pkg/CSWsudoldap/save/pspool/CSWsudoldap/pkgmap > : 1 489 > 1 f none /opt/csw/bin/sudo.ldap 0755 root bin 245232 16892 1254763822 > 1 i depend 227 20555 1254763830 > 1 i pkginfo 487 41164 1254763830 > > Look at the permissions: "/opt/csw/bin/sudo.ldap 0755". The > CSWsudoldap package is contains a binary that is not setuid root. ?I > would like to declare CSWsudoldap useless and ignore it for now. > We'll worry about making CSWsudoldap an alternative when it's done > properly, and when it actually works. oh wow. that's really sad. And yet, there IS a (very old) bug filed against the package, about something else. Please "do the right thing", and provide a properly packaged version update? its not like the older version "doesnt work at all". it just needs site-local fixes for the poor packaging :-( From dam at opencsw.org Wed Dec 9 17:01:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Dec 2009 17:01:32 +0100 Subject: [csw-maintainers] Fwd: [solarisx86] Perl issue References: <4B1E4A2D.7080800@mindspring.com> Message-ID: Hi Peter, Anfang der weitergeleiteten E-Mail: > Von: Phillip Bruce > Datum: 8. Dezember 2009 13:44:29 MEZ > An: solarisx86 at yahoogroups.com > Betreff: [solarisx86] Perl issue > Antwort an: solarisx86 at yahoogroups.com > > Anyone ran into this issue: > > Running make install > Can't coerce array into hash at > /opt/csw/share/perl/5.8.8/ExtUtils/Install.pm line 94. > gmake: *** [pure_site_install] Error 255 > /usr/sfw/bin/gmake install -- NOT OK > > what I was doing here is using perl -MCPAN -e shell and trying to > install Date::Format module. > > i tried using make under /usr/ccs/bin but it failed in the same way. > > Got same issue when running perl 5..8.4 > > Phillip It starts hurting users. Peter, could you please revert the update of MakeMaker or even better update to 5.10.1? Let me know if I can be of any help here. Best regards -- Dago From bwalton at opencsw.org Wed Dec 9 17:25:21 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Dec 2009 11:25:21 -0500 Subject: [csw-maintainers] Fwd: [solarisx86] Perl issue In-Reply-To: References: <4B1E4A2D.7080800@mindspring.com> Message-ID: <1260375875-sup-5462@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Dec 09 11:01:32 -0500 2009: > It starts hurting users. Peter, could you please revert the update > of MakeMaker or even better update to 5.10.1? Let me know if I can > be of any help here. Yes please. I don't care how it's resolved, but it's currently a blocking factor for me. 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 Dec 9 18:17:19 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 9 Dec 2009 17:17:19 +0000 Subject: [csw-maintainers] Links from mantis to the 'processing bugs' wiki page In-Reply-To: References: Message-ID: On Tue, Sep 29, 2009 at 8:23 PM, Maciej (Matchek) Blizinski wrote: > 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? Sebastian? From bwalton at opencsw.org Thu Dec 10 01:18:19 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 09 Dec 2009 19:18:19 -0500 Subject: [csw-maintainers] perl maintenance on buildfarm Message-ID: <1260404227-sup-6341@ntdws12.chass.utoronto.ca> Hi All, I'm in the process of down-revving CSWperl on the buildfarm. Please be patient if you experience problems in the next little while. 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 Thu Dec 10 08:24:11 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 07:24:11 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Tue, Dec 8, 2009 at 4:46 PM, Philip Brown wrote: > And yet, there IS a (very old) bug filed against the package, about > something else. > Please "do the right thing", and provide a properly packaged version update? > its not like the older version "doesnt work at all". it just needs > site-local fixes for the poor packaging :-( Filed bug 4074 about this issue. http://www.opencsw.org/mantis/view.php?id=4074 My brain says the right thing to do is: 1. Get the alternatives mechanism in place 2. Modify CSWsudo to use it 3. Modify CSWsudo_ldap to use it, give it higher priority (if both are installed at the same time, use sudo.ldap) 4. Remove the stupid symlink from CSWsudo_common 5. Release all three packages at the same time Does it look good? From maciej at opencsw.org Thu Dec 10 08:41:48 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 07:41:48 +0000 Subject: [csw-maintainers] Replacing existing Solaris functionality by OpenCSW packages In-Reply-To: References: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> Message-ID: On Tue, Nov 24, 2009 at 4:32 PM, Philip Brown wrote: > On Tue, Nov 24, 2009 at 7:54 AM, Dagobert Michelsen wrote: >> >>... >> As there is a "install all" option in pkg-get which is used it >> is adviseable to not install these replacemenet-packages by >> default. This may be accomplished by one of the following >> solutions: >> >> - Different [SVR4 pkg] prefix >> >> The addons would be named CSWX... to mark that they are Xtra >> to install. >>... >> >> - Different catalog >> >> The extra packages may be put in a separate catalog. >>... > > > Or by other methods. > > Such as defining additional standard global configs to go in csw.conf > > "replace_sun_pkgs=yes" > or some such? > > Then a postinstall script could check for that, and > rename/disable/replace/whatever as appropriate. > > I suppose we might even support different values. > > replace_sun_pkgs={replace,rename,???} > > (where one could mean simple "mv old binaries to .old", and another > might be "actually put in symlink to our binaries, and yet another > could mean "pkgrm conflicting") One package can't remove another package upon installation, can it? I think that the alternatives mechianism could be used to switch the implementation: mkdir /usr/libexec/sun mv /usr/bin/foo /usr/libexec/sun/foo update-alternatives --install /usr/bin/foo foo /usr/libexec/sun/foo 30 update-alternatives --install /usr/bin/foo foo /opt/csw/bin/foo 20 In this way, the Sun binary is still used. However, this could get messed up during OS patching or OS upgrades, I suppose. It's much better to have the conflicting SUNW packages uninstalled. Anyway, about handling the "install all CSW" scenario, isn't it better to just skip the packages which conflict with already installed ones? From maciej at opencsw.org Thu Dec 10 09:32:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 08:32:46 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> Message-ID: On Wed, Dec 2, 2009 at 11:01 PM, Peter Bonivart wrote: > On Wed, Dec 2, 2009 at 11:59 PM, Gary Law wrote: >> Hi all >> >> Been chatting with Maciej about a bug/feature I've hit where I can't >> properly install CSWcswclassutils, as it wants to write in /usr, and >> that's mounted readonly (it's a non-global zone). >> >> Does this mean CSWcswclassutils violates policy? I thought we had to >> confine ourselves to /opt, /etc/opt/csw and /var/opt/csw >> >> Maciej suggested non-global zones and/or non-writable /usr aren't >> supported by CSW, which may be correct, but is news to me. >> >> Thoughts? > > It's how Sun designed it. Just install that package from the global > zone and be done with it. :-) For the record: http://www.opencsw.org/bugtrack/view.php?id=3760 From glaw at opencsw.org Thu Dec 10 12:52:40 2009 From: glaw at opencsw.org (Gary Law) Date: Thu, 10 Dec 2009 11:52:40 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> Message-ID: HI 2009/12/10 Maciej (Matchek) Blizinski : > On Wed, Dec 2, 2009 at 11:01 PM, Peter Bonivart wrote: >> It's how Sun designed it. Just install that package from the global >> zone and be done with it. :-) > > For the record: > > http://www.opencsw.org/bugtrack/view.php?id=3760 OK, I don't think we should be using classutils then. It violates policy. The 'workaround' is clunky for some, and impossible if you don't have root on the global zone. -- Gary Law Email: garylaw at garylaw.net Chat googletalk/messenger: gary.law at gmail.com iChat/jabber/AIM: gary.law at mac.com From james at opencsw.org Thu Dec 10 13:08:40 2009 From: james at opencsw.org (James Lee) Date: Thu, 10 Dec 2009 12:08:40 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: Message-ID: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> On 10/12/09, 11:52:40, Gary Law wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > >> It's how Sun designed it. Just install that package from the global > >> zone and be done with it. :-) > > > > For the record: > > > > http://www.opencsw.org/bugtrack/view.php?id=3760 > OK, I don't think we should be using classutils then. It violates > policy. The 'workaround' is clunky for some, and impossible if you > don't have root on the global zone. I support Gary. I understand that classutils is clever and works well in some situations but it's not a complete solution and therefor we should look for something else. James. From bonivart at opencsw.org Thu Dec 10 13:27:26 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 10 Dec 2009 13:27:26 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> Message-ID: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> On Thu, Dec 10, 2009 at 12:52 PM, Gary Law wrote: > HI > > 2009/12/10 Maciej (Matchek) Blizinski : >> On Wed, Dec 2, 2009 at 11:01 PM, Peter Bonivart wrote: >>> It's how Sun designed it. Just install that package from the global >>> zone and be done with it. :-) >> >> For the record: >> >> http://www.opencsw.org/bugtrack/view.php?id=3760 > > OK, I don't think we should be using classutils then. It violates > policy. The 'workaround' is clunky for some, and impossible if you > don't have root on the global zone. You made a choice using a shared file system you don't have write access to in any way. Sounds like a bad choice. :-) -- /peter From maciej at opencsw.org Thu Dec 10 13:47:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 12:47:13 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> Message-ID: On Thu, Dec 10, 2009 at 12:08 PM, James Lee wrote: > On 10/12/09, 11:52:40, Gary Law wrote regarding Re: > [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > >> >> It's how Sun designed it. Just install that package from the global >> >> zone and be done with it. :-) >> > >> > For the record: >> > >> > http://www.opencsw.org/bugtrack/view.php?id=3760 > >> OK, I don't think we should be using classutils then. It violates >> policy. The 'workaround' is clunky for some, and impossible if you >> don't have root on the global zone. > > I support Gary. ?I understand that classutils is clever and works > well in some situations but it's not a complete solution and therefor > we should look for something else. Can we have our own implementation of class action scripts? I know that we can't rework pkgadd, but we can have our own equivalent: a common postinstall script which reads a configuration file and processes files marked in csw-prototype. We could even make it better by allowing one file to have multiple classes. Any other ideas? From maciej at opencsw.org Thu Dec 10 13:56:32 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 12:56:32 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> Message-ID: On Thu, Dec 10, 2009 at 11:52 AM, Gary Law wrote: > HI > > 2009/12/10 Maciej (Matchek) Blizinski : >> On Wed, Dec 2, 2009 at 11:01 PM, Peter Bonivart wrote: >>> It's how Sun designed it. Just install that package from the global >>> zone and be done with it. :-) >> >> For the record: >> >> http://www.opencsw.org/bugtrack/view.php?id=3760 > > OK, I don't think we should be using classutils then. It violates > policy. The 'workaround' is clunky for some, and impossible if you > don't have root on the global zone. It's only impossible if you don't have root on the global zone and you inherit /usr from it. I would say that if you intent to install packages to a Solaris system, it should be either a global zone or a full root zone. Can you ask for conversion of your zone to full root? Maciej From skayser at opencsw.org Thu Dec 10 14:05:01 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 10 Dec 2009 14:05:01 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> Message-ID: <20091210130501.GA7667@sebastiankayser.de> * Peter Bonivart wrote: > On Thu, Dec 10, 2009 at 12:52 PM, Gary Law wrote: > > 2009/12/10 Maciej (Matchek) Blizinski : > >> On Wed, Dec 2, 2009 at 11:01 PM, Peter Bonivart wrote: > >>> It's how Sun designed it. Just install that package from the global > >>> zone and be done with it. :-) > >> > >> For the record: > >> > >> http://www.opencsw.org/bugtrack/view.php?id=3760 > > > > OK, I don't think we should be using classutils then. It violates > > policy. The 'workaround' is clunky for some, and impossible if you > > don't have root on the global zone. > > You made a choice using a shared file system you don't have write > access to in any way. Sounds like a bad choice. :-) Peter, did you experiment with the approach that we came up with during summer camp? Put dummy CAS scripts in the package which hand over to the real CAS scripts in /opt/csw/somewhere. This way we wouldn't need to have our CAS scripts beneath /usr. Does the user get prompted with "do you really want the package to do things that you probably don't care about"? Sebastian From bonivart at opencsw.org Thu Dec 10 14:27:03 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 10 Dec 2009 14:27:03 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> Message-ID: <625385e30912100527i1afbebb1o9c7e35ab5b91fb44@mail.gmail.com> On Thu, Dec 10, 2009 at 1:56 PM, Maciej (Matchek) Blizinski wrote: > On Thu, Dec 10, 2009 at 11:52 AM, Gary Law wrote: >> HI >> >> 2009/12/10 Maciej (Matchek) Blizinski : >>> On Wed, Dec 2, 2009 at 11:01 PM, Peter Bonivart wrote: >>>> It's how Sun designed it. Just install that package from the global >>>> zone and be done with it. :-) >>> >>> For the record: >>> >>> http://www.opencsw.org/bugtrack/view.php?id=3760 >> >> OK, I don't think we should be using classutils then. It violates >> policy. The 'workaround' is clunky for some, and impossible if you >> don't have root on the global zone. > > It's only impossible if you don't have root on the global zone and you > inherit /usr from it. ?I would say that if you intent to install > packages to a Solaris system, it should be either a global zone or a > full root zone. ?Can you ask for conversion of your zone to full root? Not in reply to Maciej but more in general: I have never understood this "I don't have root in the global zone"-issue. If you're only root in the sparse zone, why don't you just ask the global root to install cswclassutils? It's not like asking them to pollute the global zone with an Oracle installation, it's just a few shell scripts. In what situation could this not get done? I doubt much can be done at all at a company that can't provide that minor service. Sorry for not being more understanding but if we're dropping support for an excellent feature I'm not going to work at replacing it. -- /peter From bonivart at opencsw.org Thu Dec 10 15:06:27 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 10 Dec 2009 15:06:27 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091210130501.GA7667@sebastiankayser.de> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> Message-ID: <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> On Thu, Dec 10, 2009 at 2:05 PM, Sebastian Kayser wrote: > Peter, did you experiment with the approach that we came up with during > summer camp? Put dummy CAS scripts in the package which hand over to the > real CAS scripts in /opt/csw/somewhere. This way we wouldn't need to > have our CAS scripts beneath /usr. No, I haven't had time to yet but if that approach works it's the only sane way to go if we're not to take a giant step backwards. > Does the user get prompted with "do you really want the package to do > things that you probably don't care about"? Yes. -- /peter From phil at bolthole.com Thu Dec 10 18:11:31 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 09:11:31 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Wed, Dec 9, 2009 at 11:24 PM, Maciej (Matchek) Blizinski wrote: > > Filed bug 4074 about this issue. > Thanks. > My brain says the right thing to do is: > > 1. Get the alternatives mechanism in place > 2. Modify CSWsudo to use it > 3. Modify CSWsudo_ldap to use it, give it higher priority (if both are > installed at the same time, use sudo.ldap) > 4. Remove the stupid symlink from CSWsudo_common > 5. Release all three packages at the same time > > Does it look good? yes... except if it takes more than a week to implement, in which case, I'd say just release new sudo with the symlink in postinstall. sudo needs upgrading sooner rather than later, for security reasons, I thought. From phil at bolthole.com Thu Dec 10 18:12:54 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 09:12:54 -0800 Subject: [csw-maintainers] need new subversion maintainer? Message-ID: Hi folks, Rupert has not responded to emails in a while. he was the last person to offer to "take over" subversion, which needs a new maintainer. Seems like we need a new takeover offer, so to speak. Anyone? From phil at bolthole.com Thu Dec 10 18:25:33 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 09:25:33 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> Message-ID: On Thu, Dec 10, 2009 at 4:08 AM, James Lee wrote: > On 10/12/09, 11:52:40, Gary Law wrote regarding Re: > >> OK, I don't think we should be using classutils then. It violates >> policy. [of writing to /usr] >> The 'workaround' is clunky for some, and impossible if you >> don't have root on the global zone. > > I support Gary. ?I understand that classutils is clever and works > well in some situations but it's not a complete solution and therefor > we should look for something else. wow. I'm surprised you have that view, James. is this something you actually run into anywhere, or is this a purely abstract, "purity" level objection? For myself, I'm not "happy" with it. but unfortunately, it's the only way sun allows class actions to work. I am very behind class actions, because it is the cleanest way to migrate to IPS [whatever-the-hell-they-are-called], 4 years down the road. The other reason is because it is the only way to avoid prompting the user for trivial pre-approved stuff, while at the same time still allowing the user control for prompting about SERIOUS stuff. In other words: Prompt user for known, understood behaviour for copying conf scripts? no. Prompt user for running a completely new, one-shot complicated postinstall script? YES, if they care about checking out those things. This is important, in my opinion. There is *NO* other solution that allows for this, while still using straight SVR4 pkgadd. You MUST use class action scripts, and they MUST go in /usr. Everything else will be forced to use postinstall script, which will have the prompting problem. From phil at bolthole.com Thu Dec 10 18:25:56 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 09:25:56 -0800 Subject: [csw-maintainers] Replacing existing Solaris functionality by OpenCSW packages In-Reply-To: References: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> Message-ID: On Wed, Dec 9, 2009 at 11:41 PM, Maciej (Matchek) Blizinski wrote: > > One package can't remove another package upon installation, can it? not in pre or postinstall, far as I know, due to pkg database locking issues? not DIRECTLY anyways... there are sneaky workarounds I think. but meanwhile.. > Anyway, about handling the "install all CSW" scenario, isn't it better > to just skip the packages which conflict with already installed ones? And how are you going to define "conflict"? and how are you going to deal with the fact that for our NORMAL operations, standard operation is the exact opposite: REMOVE packages for which newer ones (of ours) conflict. it just doesnt work well. I made a suggestion, which satisfies both "how do we deal with it", and "how do we not mess up existing expected behaviour of our packages". Perhaps you'd like to review the archives and reconsider it. (I dont remember exactly what it was right now, but I do know it fulfilled the above two criteria) From maciej at opencsw.org Thu Dec 10 18:57:07 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 17:57:07 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: <1260210104-sup-2487@ntdws12.chass.utoronto.ca> References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: Moving Here's the alternatives package for you to test: http://mirror.opencsw.org/testing/alternatives-1.15.5.3,REV=2009.12.10-SunOS5.8-all-CSW.pkg.gz To address the concern that the executable name is long: it's not going to be typed by humans. It will be used by postinstall scripts (or class action scripts). It's the Debian's alternatives system, cut out from the dpkg source tarball. How do you like it? Maciej From phil at bolthole.com Thu Dec 10 18:59:46 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 09:59:46 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Dec 10, 2009 at 9:57 AM, Maciej (Matchek) Blizinski wrote: > Here's the alternatives package for you to test: > > http://mirror.opencsw.org/testing/alternatives-1.15.5.3,REV=2009.12.10-SunOS5.8-all-CSW.pkg.gz > > To address the concern that the executable name is long: it's not > going to be typed by humans. ?It will be used by postinstall scripts > (or class action scripts). > Then how will humans specify what they want? From skayser at opencsw.org Thu Dec 10 19:05:31 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 10 Dec 2009 19:05:31 +0100 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: <20091210180531.GC7667@sebastiankayser.de> * Philip Brown wrote: > On Thu, Dec 10, 2009 at 9:57 AM, Maciej (Matchek) Blizinski > wrote: > > Here's the alternatives package for you to test: > > > > http://mirror.opencsw.org/testing/alternatives-1.15.5.3,REV=2009.12.10-SunOS5.8-all-CSW.pkg.gz > > > > To address the concern that the executable name is long: it's not > > going to be typed by humans. ?It will be used by postinstall scripts > > (or class action scripts). > > Then how will humans specify what they want? What's the concern about the command name being too long when we live in an age of shell auto-completion? As a related question: we port a known utility to our platform (Solaris), why not keep the known name? That's what we do with almost all the other software. Sebastian From phil at bolthole.com Thu Dec 10 19:26:31 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 10:26:31 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: <20091210180531.GC7667@sebastiankayser.de> References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> <20091210180531.GC7667@sebastiankayser.de> Message-ID: On Thu, Dec 10, 2009 at 10:05 AM, Sebastian Kayser wrote: > >>... >> Then how will humans specify what they want? > > What's the concern about the command name being too long when we live in > an age of shell auto-completion? my shell doesnt autocomplete, nor do I want it to. >As a related question: we port a known > utility to our platform (Solaris), why not keep the known name? That's > what we do with almost all the other software. well now that you mention it, it might be nice to keep an alias for the "regular name", or vice versa. but I'd still like to see a short(er) name for primary use. From maciej at opencsw.org Thu Dec 10 19:28:36 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 18:28:36 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Dec 10, 2009 at 5:59 PM, Philip Brown wrote: > On Thu, Dec 10, 2009 at 9:57 AM, Maciej (Matchek) Blizinski > wrote: >> Here's the alternatives package for you to test: >> >> http://mirror.opencsw.org/testing/alternatives-1.15.5.3,REV=2009.12.10-SunOS5.8-all-CSW.pkg.gz >> >> To address the concern that the executable name is long: it's not >> going to be typed by humans. ?It will be used by postinstall scripts >> (or class action scripts). >> > > > Then how will humans specify what they want? User, non-maintainer humans? They will use rm and ln to make different symlinks in /etc/opt/csw/alternatives. From maciej at opencsw.org Thu Dec 10 19:40:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 10 Dec 2009 18:40:13 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Thu, Dec 10, 2009 at 5:11 PM, Philip Brown wrote: > On Wed, Dec 9, 2009 at 11:24 PM, Maciej (Matchek) Blizinski > wrote: >> >> Filed bug 4074 about this issue. >> > > Thanks. > >> My brain says the right thing to do is: >> >> 1. Get the alternatives mechanism in place >> 2. Modify CSWsudo to use it >> 3. Modify CSWsudo_ldap to use it, give it higher priority (if both are >> installed at the same time, use sudo.ldap) >> 4. Remove the stupid symlink from CSWsudo_common >> 5. Release all three packages at the same time >> >> Does it look good? > > yes... except if it takes more than a week to implement, in which > case, I'd say just release new sudo with the symlink in postinstall. > sudo needs upgrading sooner rather than later, for security reasons, I thought. There is no security hole, it's even the opposite: the sudo command vanishes, and the system becomes more secure, because users can't get root. Unless they figure out sudo.minimal. There is one thing I'm curious about. If I understand it correctly, the transition from the older scheme (CSWsudo containing /opt/csw/bin/sudo binary) to the new scheme (CSWsudo containing /opt/csw/bin/sudo.minimal and CSWsudo-common containing the symlink), assuming the upgrade order (CSWsudo-common gets upgraded first), must inevitably lead to the problem I described. I find it hard to believe that nobody ran into this problem before and that there were no bug reports. Maintainers, are you sure that the issue hasn't surfaced after the introduction of the symlink? Was there any magic during the upgrade used? Or are our users still stuck to the old package? From what I see in the catalog, even our old stable contains packages with the newer scheme. From phil at bolthole.com Thu Dec 10 20:00:04 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 11:00:04 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Dec 10, 2009 at 10:28 AM, Maciej (Matchek) Blizinski wrote: > On Thu, Dec 10, 2009 at 5:59 PM, Philip Brown wrote: >> >> >> Then how will humans specify what they want? > > User, non-maintainer humans? ?They will use rm and ln to make > different symlinks in /etc/opt/csw/alternatives. > ick. that's rather user-unfriendly. If that's how debian-alternatives does it... lets go one BETTER than debian, eh? From james at opencsw.org Thu Dec 10 20:10:11 2009 From: james at opencsw.org (James Lee) Date: Thu, 10 Dec 2009 19:10:11 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> Message-ID: <20091210.19101100.2415089556@gyor.oxdrove.co.uk> On 10/12/09, 17:25:33, Philip Brown wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > On Thu, Dec 10, 2009 at 4:08 AM, James Lee wrote: > > On 10/12/09, 11:52:40, Gary Law wrote regarding Re: > > > >> OK, I don't think we should be using classutils then. It violates > >> policy. [of writing to /usr] > >> The 'workaround' is clunky for some, and impossible if you > >> don't have root on the global zone. > > > > I support Gary. ?I understand that classutils is clever and works > > well in some situations but it's not a complete solution and therefor > > we should look for something else. > wow. I'm surprised you have that view, James. > is this something you actually run into anywhere, or is this a purely > abstract, "purity" level objection? I have global root access but use zones to provide separation. I have stable production zones and test play zones. I do not want the same version packages in all zones, that includes classutils. Admittedly the classutils is passive until packages are changed so its update does not affect running stability and hence I've tolerated this one exception. There is the possibility that a later classutils won't be compatible with older installed packages when they eventually require update and so I object to the principle of requiring global installation and a common version. Sharing resources is a feature of zones so suggesting using root zones is a poor workaround. I want share the system and separate the /opt/ional software. > There is *NO* other solution that allows for this, while still using > straight SVR4 pkgadd. You MUST use class action scripts, and they MUST > go in /usr. If I had the solution I'd have made a suggestion long ago. I'm saying although I haven't complained myself I do support anyone else for whom it is an issue and I support the quest for an alternative. It might be possible to use the existing build/sed classes and provide developer tools that write the necessary code to work with those classes. I make ghostscript, groff and some others to install the correct paper size using request and the existing build class. I've no idea if the standard classes would work or if another technology is needed but as long as CSW needs to write to /usr there is room for improvement. James. From phil at bolthole.com Thu Dec 10 20:12:18 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 11:12:18 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: On Thu, Dec 10, 2009 at 10:40 AM, Maciej (Matchek) Blizinski wrote: > On Thu, Dec 10, 2009 at 5:11 PM, Philip Brown wrote: >> >> yes... except if it takes more than a week to implement, in which >> case, I'd say just release new sudo with the symlink in postinstall. >> sudo needs upgrading sooner rather than later, for security reasons, I thought. > > There is no security hole, it's even the opposite: ... I meant, I thought there was a version upgrade needed to sudo. huh. interestingly, there wasnt when we started... but there IS now a newer version of sudo. from 4 days ago :-} From phil at bolthole.com Thu Dec 10 20:55:49 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 10 Dec 2009 11:55:49 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091210.19101100.2415089556@gyor.oxdrove.co.uk> References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> <20091210.19101100.2415089556@gyor.oxdrove.co.uk> Message-ID: On Thu, Dec 10, 2009 at 11:10 AM, James Lee wrote: > > There is the possibility that a later classutils won't be compatible with > older installed packages when they eventually require update and so I > object to the principle of requiring global installation and a common > version. Well, if we were talking about [random anonymous 3rd party vendor], I can see how this is a concern. but seeing as how WE are the vendor... I think we can put this concern to bed fairly easily ;-) A quick off-the-cuff solution: We declare that classutils implementations must be backwards compatible. If you want to do something incompatible,you must do it in a newly named class. Problem solved? > If I had the solution I'd have made a suggestion long ago. ?I'm saying > although I haven't complained myself I do support anyone else for whom > it is an issue and I support the quest for an alternative. ah. fair enough there. i wouldnt ever say "this is perfect, i'm going to ignore any other proposals for alternatives". I would say that I just want other alternatives to be *at least as good*. > It might be possible to use the existing build/sed classes and provide > developer tools that write the necessary code to work with those classes. > I make ghostscript, groff and some others to install the correct paper > size using request and the existing build class. ?I've no idea if the > standard classes would work or if another technology is needed but as > long as CSW needs to write to /usr there is room for improvement. Well, there are probably some things for which we can use existing sun provided classes. But they ARE *very* limited. From maciej at opencsw.org Fri Dec 11 08:29:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 11 Dec 2009 07:29:58 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Dec 10, 2009 at 7:00 PM, Philip Brown wrote: > On Thu, Dec 10, 2009 at 10:28 AM, Maciej (Matchek) Blizinski > wrote: >> On Thu, Dec 10, 2009 at 5:59 PM, Philip Brown wrote: >>> >>> >>> Then how will humans specify what they want? >> >> User, non-maintainer humans? ?They will use rm and ln to make >> different symlinks in /etc/opt/csw/alternatives. >> > > ick. that's rather user-unfriendly. On the contrary, this is exactly why it's user friendly. You don't have to know about update-alternatives command line to manage your alternatives. If you want to change which sudo to use, you can go /etc/opt/csw/alternatives, replace existing symlink with the one you want and be done with it. The next time you upgrade sudo or sudo_ldap, update-alternatives will notice that the symlink has been changed, and it won't touch it. It's similar to the way we currently handle configuration files. Of course, nothing prevents humans from using the update-alternatives command line. If someone wants to type less, they should be intelligent enough to use the power of alias. From glaw at opencsw.org Fri Dec 11 08:35:07 2009 From: glaw at opencsw.org (Gary Law) Date: Fri, 11 Dec 2009 07:35:07 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <625385e30912100527i1afbebb1o9c7e35ab5b91fb44@mail.gmail.com> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100527i1afbebb1o9c7e35ab5b91fb44@mail.gmail.com> Message-ID: Hi 2009/12/10 Peter Bonivart : > I have never understood this "I don't have root in the global > zone"-issue. If you're only root in the sparse zone, why don't you > just ask the global root to install cswclassutils? It's not like > asking them to pollute the global zone with an Oracle installation, > it's just a few shell scripts. > > In what situation could this not get done? I doubt much can be done at > all at a company that can't provide that minor service. If you're buying a Solaris VM service based on zones then it might not be an option (which is the position for one of my machines). Or, if it is, it might take a long time to get done. Not only that, if you are in this position CSWcswclassutils will install (and fail, with a partially installed error message) but dependent software will still install (using pkg-get or pkgutil) and then not work. At the very least CSWcswclassutils should test the writability of /usr, and bail if it can't. > Sorry for not being more understanding but if we're dropping support > for an excellent feature I'm not going to work at replacing it. I've just done a lot of work, and Maciej has done a lot more, getting one of my packages in GAR. The package now doesn't start/stop on my test rig which means it fails my tests. I was surprised that we're writing in /usr and don't remember the robust debate on this channel which I'm sure would have accompanied the proposal to start doing so. I guess I wasn't paying attention that day. Gary -- glaw at opencsw.org From glaw at opencsw.org Fri Dec 11 08:45:42 2009 From: glaw at opencsw.org (Gary Law) Date: Fri, 11 Dec 2009 07:45:42 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> <20091210.19101100.2415089556@gyor.oxdrove.co.uk> Message-ID: 2009/12/10 Philip Brown : > A quick off-the-cuff solution: > > We declare that classutils implementations must be backwards > compatible. If you want to do something incompatible,you must do it in > a newly named class. > > Problem solved? Might be if there were no-one out there shipping identically named utils installing in the same place, who might just go ahead and upgrade thiers in an incompatible way. But there is. This is a general problem obviously, not just for this package and classutils, which opencsw and blastwave persist in ignoring. As for the question of how we reimplement something which we've done, which IMHO we should not have done, with an identical feature set I don't know (I simply don't understand enough about the features of classutils to make a suggestion at this stage). I'll have a think, and maybe pick some brains on IRC at a better time.[1] Gary [1] Right now I'm in an airport departure lounge after getting up far too early this morning -- glaw at opencsw.org From glaw at opencsw.org Fri Dec 11 08:49:51 2009 From: glaw at opencsw.org (Gary Law) Date: Fri, 11 Dec 2009 07:49:51 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: 2009/12/10 Philip Brown : > ick. that's rather user-unfriendly. > If that's how debian-alternatives does it... lets go one BETTER than debian, eh? -1. I suggest copy Debian, bugs and all, first. Then think about improving it if/when we get some feedback. Personally I like the alternatives system, it's 'unixy' in all the right ways. Gary -- glaw at opencsw.org From james at opencsw.org Fri Dec 11 10:44:16 2009 From: james at opencsw.org (James Lee) Date: Fri, 11 Dec 2009 09:44:16 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> <20091210.19101100.2415089556@gyor.oxdrove.co.uk> Message-ID: <20091211.9441600.2229441902@gyor.oxdrove.co.uk> On 10/12/09, 19:55:49, Philip Brown wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > > If I had the solution I'd have made a suggestion long ago. ?I'm saying > > although I haven't complained myself I do support anyone else for whom > > it is an issue and I support the quest for an alternative. > ah. fair enough there. i wouldnt ever say "this is perfect, i'm going > to ignore any other proposals for alternatives". I would say that I > just want other alternatives to be *at least as good*. I define better as not writing to /usr. > > It might be possible to use the existing build/sed classes and provide > > developer tools that write the necessary code to work with those classes. > > I make ghostscript, groff and some others to install the correct paper > > size using request and the existing build class. ?I've no idea if the > > standard classes would work or if another technology is needed but as > > long as CSW needs to write to /usr there is room for improvement. > Well, there are probably some things for which we can use existing sun > provided classes. > But they ARE *very* limited. The build class runs the 2 scripts supplied in the package file so isn't limited. James. From phil at bolthole.com Fri Dec 11 17:51:19 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Dec 2009 08:51:19 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <20091210.12084000.2793710856@gyor.oxdrove.co.uk> <20091210.19101100.2415089556@gyor.oxdrove.co.uk> Message-ID: On Thu, Dec 10, 2009 at 11:45 PM, Gary Law wrote: > 2009/12/10 Philip Brown : >> A quick off-the-cuff solution: >> >> We declare that classutils implementations must be backwards >> compatible. If you want to do something incompatible,you must do it in >> a newly named class. >> >> Problem solved? > > Might be if there were no-one out there shipping identically named > utils installing in the same place, who might just go ahead and > upgrade thiers in an incompatible way. But there is. > no one else (who matters...) is going to be shipping any pkg class utils named "cswxxxx". our namespace is safe. From phil at bolthole.com Fri Dec 11 17:58:44 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Dec 2009 08:58:44 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Dec 10, 2009 at 11:29 PM, Maciej (Matchek) Blizinski wrote: > On Thu, Dec 10, 2009 at 7:00 PM, Philip Brown wrote: >> >> >> ick. that's rather user-unfriendly. > > On the contrary, this is exactly why it's user friendly. ?You don't > have to know about update-alternatives command line to manage your > alternatives. But you DO have to know in depth about your target program. You might not KNOW all the places you need to symlink, as a user. picture sendmail. It has MULTIPLE things that need to be replaced. sendmail itself, plus mailq, plus newaliases, (and possibly more?) The most userfriendly thing to do, is provide a nice simple one-stop interface, that allows the user to say, [i want CSWpostfix to completely replace the functionality of sendmail on my box] the ANTI-friendly thing to do, is to default the user to, [it's up to you to know and remember all the places sun sendmail has hooks into your system] > ?If someone wants to type less, they should be > intelligent enough to use the power of alias. This is a very bad attitude in my opinion. You are essentially saying "well, we COULD make things easier for the user... but we choose to make them do the work themselves". "update-alternatives" is a *20 character command*. Gary extols the virtues of doing things in a "unixy way". I would point out that having ludicrously long command names is not a "unixy way". Rather, the opposite. > Of course, nothing prevents humans from using the update-alternatives > command line. From phil at bolthole.com Fri Dec 11 18:00:47 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Dec 2009 09:00:47 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Dec 10, 2009 at 11:49 PM, Gary Law wrote: > 2009/12/10 Philip Brown : >> ick. that's rather user-unfriendly. >> If that's how debian-alternatives does it... lets go one BETTER than debian, eh? > > -1. I suggest copy Debian, bugs and all, first. Then think about > improving it if/when we get some feedback. Personally I like the > alternatives system, it's 'unixy' in all the right ways. Errr.. we're not implementing "WINE" here. we have no reward for copying the BUGS :-} I like the concept of the alternatives system. I'm suggesting we implement debian normal behavior, and then *augment* it, to be better. Such as, including a short-command invocation. From maciej at opencsw.org Sat Dec 12 02:27:14 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 12 Dec 2009 01:27:14 +0000 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file Message-ID: Suppose I have a file CSWfoo.postinstall, which has some variables which need to be substituted before the file can be shipped. Something along the lines of: mycommand=@bindir@/foo Is it possible to preprocess a postinstall file like that? At which stage should it be done? From phil at bolthole.com Sat Dec 12 02:58:43 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 11 Dec 2009 17:58:43 -0800 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: Message-ID: On Fri, Dec 11, 2009 at 5:27 PM, Maciej (Matchek) Blizinski wrote: > Suppose I have a file CSWfoo.postinstall, which has some variables > which need to be substituted before the file can be shipped. > Something along the lines of: > > mycommand=@bindir@/foo > > Is it possible to preprocess a postinstall file like that? ?At which > stage should it be done? its impossible to answer that without you specifying where the data to be substituted, comes *from*. From bwalton at opencsw.org Sat Dec 12 03:53:48 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 11 Dec 2009 21:53:48 -0500 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: Message-ID: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Dec 11 20:27:14 -0500 2009: > Suppose I have a file CSWfoo.postinstall, which has some variables > which need to be substituted before the file can be shipped. > Something along the lines of: > > mycommand=@bindir@/foo Use the dynamic adm script capability in GAR. See docbook-style-xsl: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/docbook-style-xsl/trunk/Makefile http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/docbook-style-xsl/trunk/files/CSWdocbookxsl.postinstall Just be careful to $$ when you need to use a shell variable as the script is subject to regular Makefile expansion rules. Also, the final product will be much less readable than a normal script. Is this what you're after? 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 Dec 12 08:05:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 12 Dec 2009 08:05:26 +0100 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: Message-ID: <2FD57AEC-D3E7-4533-ACE7-3B0A351B6D13@opencsw.org> Hi Maciej, Am 12.12.2009 um 02:27 schrieb Maciej (Matchek) Blizinski: > Suppose I have a file CSWfoo.postinstall, which has some variables > which need to be substituted before the file can be shipped. > Something along the lines of: > > mycommand=@bindir@/foo > > Is it possible to preprocess a postinstall file like that? At which > stage should it be done? The natural place for this is in post-install-modulated. However, you may also do it during post-merge or in a custom-merge rule doing substitute-copy in one step. Best regards -- Dago From maciej at opencsw.org Sun Dec 13 00:09:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 12 Dec 2009 23:09:47 +0000 Subject: [csw-maintainers] Font packages In-Reply-To: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> References: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> Message-ID: On Wed, Apr 1, 2009 at 3:58 PM, Alexander Maier wrote: > Am 31.03.2009 um 12:20 schrieb Maciej (Matchek) Blizinski: > >> How do we go about adding font packages? Let's suppose I have a font >> what I want to package. Let it be Terminus[1], for the sake of the >> exercise. Can it be somehow integrated with Sun-provided X server in >> Solaris 10? Are there established practices about including fonts in >> OpenCSW? >> > > > I think one have to distinguish between fonts for "classic X apps" with > local/remote xfs and fonts for apps using libfreetype/fontconfig (based on > GTK or Qt). > > In the latter case I would suggest to put these fonts into > /opt/csw/share/fonts (e.g. Microsoft TrueType fonts or Red Hat Liberation > fonts). > > Terminus seems to be a classic X11/Motif font, so it would probably be > better off somewhere below /opt/csw/X11 (as Phil has suggested). Speaking of TTF fonts, is it possible to achieve the effect of making the font package "just work"? I mean that the fonts would just appear in the font lists after installing a font package. It works that way if one puts fonts into /usr/openwin/lib/X11/fonts/TrueType but the OpenCSW policy prohibits putting anything there. What is the least invasive way of going about it? Fiddling with configuration in /etc? (this would require X restart for the change to take effect) Releasing an update to fontconfig and adding a new fonts directory under /opt/csw? Maciej From rupert at opencsw.org Sun Dec 13 00:43:48 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 13 Dec 2009 00:43:48 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> Message-ID: <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> will do tomorrow, when i get back to the computer with the login keys on it :) sorry for beeing slow. my main problem is that in my day job i am sitting behind a firewall which does not allow me access opencsw emails, and also not looging in to build/submit so i have a slow reaction time. therefor i would not mind if somebody submits the packages without asking and waiting for a response, which might come up to 2 weeks later. rupert On Mon, Nov 30, 2009 at 18:47, Philip Brown wrote: > On Sat, Nov 28, 2009 at 5:01 AM, Dagobert Michelsen > wrote: > > > > I am already working on a version-modulated OpenLDAP package including > the > > previous shared version. In the meantime I removed the broken OpenLDAP > > package. > > > > oh good. in that case I guess the subversion in testing can be > released? Please officially submit it Rupert? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Sun Dec 13 20:43:47 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 13 Dec 2009 20:43:47 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> Message-ID: Hi Rupert, Am 13.12.2009 um 00:43 schrieb rupert THURNER: > will do tomorrow, when i get back to the computer with the login keys on it :) sorry for beeing slow. > > my main problem is that in my day job i am sitting behind a firewall which does not allow me access opencsw emails, and also not looging in to build/submit so i have a slow reaction time. > > therefor i would not mind if somebody submits the packages without asking and waiting for a response, which might come up to 2 weeks later. No, no, we are grateful that you do this at all given your restrictions. Just let the list know when your timeframe gets even fuller :-) Please go ahead. Best regards -- Dago From rupert at opencsw.org Sun Dec 13 21:54:33 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 13 Dec 2009 21:54:33 +0100 Subject: [csw-maintainers] Fwd: [trac 0004077]: undeclared dependency on python_devel In-Reply-To: <5227c158cd8ba1432ab4a77f045f8334@www.opencsw.org> References: <5227c158cd8ba1432ab4a77f045f8334@www.opencsw.org> Message-ID: <6af4270912131254i6ab989e2sb8bc29633861c532@mail.gmail.com> hi, can the python specialists amongst you drop a line on this bug report? how is python devel, setuptools and distutils interconnected, and which package contains what? rupert. ---------- Forwarded message ---------- From: Mantis Bug Tracker Date: Fri, Dec 11, 2009 at 09:22 Subject: [trac 0004077]: undeclared dependency on python_devel To: rupert at opencsw.org The following issue has been SUBMITTED. ====================================================================== http://www.opencsw.org/bugtrack/view.php?id=4077 ====================================================================== Reported By: pfelecan Assigned To: ====================================================================== Project: trac Issue ID: 4077 Category: packaging Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2009-12-11 09:22 CET Last Modified: 2009-12-11 09:22 CET ====================================================================== Summary: undeclared dependency on python_devel Description: After installing trac, trying to get help: trac-admin help we get: Traceback (most recent call last): File "/opt/csw/bin/trac-admin", line 5, in from pkg_resources import load_entry_point File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 657, in class Environment(object): File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 660, in Environment def __init__(self, search_path=None, platform=get_supported_platform(), python=PY_MAJOR): File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 55, in get_supported_platform plat = get_build_platform(); m = macosVersionString.match(plat) File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 186, in get_build_platform from distutils.util import get_platform ImportError: No module named distutils.util After installing python_devel, everything seems alright. ====================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Dec 13 22:06:45 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 13 Dec 2009 21:06:45 +0000 Subject: [csw-maintainers] Fwd: [trac 0004077]: undeclared dependency on python_devel In-Reply-To: <6af4270912131254i6ab989e2sb8bc29633861c532@mail.gmail.com> References: <5227c158cd8ba1432ab4a77f045f8334@www.opencsw.org> <6af4270912131254i6ab989e2sb8bc29633861c532@mail.gmail.com> Message-ID: On Sun, Dec 13, 2009 at 8:54 PM, rupert THURNER wrote: > hi, > > can the python specialists amongst you drop a line on this bug report? how > is python devel, setuptools and distutils interconnected, and which package > contains what? The problem is that distutils (the distutils module which you import by "import distutils") isn't included in CSWpython, but in CSWpython-devel instead. I believe that distutils should be included in CSWpython. I've already filed a bug report about this: http://www.opencsw.org/mantis/view.php?id=3967 However, Mike Watters is on sabbatical, so we can't expect this to change anytime soon, unless someone else takes over the package. Maciej From phil at bolthole.com Mon Dec 14 17:12:43 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Dec 2009 08:12:43 -0800 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> Message-ID: On Sat, Dec 12, 2009 at 3:43 PM, rupert THURNER wrote: > > my main problem is that in my day job i am sitting behind a firewall which > does not allow me access opencsw emails, and also not looging in to > build/submit so i have a slow reaction time. > What does the firewall allow? From phil at bolthole.com Mon Dec 14 17:21:27 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Dec 2009 08:21:27 -0800 Subject: [csw-maintainers] Font packages In-Reply-To: References: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> Message-ID: On Sat, Dec 12, 2009 at 3:09 PM, Maciej (Matchek) Blizinski wrote: > Speaking of TTF fonts, is it possible to achieve the effect of making > the font package "just work"? ?I mean that the fonts would just appear > in the font lists after installing a font package. > > It works that way if one puts fonts into > /usr/openwin/lib/X11/fonts/TrueType but the OpenCSW policy prohibits > putting anything there. ?What is the least invasive way of going about > it? ?Fiddling with configuration in /etc? (this would require X > restart for the change to take effect) Releasing an update to > fontconfig and adding a new fonts directory under /opt/csw? > Huh. I thougth we already had an X11 fonts dir. but it would seem we do not. Soooo... yeah, we should have an official CSW fonts dir for X. Presumably /opt/csw/X11/fonts ? But then for fonts that are not strictly X only, we have the question of ..."well, what about non-X things, that still want access to true type fonts?" We have more than one package that provides some hooks for truetype fonts. tetex, for one. openoffice, for another. From dam at opencsw.org Mon Dec 14 17:31:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 14 Dec 2009 17:31:43 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> Message-ID: <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> Hi, Am 14.12.2009 um 17:12 schrieb Philip Brown: > On Sat, Dec 12, 2009 at 3:43 PM, rupert THURNER > wrote: >> >> my main problem is that in my day job i am sitting behind a >> firewall which >> does not allow me access opencsw emails, and also not looging in to >> build/submit so i have a slow reaction time. >> > > What does the firewall allow? I could setup wither SSH on 443 to allow tunneling with proxy connect or Sun SGD for a real webconnect if that would help you. Best regards -- Dago From phil at bolthole.com Mon Dec 14 18:21:35 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Dec 2009 09:21:35 -0800 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> Message-ID: On Mon, Dec 14, 2009 at 8:31 AM, Dagobert Michelsen wrote: > > > I could setup wither SSH on 443 to allow tunneling with > proxy connect or Sun SGD for a real webconnect if that would > help you. > For those not familiar with the acronym, that's "Sun(or "secure"?) Global Desktop". sorta like VNC over https kinda. From rupert at opencsw.org Mon Dec 14 19:01:29 2009 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 14 Dec 2009 19:01:29 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: References: <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> Message-ID: <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> On Mon, Dec 14, 2009 at 18:21, Philip Brown wrote: > On Mon, Dec 14, 2009 at 8:31 AM, Dagobert Michelsen > wrote: > > > > > > I could setup wither SSH on 443 to allow tunneling with > > proxy connect or Sun SGD for a real webconnect if that would > > help you. > > > > For those not familiar with the acronym, that's "Sun(or "secure"?) > Global Desktop". > > sorta like VNC over https > > oh, then this would definitely help. http(s) is only blocked to public mailers. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon Dec 14 21:45:57 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 14 Dec 2009 21:45:57 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> References: <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> Message-ID: <2A4937DB-0B66-4E92-BA39-E972CB88FC3A@opencsw.org> Hi, Am 14.12.2009 um 19:01 schrieb rupert THURNER: > On Mon, Dec 14, 2009 at 18:21, Philip Brown wrote: > On Mon, Dec 14, 2009 at 8:31 AM, Dagobert Michelsen > wrote: > > > > > > I could setup wither SSH on 443 to allow tunneling with > > proxy connect or Sun SGD for a real webconnect if that would > > help you. > > > > For those not familiar with the acronym, that's "Sun(or "secure"?) > Global Desktop". > > sorta like VNC over https > > oh, then this would definitely help. http(s) is only blocked to > public mailers. I'll see what I can do. BTW, this also means real passwords on 'login' in addition to ssh keys. Best regards -- Dago From skayser at opencsw.org Tue Dec 15 01:02:19 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 15 Dec 2009 01:02:19 +0100 Subject: [csw-maintainers] OpenCSW Winter Camp - 23/24 Jan 2010. Who is coming? In-Reply-To: <20091203114056.GA26420@sebastiankayser.de> References: <20091203114056.GA26420@sebastiankayser.de> Message-ID: <4B26D20B.4020506@opencsw.org> Sebastian Kayser wrote on 03.12.2009 12:40: > the venue and dates are fixed. Winter Camp will get us together in a > cosy seminar hotel near the Bavarian mountains on 23.01./24.01. next > year. > > http://wiki.opencsw.org/wintercamp-2009 > > I have updated the wiki page with details. The hotel doesn't have a > online booking system, so those of you who can make their way please > send me an email (by 17.12.2009) so that I can let them know with > how many people we are attending and take care of the room bookings. > > Except for the room rate (approx 60EUR / night for a single) everything > will be covered by the company I work for, so you just need to get > there. :) > > Any questions, just let me know. Hope to see you there. Ping, anyone else? I would like to confirm the booking this Thursday and so far the lists consists of the following people - Dagobert Michelsen - Maciej Blizinski - Trygve Laugstol - Benny von Mossner - Alexander Maier - me William, Dominique? There is some good beer to have in Bavaria ;) Sebastian From phil at bolthole.com Tue Dec 15 01:05:55 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 14 Dec 2009 16:05:55 -0800 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> References: <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> Message-ID: On Mon, Dec 14, 2009 at 10:01 AM, rupert THURNER wrote: > > > oh, then this would definitely help. http(s) is only blocked to public > mailers. > Do you have ssh access though? From maciej at opencsw.org Tue Dec 15 10:03:26 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Dec 2009 09:03:26 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: On Thu, Dec 10, 2009 at 7:12 PM, Philip Brown wrote: > On Thu, Dec 10, 2009 at 10:40 AM, Maciej (Matchek) Blizinski > wrote: >> On Thu, Dec 10, 2009 at 5:11 PM, Philip Brown wrote: >>> >>> yes... except if it takes more than a week to implement, in which >>> case, I'd say just release new sudo with the symlink in postinstall. >>> sudo needs upgrading sooner rather than later, for security reasons, I thought. >> >> There is no security hole, it's even the opposite: ... > > I meant, I thought there was a version upgrade needed to sudo. > > huh. interestingly, there wasnt when we started... but there IS now a > newer version of sudo. > > from 4 days ago :-} Postinstall also needs to be implemented and tested. I think that if it's a security update it can go without any other changes: preserve the existing package structure, upgrade from p1 to p2. We can quibble about symlinks/alternatives later. Upgraded sudo packages are in testing/. Version bump is the only change. I haven't changed any file locations, or permissions, or anything else. Version bump, period. I haven't tested these packages, since I'm using my own sudo packages at the moment. Would you please test the packages if they work for you? Maciej From maciej at opencsw.org Tue Dec 15 10:46:34 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Dec 2009 09:46:34 +0000 Subject: [csw-maintainers] GPG, agent, pinentry and keychain Message-ID: I'd like to tell you about the packaging work I've done with relation to cryptographic key management. There are 3 main packages that are related to it: - gnupg_agent - pinentry - keychain The idea is to hold an unlocked key in the memory, using gpg-agent. When you need to use your private key, gpg talks to gpg-agent, which provides it with an unlocked key. In this way, you can browse e-mail encrypted to you without typing in your password each time you want to open an encrypted e-mail. Pinentry is a small utility which allows entering passwords to gpg-agent. I've compiled two backends, gtk2 and curses. The way to use the agent-pinentry-keychain combo: - install the three packages - put the following lines in your shell configuration (e.g. ~/.bash_profile) keychain 1234ABCD . ~/.keychain/$HOSTNAME-sh-gpg ...where 1234ABCD is your gpg key's shortened fingerprint. If you also want to do the same thing (unlock a key) with ssh keys, you can do: keychain id_dsa id_rsa 1234ABCD . ~/.keychain/$HOSTNAME-sh . ~/.keychain/$HOSTNAME-sh-gpg Use id_dsa and/or id_rsa depending on which keys you have. This is a more secure way to provide paswordless ssh logins, compared to unprotected private ssh keys. After putting the configuration into your shell run control file / config file, you'll be asked to unlock your keys during login. Your unlocked key will be preserved between shell sessions and will expire with time. The gnupg_agent can be used with both gpg 1.x and 2.x. It's available as part of gpg 2.x source distribution, so I've packaged it separately. gnupg_agent is in testing/. Maciej From james at opencsw.org Tue Dec 15 11:28:05 2009 From: james at opencsw.org (James Lee) Date: Tue, 15 Dec 2009 10:28:05 GMT Subject: [csw-maintainers] Font packages In-Reply-To: References: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> Message-ID: <20091215.10280500.1365323061@gyor.oxdrove.co.uk> On 14/12/09, 16:21:27, Philip Brown wrote regarding Re: [csw-maintainers] Font packages: > I thougth we already had an X11 fonts dir. but it would seem we do not. > Soooo... yeah, we should have an official CSW fonts dir for X. > Presumably /opt/csw/X11/fonts ? We had decided on: /opt/csw/share/fonts/${FORMAT}/ > But then for fonts that are not strictly X only, we have the question > of ..."well, what about non-X things, that still want access to true > type fonts?" Correct, fonts are used by X, they are not X. > We have more than one package that provides some hooks for truetype > fonts. > tetex, for one. > openoffice, for another. There's no Bitstream Vera in OOo at the moment. There are many fonts available (free for download) but Solaris comes with more and better fonts as standard than competitive systems so to me CSW fonts aren't important. I don't need the Liberation Fonts because I don't need liberating, neither do I need yet another clone of Helvetica or Times Roman. Ideally fonts should be in a common /opt/csw/share/fonts/ directory and the default font paths set in the apps. The problem is programs that index the installed fonts so adding fonts to the directory needs a way of notifying the apps, eg, Gostscript's Fontmap.GS. James. From phil at bolthole.com Tue Dec 15 17:45:21 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Dec 2009 08:45:21 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: On Tue, Dec 15, 2009 at 1:03 AM, Maciej (Matchek) Blizinski wrote: > > Upgraded sudo packages are in testing/. ?Version bump is the only > change. ?I haven't changed any file locations, or permissions, or > anything else. ?Version bump, period. > there is at least ONE "known bug", that you havent fixed: perms on sudo_ldap. please fix that. From rupert at opencsw.org Tue Dec 15 17:51:50 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 15 Dec 2009 17:51:50 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: References: <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> Message-ID: <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> from work? no, nothing but http/s. but i will ask them if i get an exception for ssh to opencsw. rupert. On Tue, Dec 15, 2009 at 01:05, Philip Brown wrote: > On Mon, Dec 14, 2009 at 10:01 AM, rupert THURNER > wrote: > > > > > > oh, then this would definitely help. http(s) is only blocked to public > > mailers. > > > > Do you have ssh access though? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Tue Dec 15 17:57:34 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 15 Dec 2009 17:57:34 +0100 Subject: [csw-maintainers] make platforms, PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" Message-ID: <6af4270912150857pbb3fdd8ic1b7daaee7977b0d@mail.gmail.com> hi, what would be the best way to use the multicore architecture and "make platforms" at the same time? usually i do PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" gmake clean package now i tried with gmake platforms which works great, but it does not parallelize on the target. or it maybe does but not the way i call it. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Tue Dec 15 17:59:24 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 15 Dec 2009 17:59:24 +0100 Subject: [csw-maintainers] mod_wsgi-3.1 in testing - this should support python-2.6 and python-3.1 Message-ID: <6af4270912150859x3ea92465qd722db5342ef3bf6@mail.gmail.com> hi, mod_wsgi-3.1 is now in testing - this should support python-2.6 and python-3.1. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Tue Dec 15 18:10:10 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 15 Dec 2009 18:10:10 +0100 Subject: [csw-maintainers] trac-0.11.6 upgrade, CSWgenshi not found? Message-ID: <6af4270912150910l179db3b7r4e93f812513703d3@mail.gmail.com> hi, i tried to upgrade the trac package. building gives system CSWcommon common - common files and dirs for CSW packages application CSWcswclassutils cswclassutils - CSW class action utilities ERROR: information for "CSWgenshi" was not found ERROR: Invalid package CSWgenshi specified. Check of /tmp/trac-0.11.6,REV=2009.12.15-SunOS5.8-sparc-CSW.pkg.gz fails gmake: *** [pkgcheck-CSWtrac] Error 2 where this could come from? i checked it in as well, so it should be easier to reproduce. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Tue Dec 15 18:14:11 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Dec 2009 09:14:11 -0800 Subject: [csw-maintainers] Font packages In-Reply-To: <20091215.10280500.1365323061@gyor.oxdrove.co.uk> References: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> <20091215.10280500.1365323061@gyor.oxdrove.co.uk> Message-ID: On Tue, Dec 15, 2009 at 2:28 AM, James Lee wrote: > > Ideally fonts should be in a common /opt/csw/share/fonts/ directory > and the default font paths set in the apps. ?The problem is programs > that index the installed fonts so adding fonts to the directory needs > a way of notifying the apps, eg, Gostscript's Fontmap.GS. > please propose something? From bwalton at opencsw.org Tue Dec 15 18:24:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 15 Dec 2009 12:24:12 -0500 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> References: <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> Message-ID: <1260896801-sup-2625@ntdws12.chass.utoronto.ca> Excerpts from rupert THURNER's message of Tue Dec 15 11:51:50 -0500 2009: Hi Rupert, > from work? no, nothing but http/s. but i will ask them if i get an exception > for ssh to opencsw. If you don't mind me asking, where do you work? Your firewall seems extremely restrictive. 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 Dec 15 18:58:20 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Dec 2009 17:58:20 +0000 Subject: [csw-maintainers] make platforms, PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" In-Reply-To: <6af4270912150857pbb3fdd8ic1b7daaee7977b0d@mail.gmail.com> References: <6af4270912150857pbb3fdd8ic1b7daaee7977b0d@mail.gmail.com> Message-ID: On Tue, Dec 15, 2009 at 4:57 PM, rupert THURNER wrote: > hi, > > what would be the best way to use the multicore architecture and "make > platforms" at the same time? > > usually i do > > PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" > gmake clean package > > now i tried with > > gmake platforms > > which works great, but it does not parallelize on the target. or it maybe > does but not the way i call it. I've put PARALLELMFLAGS into my ~/.garrc. From maciej at opencsw.org Tue Dec 15 19:00:23 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Dec 2009 18:00:23 +0000 Subject: [csw-maintainers] trac-0.11.6 upgrade, CSWgenshi not found? In-Reply-To: <6af4270912150910l179db3b7r4e93f812513703d3@mail.gmail.com> References: <6af4270912150910l179db3b7r4e93f812513703d3@mail.gmail.com> Message-ID: On Tue, Dec 15, 2009 at 5:10 PM, rupert THURNER wrote: > where this could come from? i checked it in as well, so it should be easier > to reproduce. Ask buildfarm@ to install the CSWgenshi package for you. (assuming it's been released) From maciej at opencsw.org Tue Dec 15 19:49:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Dec 2009 18:49:47 +0000 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> References: <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> Message-ID: On Tue, Dec 15, 2009 at 4:51 PM, rupert THURNER wrote: > from work? no, nothing but http/s. but i will ask them if i get an exception > for ssh to opencsw. Yes, it's generally better to get the permission rather than pierce the firewall, which might violate company's security policy. Not that the security policies always make sense. From maciej at opencsw.org Tue Dec 15 21:57:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 15 Dec 2009 20:57:01 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: On Tue, Dec 15, 2009 at 4:45 PM, Philip Brown wrote: > On Tue, Dec 15, 2009 at 1:03 AM, Maciej (Matchek) Blizinski > wrote: >> >> Upgraded sudo packages are in testing/. ?Version bump is the only >> change. ?I haven't changed any file locations, or permissions, or >> anything else. ?Version bump, period. >> > > there is at least ONE "known bug", that you havent fixed: perms on sudo_ldap. > please fix that. I'll pass for now. I'm offering only the version bump. From skayser at opencsw.org Tue Dec 15 22:03:32 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 15 Dec 2009 22:03:32 +0100 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: <4B27F9A4.8060100@opencsw.org> Hi Maciej, Maciej (Matchek) Blizinski wrote on 15.12.2009 10:03: > On Thu, Dec 10, 2009 at 7:12 PM, Philip Brown wrote: >> On Thu, Dec 10, 2009 at 10:40 AM, Maciej (Matchek) Blizinski >> wrote: >>> On Thu, Dec 10, 2009 at 5:11 PM, Philip Brown wrote: >>>> yes... except if it takes more than a week to implement, in which >>>> case, I'd say just release new sudo with the symlink in postinstall. >>>> sudo needs upgrading sooner rather than later, for security reasons, I thought. >>> There is no security hole, it's even the opposite: ... >> I meant, I thought there was a version upgrade needed to sudo. >> >> huh. interestingly, there wasnt when we started... but there IS now a >> newer version of sudo. >> >> from 4 days ago :-} > > Postinstall also needs to be implemented and tested. I think that if > it's a security update it can go without any other changes: preserve > the existing package structure, upgrade from p1 to p2. We can quibble > about symlinks/alternatives later. > > Upgraded sudo packages are in testing/. Version bump is the only > change. I haven't changed any file locations, or permissions, or > anything else. Version bump, period. > > I haven't tested these packages, since I'm using my own sudo packages > at the moment. would it make sense to add what you are currently maintaing for yourself to our sudo packages (and then adopt the CSW sudo packages) or are your changes too custom/environment-specific? Sebastian From skayser at opencsw.org Tue Dec 15 22:07:47 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 15 Dec 2009 22:07:47 +0100 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <320B6E41-BA5C-4551-BD57-5592F218B8AF@opencsw.org> Message-ID: <4B27FAA3.9030903@opencsw.org> Maciej (Matchek) Blizinski wrote on 10.12.2009 19:40: > On Thu, Dec 10, 2009 at 5:11 PM, Philip Brown wrote: >> On Wed, Dec 9, 2009 at 11:24 PM, Maciej (Matchek) Blizinski >> wrote: >>> Filed bug 4074 about this issue. >>> >> Thanks. >> >>> My brain says the right thing to do is: >>> >>> 1. Get the alternatives mechanism in place >>> 2. Modify CSWsudo to use it >>> 3. Modify CSWsudo_ldap to use it, give it higher priority (if both are >>> installed at the same time, use sudo.ldap) >>> 4. Remove the stupid symlink from CSWsudo_common >>> 5. Release all three packages at the same time >>> >>> Does it look good? >> yes... except if it takes more than a week to implement, in which >> case, I'd say just release new sudo with the symlink in postinstall. >> sudo needs upgrading sooner rather than later, for security reasons, I thought. > > There is no security hole, it's even the opposite: the sudo command > vanishes, and the system becomes more secure, because users can't get > root. Unless they figure out sudo.minimal. > > There is one thing I'm curious about. If I understand it correctly, > the transition from the older scheme (CSWsudo containing > /opt/csw/bin/sudo binary) to the new scheme (CSWsudo containing > /opt/csw/bin/sudo.minimal and CSWsudo-common containing the symlink), > assuming the upgrade order (CSWsudo-common gets upgraded first), must > inevitably lead to the problem I described. I find it hard to believe > that nobody ran into this problem before and that there were no bug > reports. Maintainers, are you sure that the issue hasn't surfaced > after the introduction of the symlink? Just cross-checked with two of our systems which were upgraded recently. Both have up to date sudo packages now, but no /opt/csw/bin/sudo any more. So yes, the problem has surfaced, but as we don't use sudo in that environment it hasn't been noticed so far. As a side note: I guess with pkgutil 1.9 which removes all to-be-upgraded packages before installing the newer versions, one wouldn't see this issue. Right? Sebastian From phil at bolthole.com Tue Dec 15 22:12:35 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 15 Dec 2009 13:12:35 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: On Tue, Dec 15, 2009 at 12:57 PM, Maciej (Matchek) Blizinski wrote: > On Tue, Dec 15, 2009 at 4:45 PM, Philip Brown wrote: >> there is at least ONE "known bug", that you havent fixed: perms on sudo_ldap. >> please fix that. > > I'll pass for now. ?I'm offering only the version bump. It's a trivial change. one line in the prototype file. I wont accept the packages until you fix it. From bwalton at opencsw.org Tue Dec 15 22:27:27 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 15 Dec 2009 16:27:27 -0500 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: <1260912178-sup-4991@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Dec 15 16:12:35 -0500 2009: > It's a trivial change. one line in the prototype file. I wont accept > the packages until you fix it. As it stands now, these are two separate packages. They're built from the same source, but from different build descriptions. They're tracked separately in our version control. This means that the package Maciej is _volunteering_ his time to correct is completely independent of the sudo_ldap package[1]. Why not accept the work that Maciej is willing to do and work towards getting the sudo_ldap package updated as well[2] if it's that important. It seems to me that nobody is really rushing to work on sudo_ldap, so maybe nobody is actually using it? Thanks -Ben [1] This doesn't have to be the way it is, but that's how our history has evolved it. [2] The two should likely be merged in GAR and built with modulations. We could then do away with the sudo_ldap package completely, while still providing a mechanism to toggle between the 'backends' to sudo. -- 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 Tue Dec 15 23:48:48 2009 From: glaw at opencsw.org (Gary Law) Date: Tue, 15 Dec 2009 22:48:48 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: <1260912178-sup-4991@ntdws12.chass.utoronto.ca> References: <1260912178-sup-4991@ntdws12.chass.utoronto.ca> Message-ID: 2009/12/15 Ben Walton : > > Why not accept the work that Maciej is willing to do and work towards > getting the sudo_ldap package updated as well[2] if it's that important. +1 -- glaw at opencsw.org From glaw at opencsw.org Tue Dec 15 23:57:27 2009 From: glaw at opencsw.org (Gary Law) Date: Tue, 15 Dec 2009 22:57:27 +0000 Subject: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr) Message-ID: Hi 2009/12/11 Philip Brown : > On Thu, Dec 10, 2009 at 11:45 PM, Gary Law wrote: >> 2009/12/10 Philip Brown : >>> A quick off-the-cuff solution: >>> >>> We declare that classutils implementations must be backwards >>> compatible. If you want to do something incompatible,you must do it in >>> a newly named class. >>> >>> Problem solved? >> >> Might be if there were no-one out there shipping identically named >> utils installing in the same place, who might just go ahead and >> upgrade thiers in an incompatible way. But there is. >> > > no one else (who matters...) is going to be shipping any pkg class > utils named "cswxxxx". > our namespace is safe. I'm sorry, there is someone else who really does matter shipping identically named software, Blastwave. They have a larger installed base, more hits on google (*much* more in fact, and more recent new pages that refer to them too), active forums and IRC channel that suggest plenty of users. What we have is, IMHO, better software. However, we give the software the same pkg name as them, and install in the same place, which given our generally commitment to quality, is madness. I've said it before and I'm going to say it again: we need to shift name space and distinguish this project from Blastwave. We completely lack credibility otherwise, and have to worry -- as we are now -- about collisions. In this particular case, of course, this is a real problem. I've got to go to my provider of zones and say ' install this package ' and hope none of their other customers ever want to use Blastwave. If I was a commercial provider of zones, and had an understanding of these issues, I'd refuse to install our package (and the Blastwave one of the same name) just to avoid future support headaches. -- glaw at opencsw.org From skayser at opencsw.org Wed Dec 16 00:00:29 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 16 Dec 2009 00:00:29 +0100 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: Message-ID: <4B28150D.4040506@opencsw.org> Philip Brown wrote on 15.12.2009 22:12: > On Tue, Dec 15, 2009 at 12:57 PM, Maciej (Matchek) Blizinski > wrote: >> On Tue, Dec 15, 2009 at 4:45 PM, Philip Brown wrote: >>> there is at least ONE "known bug", that you havent fixed: perms on sudo_ldap. >>> please fix that. >> I'll pass for now. I'm offering only the version bump. > > It's a trivial change. one line in the prototype file. I wont accept > the packages until you fix it. Disclaimer: no offense intended. It's not about "the one prototype line". You once pointed out the importance of volunteers. At the same time we are having discussions over and over again, many times about subtleties, many times leading nowhere, where i can't help but to feel a sort of "clever" argumentation (for the sake of the argument) and a "my way or highway" attitude on your side. Often this ends up with disgruntled parties, just like here. Might well be that this is all in a quest for perfection, but we are all volunteers (including you) and I really think it would help the project, if someone at a central position like yours would take a step back sometimes and try to better understand/foster what people are trying to contribute, instead of hitting them with the "nah, we/you should do it better, completely different or simply the way I think" autocracy hammer. In particular, when they are the ones doing the work. There are always multiple sides of a story. This is how I perceive things within my INBOX and it simply doesn't feel right to see people who are passionately contributing to OpenCSW (Maciej in this case, others in other cases, maybe even you sometimes, or anyone else for that matter) to go home being frustrated over OpenCSW internals. Sebastian From rupert at opencsw.org Wed Dec 16 08:45:36 2009 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 16 Dec 2009 08:45:36 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: <1260896801-sup-2625@ntdws12.chass.utoronto.ca> References: <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> <1260896801-sup-2625@ntdws12.chass.utoronto.ca> Message-ID: <6af4270912152345o14005c2ds642cfcebad108997@mail.gmail.com> On Tue, Dec 15, 2009 at 18:24, Ben Walton wrote: > Excerpts from rupert THURNER's message of Tue Dec 15 11:51:50 -0500 2009: > > Hi Rupert, > > > from work? no, nothing but http/s. but i will ask them if i get an > exception > > for ssh to opencsw. > > If you don't mind me asking, where do you work? Your firewall seems > extremely restrictive. > > credit suisse. the firewall policies allow certain things, and forbid others, besides the technical restrictions in place. either there is a technically clean possibility in line with the rules (like Sun SGD), or i have to go through the paper process for getting a permission for "ssh login.opencsw". but i do not want to break their rules even if technically possible (e.g. pierce the firewall by tunneling ssh through 443). if i do not like the rules any more it is time to look for another job i guess :) rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Wed Dec 16 09:24:17 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 16 Dec 2009 08:24:17 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: <4B27F9A4.8060100@opencsw.org> References: <4B27F9A4.8060100@opencsw.org> Message-ID: On Tue, Dec 15, 2009 at 9:03 PM, Sebastian Kayser wrote: > Hi Maciej, > > Maciej (Matchek) Blizinski wrote on 15.12.2009 10:03: >> I haven't tested these packages, since I'm using my own sudo packages >> at the moment. > > would it make sense to add what you are currently maintaing for yourself > to our sudo packages (and then adopt the CSW sudo packages) or are your > changes too custom/environment-specific? It would make sense to add it to our sudo packages. The difference between the two is that my packages move the /opt/csw/bin/sudo -> sudo.minimal symlink from CSWsudo-common to CSWsudo. This fixes the sudo upgrade problem which has just hit you. Phil did not accept this change because "somebody might have also installed CSWsudoldap and manually change the symlink to /opt/csw/bin/sudo -> sudo.ldap and this upgrade would revert their local change". I'm using the version of sudo from trunk, the one in testing/ is from branches/old-symlink-scheme. The main diff between the two is that the one in trunk has the following line: PKGFILES_CSWsudo += $(bindir)/sudo Maciej [1] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/sudo/trunk/Makefile [2] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/sudo/branches/old-symlink-scheme/Makefile From maciej at opencsw.org Wed Dec 16 09:27:49 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 16 Dec 2009 08:27:49 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: <4B27FAA3.9030903@opencsw.org> References: <4B27FAA3.9030903@opencsw.org> Message-ID: On Tue, Dec 15, 2009 at 9:07 PM, Sebastian Kayser wrote: > Maciej (Matchek) Blizinski wrote on 10.12.2009 19:40: >> On Thu, Dec 10, 2009 at 5:11 PM, Philip Brown wrote: >>> On Wed, Dec 9, 2009 at 11:24 PM, Maciej (Matchek) Blizinski >>> wrote: >>>> Filed bug 4074 about this issue. >>>> >>> Thanks. >>> >>>> My brain says the right thing to do is: >>>> >>>> 1. Get the alternatives mechanism in place >>>> 2. Modify CSWsudo to use it >>>> 3. Modify CSWsudo_ldap to use it, give it higher priority (if both are >>>> installed at the same time, use sudo.ldap) >>>> 4. Remove the stupid symlink from CSWsudo_common >>>> 5. Release all three packages at the same time >>>> >>>> Does it look good? >>> yes... except if it takes more than a week to implement, in which >>> case, I'd say just release new sudo with the symlink in postinstall. >>> sudo needs upgrading sooner rather than later, for security reasons, I thought. >> >> There is no security hole, it's even the opposite: ?the sudo command >> vanishes, and the system becomes more secure, because users can't get >> root. ?Unless they figure out sudo.minimal. >> >> There is one thing I'm curious about. ?If I understand it correctly, >> the transition from the older scheme (CSWsudo containing >> /opt/csw/bin/sudo binary) to the new scheme (CSWsudo containing >> /opt/csw/bin/sudo.minimal and CSWsudo-common containing the symlink), >> assuming the upgrade order (CSWsudo-common gets upgraded first), must >> inevitably lead to the problem I described. ?I find it hard to believe >> that nobody ran into this problem before and that there were no bug >> reports. ?Maintainers, are you sure that the issue hasn't surfaced >> after the introduction of the symlink? > > Just cross-checked with two of our systems which were upgraded recently. > Both have up to date sudo packages now, but no /opt/csw/bin/sudo any > more. So yes, the problem has surfaced, but as we don't use sudo in that > environment it hasn't been noticed so far. I was wondering why were there no bug reports or complaints. In which order does pkg-get upgrade the packages? pkgutil was doing it from bottom-up (i.e. dependencies first). If pkg-get does it the other way (i.e. dependencies last), the upgrade wouldn't cause the issue. > As a side note: I guess with pkgutil 1.9 which removes all > to-be-upgraded packages before installing the newer versions, one > wouldn't see this issue. Right? Correct. From james at opencsw.org Wed Dec 16 11:27:14 2009 From: james at opencsw.org (James Lee) Date: Wed, 16 Dec 2009 10:27:14 GMT Subject: [csw-maintainers] Font packages In-Reply-To: References: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> <20091215.10280500.1365323061@gyor.oxdrove.co.uk> Message-ID: <20091216.10271400.3514256454@gyor.oxdrove.co.uk> On 15/12/09, 17:14:11, Philip Brown wrote regarding Re: [csw-maintainers] Font packages: > > Ideally fonts should be in a common /opt/csw/share/fonts/ directory > > and the default font paths set in the apps. ?The problem is programs > > that index the installed fonts so adding fonts to the directory needs > > a way of notifying the apps, eg, Gostscript's Fontmap.GS. > please propose something? I thought this is what package hooks was for? If not, what I think they are will do it. James. From dam at opencsw.org Wed Dec 16 11:49:27 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 16 Dec 2009 11:49:27 +0100 Subject: [csw-maintainers] Access to the buildfarm via http with Sun Secure Global Desktop In-Reply-To: <6af4270912152345o14005c2ds642cfcebad108997@mail.gmail.com> References: <6af4270912121543k38ec76fcj1f5e37c06947806e@mail.gmail.com> <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> <1260896801-sup-2625@ntdws12.chass.utoronto.ca> <6af4270912152345o14005c2ds642cfcebad108997@mail.gmail.com> Message-ID: <029C3E5C-61F4-4BF6-A786-B30CCDECE9C3@opencsw.org> Hi Rupert, Am 16.12.2009 um 08:45 schrieb rupert THURNER: > On Tue, Dec 15, 2009 at 18:24, Ben Walton wrote: > Excerpts from rupert THURNER's message of Tue Dec 15 11:51:50 -0500 > 2009: > > from work? no, nothing but http/s. but i will ask them if i get an > exception > > for ssh to opencsw. > > the firewall policies allow certain things, and forbid others, > besides the technical restrictions in place. either there is a > technically clean possibility in line with the rules (like Sun SGD), > or i have to go through the paper process for getting a permission > for "ssh login.opencsw". > > but i do not want to break their rules even if technically possible > (e.g. pierce the firewall by tunneling ssh through 443). if i do not > like the rules any more it is time to look for another job i guess :) Fortunately setting up SGD is quite easy. If you want you can try logging in with accessing https://login.opencsw.org (http is redirected). As it is not an official certificate you must accept the root cert and add it to your keystore once. As there needs to be a password set I only opened this for Rupert for now, if anyone else is interested please mail to buildfarm at . Best regards -- Dago From rupert at opencsw.org Wed Dec 16 12:05:56 2009 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 16 Dec 2009 12:05:56 +0100 Subject: [csw-maintainers] Access to the buildfarm via http with Sun Secure Global Desktop In-Reply-To: <029C3E5C-61F4-4BF6-A786-B30CCDECE9C3@opencsw.org> References: <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> <1260896801-sup-2625@ntdws12.chass.utoronto.ca> <6af4270912152345o14005c2ds642cfcebad108997@mail.gmail.com> <029C3E5C-61F4-4BF6-A786-B30CCDECE9C3@opencsw.org> Message-ID: <6af4270912160305n56c0a9f1x460bd23c7b6b07de@mail.gmail.com> On Wed, Dec 16, 2009 at 11:49, Dagobert Michelsen wrote: > Hi Rupert, > > Am 16.12.2009 um 08:45 schrieb rupert THURNER: > >> On Tue, Dec 15, 2009 at 18:24, Ben Walton wrote: >> Excerpts from rupert THURNER's message of Tue Dec 15 11:51:50 -0500 2009: >> > from work? no, nothing but http/s. but i will ask them if i get an >> exception >> > for ssh to opencsw. >> >> the firewall policies allow certain things, and forbid others, besides the >> technical restrictions in place. either there is a technically clean >> possibility in line with the rules (like Sun SGD), or i have to go through >> the paper process for getting a permission for "ssh login.opencsw". >> >> but i do not want to break their rules even if technically possible (e.g. >> pierce the firewall by tunneling ssh through 443). if i do not like the >> rules any more it is time to look for another job i guess :) >> > > Fortunately setting up SGD is quite easy. If you want you can try > logging in with accessing > https://login.opencsw.org > (http is redirected). As it is not an official certificate you must > accept the root cert and add it to your keystore once. > > uuh .. that reminds me that we have another restriction in place: there is a list of trusted ca's. we use a software called "webwasher" which breaks up https connections at the firewall - and blocks everything which is not on this list. but, we convinced the security people to accept http://cacert.org/ certs to have a free alternative as well - besides the usual suspects thawte, etc. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Wed Dec 16 12:17:55 2009 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 16 Dec 2009 12:17:55 +0100 Subject: [csw-maintainers] Access to the buildfarm via http with Sun Secure Global Desktop In-Reply-To: <6af4270912160305n56c0a9f1x460bd23c7b6b07de@mail.gmail.com> References: <6FD0FF07-63E8-4E89-A73A-18A3A1C62F27@opencsw.org> <6af4270912141001w7e52df3di5b13f537fda22071@mail.gmail.com> <6af4270912150851n2d022d1bma9f79c4952eb801e@mail.gmail.com> <1260896801-sup-2625@ntdws12.chass.utoronto.ca> <6af4270912152345o14005c2ds642cfcebad108997@mail.gmail.com> <029C3E5C-61F4-4BF6-A786-B30CCDECE9C3@opencsw.org> <6af4270912160305n56c0a9f1x460bd23c7b6b07de@mail.gmail.com> Message-ID: <6af4270912160317i2c0d7e37m3938468ed768e199@mail.gmail.com> On Wed, Dec 16, 2009 at 12:05, rupert THURNER wrote: > On Wed, Dec 16, 2009 at 11:49, Dagobert Michelsen wrote: > >> Hi Rupert, >> >> Am 16.12.2009 um 08:45 schrieb rupert THURNER: >> >>> On Tue, Dec 15, 2009 at 18:24, Ben Walton wrote: >>> Excerpts from rupert THURNER's message of Tue Dec 15 11:51:50 -0500 2009: >>> > from work? no, nothing but http/s. but i will ask them if i get an >>> exception >>> > for ssh to opencsw. >>> >>> the firewall policies allow certain things, and forbid others, besides >>> the technical restrictions in place. either there is a technically clean >>> possibility in line with the rules (like Sun SGD), or i have to go through >>> the paper process for getting a permission for "ssh login.opencsw". >>> >>> but i do not want to break their rules even if technically possible (e.g. >>> pierce the firewall by tunneling ssh through 443). if i do not like the >>> rules any more it is time to look for another job i guess :) >>> >> >> Fortunately setting up SGD is quite easy. If you want you can try >> logging in with accessing >> https://login.opencsw.org >> (http is redirected). As it is not an official certificate you must >> accept the root cert and add it to your keystore once. >> >> > uuh .. that reminds me that we have another restriction in place: there is > a list of trusted ca's. we use a software called "webwasher" which breaks up > https connections at the firewall - and blocks everything which is not on > this list. > > but, we convinced the security people to accept http://cacert.org/ certs > to have a free alternative as well - besides the usual suspects thawte, etc. > > > i tested it from home and it seems to work great. the following i was wondering: * where to change the password * where to change the terminal type rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Wed Dec 16 13:44:46 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 16 Dec 2009 07:44:46 -0500 Subject: [csw-maintainers] Font packages In-Reply-To: <20091216.10271400.3514256454@gyor.oxdrove.co.uk> References: <8642B5FA-EA51-4702-A07B-32641C37B1D4@opencsw.org> <20091215.10280500.1365323061@gyor.oxdrove.co.uk> <20091216.10271400.3514256454@gyor.oxdrove.co.uk> Message-ID: <1260967259-sup-9606@ntdws12.chass.utoronto.ca> Excerpts from James Lee's message of Wed Dec 16 05:27:14 -0500 2009: > > > a way of notifying the apps, eg, Gostscript's Fontmap.GS. > > > please propose something? > > I thought this is what package hooks was for? If not, what I think > they are will do it. Hooks could do this, but aren't ideally suited to the task. You'd need to do something like: prebatch(remove|install|upgrade): Record list of fonts present postbatch(remove|install|upgrade): Compare current list with previouslist; trigger font index updates if difference. The problems are: 1. The script(s) need to be aware of all different indexes that need updating. 2. It's not plain pkgadd/pkgrm aware. Ultimately, class action scripts would be better for this, but since this whole /usr issue seems so thorny, I'm not sure it will gain tractaion. If only Sun hadn't made this such a fundamental flaw. -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 Dec 16 20:06:55 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Dec 2009 11:06:55 -0800 Subject: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr) In-Reply-To: References: Message-ID: On Tue, Dec 15, 2009 at 2:57 PM, Gary Law wrote: >... Blastwave. They have a larger installed > base, more hits on google (*much* more in fact, and more recent new > pages that refer to them too), active forums and IRC channel that > suggest plenty of users. So lets fix that. It has already been proposed that we need to make an effort to "advertise" ourselves better. I think that those people who are interested in doing something about this, should form an off-list "working group", to improve the situation. I am interested in this, also I think William... who else is willing to actually DO something about it? > What we have is, IMHO, better software. yes we do. > We completely lack credibility otherwise, I'm not sure how this translates into lack of "credibility". To my mind, its just the opposite. Keeping the same prefix, that many of us had, while we worked on "CSW at blastwave", emphasises that it belongs to us, the true continuation of "The CSW packaging project" Changing it, reduces our credibility, by denying the above. I will remind you that "CSW packaging" is *NOT* a creation of Dennis Clarke. He merely hosted it. He never "owned" it, even though he liked to give the appearance that he did. > In this particular case, of course, this is a real problem. I've got > to go to my provider of zones and say ' install this package ' and > hope none of their other customers ever want to use Blastwave. If I > was a commercial provider of zones, and had an understanding of these > issues, I'd refuse to install our package (and the Blastwave one of > the same name) just to avoid future support headaches. I think that the conflict works in our favor; users have to choose between "install blastwave", or "install opencsw", and thus do an evaluation of "which is better?" Almost any sane organization that does the evaluation, will concur that they are better off installing *our* packages. For cases where those organizations have an issue of, "we really like your packages, but there's this specific issue where blastwave has ...." hopefully, they can be encouraged to actually mention this to us, and then we can FIX it. I will take a moment to point out that we are way ahead of blastwave in up to date packages at this point. Since this is a public list, and the "advertising/promote group" has not been formed yet (and I i think would deserve first say on how this is disclosed), I wont mention exactly how far ahead we are. But take my word for it when I say *very* far ahead. From phil at bolthole.com Wed Dec 16 20:20:04 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Dec 2009 11:20:04 -0800 Subject: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr) In-Reply-To: References: Message-ID: On Tue, Dec 15, 2009 at 2:57 PM, Gary Law wrote: > ... > In this particular case, of course, this is a real problem. I've got > to go to my provider of zones and say ' install this package ' and > hope none of their other customers ever want to use Blastwave. oh, a small point on zone compatibility, btw: sparse zones usually share /usr from the global zone. However, no-one says they HAVE to. They can actually share /usr from somewhere else(whether that be a non-global zone, or somewhere else entirely) Similar for /opt, and /opt/csw, if you want those shared rather than zone-local. Additionally.. just because /usr is read-only, doesnt mean that you cannot modify it for a zone, funnily enough :-} If for some reason, you really REALLY want multiple zones on a single box, all with single shared /usr from global zone.. but you wish some zones to use blastwave, and others to use opencsw.. and thus you maybe have a conflict in /usr/sadm/install/scripts... You can have an overlay mount for /usr/sadm/install/scripts. Its not quite as pretty or simple, as just having "everything use opencsw". But it is as least, not an insurmountable problem. From phil at bolthole.com Wed Dec 16 20:36:59 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 16 Dec 2009 11:36:59 -0800 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <4B27FAA3.9030903@opencsw.org> Message-ID: On Wed, Dec 16, 2009 at 12:27 AM, Maciej (Matchek) Blizinski wrote: > > I was wondering why were there no bug reports or complaints. In which > order does pkg-get upgrade the packages? ?pkgutil was doing it from > bottom-up (i.e. dependencies first). ?If pkg-get does it the other way > (i.e. dependencies last), the upgrade wouldn't cause the issue. > pkg-get does dependancies first. It actually insists that (direct)dependancies be up to date, before it will update a package. side note: perhaps there are few complaints, because there are few people who trust a third party sudo package, but usually create their own ;-) From james at opencsw.org Thu Dec 17 11:25:06 2009 From: james at opencsw.org (James Lee) Date: Thu, 17 Dec 2009 10:25:06 GMT Subject: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr) In-Reply-To: References: Message-ID: <20091217.10250600.3134011945@gyor.oxdrove.co.uk> On 16/12/09, 19:20:04, Philip Brown wrote regarding Re: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr): > sparse zones usually share /usr from the global zone. However, no-one > says they HAVE to. > They can actually share /usr from somewhere else(whether that be a > non-global zone, or somewhere else entirely) > Similar for /opt, and /opt/csw, if you want those shared rather than > zone-local. No one says I have to share /usr, or use zones, or use CSW, or use Solaris - but I choose to. Zones are good *because* they allow me to share resources, suggesting I don't as a workaround is stupid. Example: $ zoneadm list -c | wc -l 14 $ du -sh /usr 5.7G /usr 13 * 5.7G > 100% full, the only reason this system exists is because I share /usr/. I could buy 2 more hard drives but then I couldn't spend the money on something else, and eventually the point comes when I can't buy more kit, or anything else. (If ZFS clones worked with live update it would be different.) James. From maciej at opencsw.org Thu Dec 17 21:08:50 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 17 Dec 2009 20:08:50 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <4B0D1316.5000704@opencsw.org> References: <4AF342DE.2020604@opencsw.org> <4AF5B104.90307@opencsw.org> <4AF74A6F.6010004@opencsw.org> <4B0D1316.5000704@opencsw.org> Message-ID: mysql 5.0.87 has been sitting in testing for quite a while now. I was thinking to spend more time on it, but I've been sidetracked by other things. Since I'm not going to work on mysql-5.1 tests in the nearest weeks, what do you think of releasing the packages from testing? It's a question partly to the general maintainers audience, and partly to Phil as the release manager. Maciej From phil at bolthole.com Thu Dec 17 23:55:08 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 17 Dec 2009 14:55:08 -0800 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> <4AF5B104.90307@opencsw.org> <4AF74A6F.6010004@opencsw.org> <4B0D1316.5000704@opencsw.org> Message-ID: On Thu, Dec 17, 2009 at 12:08 PM, Maciej (Matchek) Blizinski wrote: > mysql 5.0.87 .[...]. > ?It's > a question partly to the general maintainers audience, and partly to > Phil as the release manager. > my comments are: while 5.1 would of course be better, it's at least an improvement over what we currently have, 5.0.51. = ancient. If at least one other person can say they tried it out, in however limited a form, I'd say lets release it. From glaw at opencsw.org Fri Dec 18 09:50:14 2009 From: glaw at opencsw.org (Gary Law) Date: Fri, 18 Dec 2009 08:50:14 +0000 Subject: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr) In-Reply-To: References: Message-ID: Hi 2009/12/16 Philip Brown : > On Tue, Dec 15, 2009 at 2:57 PM, Gary Law wrote: >>... Blastwave. They have a larger installed >> base, more hits on google (*much* more in fact, and more recent new >> pages that refer to them too), active forums and IRC channel that >> suggest plenty of users. > > > So lets fix that. Fixing that is not a bad idea. However, until it is fixed, we should recognise that we're not the dominant software distributor in the /opt/csw space. It is therefore unwise to make statements along the lines of no-one who matters will ship software with conflicting names. > It has already been proposed that we need to make an effort to > "advertise" ourselves better. I think that those people who are > interested in doing something about this, should form an off-list > "working group", to improve the situation. > > I am interested in this, also I think William... who else is willing > to actually DO something about it? I've chatted to William about this on IRC, and I love what he's done with the beta website. Let's get it launched and get google trawling it. >> What we have is, IMHO, better software. > > yes we do. > >> We completely lack credibility otherwise, > > I'm not sure how this translates into lack of "credibility". > > To my mind, its just the opposite. Keeping the same prefix, that many > of us had, while we worked on "CSW at blastwave", emphasises that it > belongs to us, the true continuation of "The CSW packaging project" > > Changing it, reduces our credibility, by denying the above. > > I will remind you that "CSW packaging" is *NOT* a creation of Dennis > Clarke. He merely hosted it. He never "owned" it, even though he liked > to give the appearance that he did. No-one owns a name space in this context. But whatever the rights and wrongs of who owns the name the mature and sensible approach at this stage is to walk away from the /opt/csw space (and CSW packaging prefix) because someone else is using it. Never mind that it wasn't his idea, the conflict is damaging. >> In this particular case, of course, this is a real problem. I've got >> to go to my provider of zones and say ' install this package ' and >> hope none of their other customers ever want to use Blastwave. If I >> was a commercial provider of zones, and had an understanding of these >> issues, I'd refuse to install our package (and the Blastwave one of >> the same name) just to avoid future support headaches. > > I think that the conflict works in our favor; users have to choose > between "install blastwave", or "install opencsw", and thus do an > evaluation of "which is better?" Or say, 'sod it, neither of them untill they sort their act out'. Which is what I would do if I were such a commercial provider -- there's no way I'd 'take sides' like that. > Almost any sane organization that does the evaluation, will concur > that they are better off installing *our* packages. > > For cases where those organizations have an issue of, "we really like > your packages, but there's this specific issue where blastwave has > ...." hopefully, they can be encouraged to actually mention this to > us, and then we can FIX it. > > I will take a moment to point out that we are way ahead of blastwave > in up to date packages at this point. > Since this is a public list, and the "advertising/promote group" has > not been formed yet (and I i think would deserve first say on how this > is disclosed), I wont mention exactly how far ahead we are. > But take my word for it when I say *very* far ahead. This should not be a matter of Blastwave vs. OpenCSW any more than OpenCSW is 'vs' Sunfreeware. All should be able to exist independently, no admin should be forced to choose. We're getting close to the point where most of our software is in GAR (which is where this thread started, I'm having trouble with /usr!) which means we can rebuild and retarget on mass. Gary -- glaw at opencsw.org From rupert at opencsw.org Fri Dec 18 17:53:19 2009 From: rupert at opencsw.org (rupert THURNER) Date: Fri, 18 Dec 2009 17:53:19 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4ADB697E.5060403@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> <4ADB4837.9010404@opencsw.org> <1255887034-sup-5726@ntdws12.chass.utoronto.ca> <4ADB697E.5060403@opencsw.org> Message-ID: <6af4270912180853r22f087aet4756e5d47dd2c4a6@mail.gmail.com> maciej and i tried to convert apache2 to dynamic prototype, and removed the gspec files. to have a testable version i switched back to a single-package apache2, which i also moved into /home/testing to give it a try. some links: * ihsan's version: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/apache2/tags/apache-2.2.13-by-idogan * last commit: http://sourceforge.net/apps/trac/gar/changeset/7671 * http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/apache2/trunk/files?rev=7671 post/pre scripts need to be verified * http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/apache2/trunk/Makefile?rev=7667 version of the makefile which still has all the packages, but i did not get it to work it would be great if somebody more experienced could have a look what was wrong with the multiple packages Makefile. it did not produce distinct prototype files. some of the packages then had an empty prototype file, others had a prototype file containing everything. rupert. On Sun, Oct 18, 2009 at 20:16, Ihsan Dogan wrote: > Am 18.10.2009 19:31 Uhr, Ben Walton schrieb: > > > Excerpts from Ihsan Dogan's message of Sun Oct 18 12:54:15 -0400 2009: > > > >> The packaging has to be changed to dynamic prototype, gspec files has to > >> be removed and maybe the packaging of the rt and c package has to be > >> verified. > > > > ...and sysconfdir -> /etc/opt/csw/apache2, localstatedir -> > > /var/opt/csw/apache2? [Just a personal wishlist item.] > > Of course, I've forgot that one. This would require coordination with > other package maintainers. > > > > Ihsan > > -- > ihsan at dogan.ch http://blog.dogan.ch/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Dec 18 18:25:05 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 18 Dec 2009 18:25:05 +0100 Subject: [csw-maintainers] no one else who matters? (was CSWcswclassutils: it wants to write in /usr) In-Reply-To: References: Message-ID: <7562555E-319E-4091-9F1C-82C24C43B25B@opencsw.org> Hi Gary, Am 18.12.2009 um 09:50 schrieb Gary Law: >> It has already been proposed that we need to make an effort to >> "advertise" ourselves better. I think that those people who are >> interested in doing something about this, should form an off-list >> "working group", to improve the situation. >> >> I am interested in this, also I think William... who else is willing >> to actually DO something about it? > > I've chatted to William about this on IRC, and I love what he's done > with the beta website. Let's get it launched and get google trawling > it. If you have spare cycles you can speed it up by working on any item on the todo list at http://wiki.opencsw.org/new-website Best regards -- Dago From phil at bolthole.com Fri Dec 18 18:34:15 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 09:34:15 -0800 Subject: [csw-maintainers] advertising Message-ID: On Fri, Dec 18, 2009 at 12:50 AM, Gary Law wrote: > Hi > > 2009/12/16 Philip Brown : > >> It has already been proposed that we need to make an effort to >> "advertise" ourselves better. I think that those people who are >> interested in doing something about this, should form an off-list >> "working group", to improve the situation. >> >> I am interested in this, also I think William... who else is willing >> to actually DO something about it? > > I've chatted to William about this on IRC, and I love what he's done > with the beta website. Let's get it launched and get google trawling > it. Thats nice an all,... but it doesnt really address the topic of my paragraph there. The core issue being, How do we get more people aware of us/using our packages? While getting the beta website productional would be "more pretty"... I dont think that it will have any impact towards "getting more people aware of us/using our packages". From phil at bolthole.com Fri Dec 18 18:43:05 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 09:43:05 -0800 Subject: [csw-maintainers] advertising Message-ID: PS: On Fri, Dec 18, 2009 at 12:50 AM, Gary Law wrote: > > This should not be a matter of Blastwave vs. OpenCSW any more than > OpenCSW is 'vs' Sunfreeware. ?? Of COURSE we are "vs" sunfreeware, et. al. We should be(?) trying to make "the best packages for solaris out there". "best" means "better than all others". Therefore, we are already in competition with them. If we are not trying to generate a better product, then what's the point? > All should be able to exist > independently, no admin should be forced to choose. Admins are already "forced" to choose in various ways. They are "forced" to choose which mail program they use to process their email. They are "forced" to choose which web server, from which "vendor" they are going to use to run their website. Unless a company's business, is providing "choice" to other businesses, they will almost inevitably choose one solution for all their packaging needs, and go with it, until such time as another solution shows itself as better. We should have our mission to prove ourselves as "the better solution", in all cases. In any cases where we are not.. let's fix it! From skayser at opencsw.org Fri Dec 18 20:37:52 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 18 Dec 2009 20:37:52 +0100 Subject: [csw-maintainers] Incompatible packages? Musing about mtr and mtr-tiny Message-ID: <4B2BDA10.2020905@opencsw.org> Hi, what's the current stance on incompatible packages? We currently have "mtr" in it's GUI version in the catalog which pulls in the whole g* and X11 chain. I would like to update it and also release an additional, non-GUI package (with a reduced dependency chain) as "mtr-tiny" and set it to incompatible with "mtr". The binary name in both cases is the same "mtr". That's the way Debian does it. When one had installed "mtr-tiny" and then installs "mtr" apt-get/aptitude will uninstall "mtr-tiny" first (and vice versa). Simple solution, no dangling symlinks like it just happened with sudo and it's package variants. On servers one usually just installs "mtr-tiny" and doesn't need any X. Do pkg-get/pkgutil support the concept of incompatible packages at all, i.e. would they uninstall an incompatible package before installing the new one? I remember, there were some reservations against incompatible packages because of "pkg-get install all". To cut a long story short: can we do the same as the Debian folks do or do we have another way to achieve what I need to do? Sebastian From phil at bolthole.com Fri Dec 18 20:57:25 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 11:57:25 -0800 Subject: [csw-maintainers] Incompatible packages? Musing about mtr and mtr-tiny In-Reply-To: <4B2BDA10.2020905@opencsw.org> References: <4B2BDA10.2020905@opencsw.org> Message-ID: On Fri, Dec 18, 2009 at 11:37 AM, Sebastian Kayser wrote: > Hi, > > what's the current stance on incompatible packages? We currently have > "mtr" in it's GUI version in the catalog which pulls in the whole g* and > X11 chain. I would like to update it and also release an additional, > non-GUI package (with a reduced dependency chain) as "mtr-tiny" and set > it to incompatible with "mtr". The binary name in both cases is the same > "mtr". >... > Do pkg-get/pkgutil support the concept of incompatible packages at all, > i.e. would they uninstall an incompatible package before installing the > new one? they WOULD uninstall an incompatible package. however, you are only allowed to be "incompatible" with a package that is no longer in "current". Happily, you have other options. [What I had written up, I am now editing, because current mtr pkg is orphaned] So, you have volunteered to take over the mgr package. You thus have a few options that I see. (there may be more,but here are the "obvious" ones that come to mind): A) Take over mgr, publish it with the "tiny" compiled version, but hopefully also release a GUI version, which you can then rename "mtr_x11" or something B) [I would normaly suggest a combined package, but you explicitly want a reduced dependancy package, so this option is scratched] C) publish mtr_tiny and mtr_x11;have a postinstall or something create a symlink from "mtr" to whichever the user prefers. You can pick your own preference as "default", but then in future installs, leave the symlink if it already exists. (This would be an appropriate use of the recently proposed "alternatives" system, if we can agree on implementation and naming of it ;-) From maciej at opencsw.org Fri Dec 18 21:14:05 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 18 Dec 2009 20:14:05 +0000 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260208118-sup-6509@ntdws12.chass.utoronto.ca> <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Dec 11, 2009 at 5:00 PM, Philip Brown wrote: > I like the concept of the alternatives system. I'm suggesting we > implement debian normal behavior, and then *augment* it, to be better. > Such as, including a short-command invocation. If I sent CSWalternatives as is for release, what would you say? From skayser at opencsw.org Fri Dec 18 21:54:20 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 18 Dec 2009 21:54:20 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> Message-ID: <4B2BEBFC.4040601@opencsw.org> Peter Bonivart wrote on 10.12.2009 15:06: > On Thu, Dec 10, 2009 at 2:05 PM, Sebastian Kayser wrote: >> Peter, did you experiment with the approach that we came up with during >> summer camp? Put dummy CAS scripts in the package which hand over to the >> real CAS scripts in /opt/csw/somewhere. This way we wouldn't need to >> have our CAS scripts beneath /usr. > > No, I haven't had time to yet but if that approach works it's the only > sane way to go if we're not to take a giant step backwards. > >> Does the user get prompted with "do you really want the package to do >> things that you probably don't care about"? > > Yes. Couldn't we simply ship pkgutil/pkg-get with a admin(4) file that suppresses CAS warnings and then call pkgadd with it per default? Then we could have: - cswclassutils: Eventually move from /usr to /opt/csw/somewhere. While not all been packages have been converted, maintain the CAS twice for /usr and /opt/csw/somewhere. - GAR: For each requested CAS "cswfoo", include a stub CAS {i,r}.cswfoo in the package which only hands over to /opt/csw/somehwere/{i,r}.cswfoo. Current packages need to be rebuilt, so that we can get rid of /usr eventually. - pkg-get/pkgutil: On package installation call pkgadd with a admin file to suppress CAS prompts. Sebastian From phil at bolthole.com Fri Dec 18 22:11:07 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 13:11:07 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Dec 18, 2009 at 12:14 PM, Maciej (Matchek) Blizinski wrote: > On Fri, Dec 11, 2009 at 5:00 PM, Philip Brown wrote: >> I like the concept of the alternatives system. I'm suggesting we >> implement debian normal behavior, and then *augment* it, to be better. >> Such as, including a short-command invocation. > > If I sent CSWalternatives as is for release, what would you say? > I would say, "please add a symlink for a shorter name to type, and I'd be happy to drop it in" :-) Otherwise, if you wished to argue aobut it, then things get complicated. Given that this is a proposed addition to the standard CSW toolset, its very important to make at "all it can be", as it were :-) It's not my decision alone, but I'd want to have a decent open discussion/vote on it. either via the board, or the maintainer list. As a pre-argument I would mention: what strong argument do you have for specifically NOT putting it in? It in no way detracts from the functionality, and it definately enhances it. It also allows us to give it a bit more csw personality at the same time, which is an additional bonus. Not to mention it is a trivial amount of work to do. Just add a symlink. ************ Erm... now that I'm taking a deeper look at it though... are you sure this thing is going to work ok for us? Its got a whoole lot of stuff, rather explicitly labeled "Dpkg". Virtually the whole thing, seems to be a bunch of perl modules under /opt/csw/share/perl/csw/Dpkg That makes me worried. A whole bunch of extra code that "isnt needed" but still laying around, has a tendancy to bite you in the rear later when you least expect it. The concept doesnt sound too terribly difficult. If I had more time, I would simply write a clean 'workalike', as I did when I created pkg-get to stand in for apt-get. I would guess it shouldnt take a competant shellscript programmer more than a few hours. However, I have 3 children to take care of this weekend, so I dont HAVE "a few hours" myself to spare. PS: if you dont realize how seriously I take user-level compatibility in "workalikes", you probably havent compared output of "apt-get moo" vs "pkg-get moo" ;-) From phil at bolthole.com Fri Dec 18 22:22:19 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 13:22:19 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <4B2BEBFC.4040601@opencsw.org> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> Message-ID: On Fri, Dec 18, 2009 at 12:54 PM, Sebastian Kayser wrote: > > > Couldn't we simply ship pkgutil/pkg-get with a admin(4) file that > suppresses CAS warnings and then call pkgadd with it per default? I would guess you mean "suppress postinstall scripts" warnings. pkg-get already ships with an OPTIONAL admin file to do just that. However, sysadmins who care about security (or sysadmins who just want to know very closely, what random install scripts mess with) tend to not appreciate that sort of behaviour by default. > Then we could have: > > - cswclassutils: Eventually move from /usr to /opt/csw/somewhere. > ?While not all been packages have been converted, maintain the > ?CAS twice for /usr and /opt/csw/somewhere. I thought of this when I first proposed the class action script approach, years ago now. However... have you tested whether class action scripts WORK anywhere other than /usr/sadm/blah, if they are not in the same package? As far as I recall, they do not. They must be in either /usr/blah, or in each individual package that uses it. Thus, there are TWO major benefits to our existing classactions scripts: 1. user doesnt get prompted about routine boring stuff from a postinstall script 2. There is a COMMON utility across all our packages, deployed to a SINGLE place. This means that if we update a class action script, we update it ONE time,and all packages get the benefit. The alternative, would mean that, if we bundled class action scripts individually in every package that used them... then every time we find, "oh dear, there's a bug in [classactionscriptfoo]", we would need to repackage and release EVERY PACKAGE that used it!! Take a look at http://www.opencsw.org/packages/cswclassutils I would guestimate there are... 100? packages that use cswclassutils now. I will propose an alternative, that came to me today while pondering this problem. An alternative, would be for us to publish our own version of the SVR4 pkg utils. This version would respect class action scripts elsewhere, such as /opt/csw/[whereever]. We could then do the "dual publish" mechanism that you propose, and which I am actually in favour of. If it actually WORKED :-} Sadly, I myself do not have the time to do this. I imagine it would be a considerable effort for someone to do this. Allegedly, the source is out there somewhere... but you'd have to track it down and make it useable. From skayser at opencsw.org Fri Dec 18 23:08:40 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 18 Dec 2009 23:08:40 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> Message-ID: <4B2BFD68.6090301@opencsw.org> Philip Brown wrote on 18.12.2009 22:22: > On Fri, Dec 18, 2009 at 12:54 PM, Sebastian Kayser wrote: >> >> Couldn't we simply ship pkgutil/pkg-get with a admin(4) file that >> suppresses CAS warnings and then call pkgadd with it per default? > > I would guess you mean "suppress postinstall scripts" warnings. No, I specifically meant suppress CAS warnings. Please see below. >> Then we could have: >> >> - cswclassutils: Eventually move from /usr to /opt/csw/somewhere. >> While not all been packages have been converted, maintain the >> CAS twice for /usr and /opt/csw/somewhere. > > I thought of this when I first proposed the class action script > approach, years ago now. However... have you tested whether class action > scripts WORK anywhere other than /usr/sadm/blah, if they are not in > the same package? As far as I recall, they do not. They must be > in either /usr/blah, or in each individual package that uses it. Correct. My thought was to add _CAS stubs_ for required functionality to our packages. These would be added by GAR and do nothing more than something similar to exec /opt/csw/somewhere/{i,r}.cswfoo plus some logic for Jumpstart and zone environments where /opt/csw/somewhere is /$someprefix/opt/csw/somewhere. So our whole suite of CAS would be centrally maintained at /opt/csw/somewhere. Combined with the admin file to suppress CAS prompts (for the CAS stubs in the package) this would free us from /usr and not incur any additional prompts to the user. > Thus, there are TWO major benefits to our existing classactions scripts: > > 1. user doesnt get prompted about routine boring stuff from a postinstall script > > 2. There is a COMMON utility across all our packages, deployed to a > SINGLE place. > This means that if we update a class action script, we update it ONE > time,and all packages get the benefit. > The alternative, would mean that, if we bundled class action scripts > individually in every package that used them... then every time we > find, "oh dear, there's a bug in [classactionscriptfoo]", we would > need to repackage and release EVERY PACKAGE that used it!! With the suggested approach, the main intelligence is kept in /opt/csw/somewhere. The CAS bundled with the packages are simple stubs so that the likelihood of bugs in these stubs is minimized. Still, you are right, if there were a bug in one of these stubs each dependent pkg would need to be repackaged (not rebuilt). > I will propose an alternative, that came to me today while pondering > this problem. An alternative, would be for us to publish our own > version of the SVR4 pkg utils. This version would respect class action > scripts elsewhere, such as /opt/csw/[whereever]. [...] I imagine it > would be a considerable effort for someone to do this. Allegedly, > the source is out there somewhere... but you'd have to track it down > and make it useable. Sounds like a substantial effort to deliver/maintain and honestly, I as a sysadmin would not be willing to install 3rd party repackaged pkg* tools which directly deal with my package database. Currently, I am not sure whether either options is a viable one. Sebastian From skayser at opencsw.org Fri Dec 18 23:28:43 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 18 Dec 2009 23:28:43 +0100 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <1260210104-sup-2487@ntdws12.chass.utoronto.ca> Message-ID: <4B2C021B.50800@opencsw.org> Philip Brown wrote on 18.12.2009 22:11: > On Fri, Dec 18, 2009 at 12:14 PM, Maciej (Matchek) Blizinski > wrote: >> On Fri, Dec 11, 2009 at 5:00 PM, Philip Brown wrote: >>> I like the concept of the alternatives system. I'm suggesting we >>> implement debian normal behavior, and then *augment* it, to be better. >>> Such as, including a short-command invocation. >> If I sent CSWalternatives as is for release, what would you say? >> > > I would say, "please add a symlink for a shorter name to type, and I'd > be happy to drop it in" :-) > > Otherwise, if you wished to argue aobut it, then things get complicated. > Given that this is a proposed addition to the standard CSW toolset, > its very important to make at "all it can be", as it were :-) > It's not my decision alone, but I'd want to have a decent open > discussion/vote on it. either via the board, or the maintainer list. > > As a pre-argument I would mention: what strong argument do you have > for specifically NOT putting it in? It in no way detracts from the > functionality, and it definately enhances it. It also allows us to > give it a bit more csw personality at the same time, which is an > additional bonus. > > Not to mention it is a trivial amount of work to do. Just add a symlink. A slight concern of mine would be: besides the symlink, it is another invocation method that one has to keep in mind. update-alternatives on it's own is canonical and well-known from Debian, add cswua (or similar) to the mix and it will introduce ambiguity when people start talking about tools. In the end I would bet you a crate of beer that there are more OpenCSW users who would potentially be exposed to update-alternatives/cswua and ambiguity than there are OpenCSW users who are currently exposed to non-autocompletion-shells. ;) Sebastian From phil at bolthole.com Fri Dec 18 23:34:38 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 14:34:38 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <4B2BFD68.6090301@opencsw.org> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> Message-ID: On Fri, Dec 18, 2009 at 2:08 PM, Sebastian Kayser wrote: > Philip Brown wrote on 18.12.2009 22:22: >> >> >> I would guess you mean "suppress postinstall scripts" warnings. > > No, I specifically meant suppress CAS warnings. Please see below. Hm. things are getting long, so I think it would be beneficial to restate in full your proposal, and perhaps it will actually take up less space that way :) What I believe you are suggesting, is as follows: - We still use things such as f cswpreserveconf /etc/opt/csw/yourprog.cnf.CSW 0444 root bin however, the class action "cswpreserveconf", you are proposing be a very dumb stub, included in every package, which would somehow hand things off to /opt/csw/share/CSWUTILS/[...] Since these are no longer "bundled/installed" class actions, they would trigger class action warnings. Which you are then suggesting we suppress by forcing an admin file, "dont prompt user about questionable-security activities of packages". that about sum it up? I have two comments on this: 1. In some respects that seems only slightly different, from just doing everything in postinstall scripts, that call "standard" csw utils, rather than having everything inline. I'm not sure it is strictly better than the simplistic postinstall way. 2. It requires having an admin disable LEGITIMATE warnings, to be spared the prescreened trivial warnings. (ie: you propose disable ALL class action script warnings, not just warnings about the official csw pre-screened actions) So, while your proposal does address the "single point of update" issue, it still leaves the security issue open. I will point out,that one of the reasons sun chose /usr/sadm to be the official residence of approved class action utils, is exactly BECAUSE it is often mounted read-only, in security-sensitive installations!! it is expected, and encouraged, to only very rarely update things in there, and thus to have detailed inspections and approvals for it when they are. (which as a side note, should serve as a reminder to us, to only update cswclassutils infrequently, and to ensure 100% backward compatibility for it) >> I will propose an alternative, that came to me today while pondering >> this problem. An alternative, would be for us to publish our own >> version of the SVR4 pkg utils. This version would respect class action >> scripts elsewhere, such as /opt/csw/[whereever]. [...] I imagine it >> would be a considerable effort for someone to do this. Allegedly, >> the source is out there somewhere... but you'd have to track it down >> and make it useable. > > Sounds like a substantial effort to deliver/maintain and honestly, I as > a sysadmin would not be willing to install 3rd party repackaged pkg* > tools which directly deal with my package database. you are not open to that, but you ARE perfectly happy with turning off all security warnings when you add a package? This policy seems to be a little... lacking.. to me :-} From phil at bolthole.com Fri Dec 18 23:44:17 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 18 Dec 2009 14:44:17 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: <4B2C021B.50800@opencsw.org> References: <4B2C021B.50800@opencsw.org> Message-ID: On Fri, Dec 18, 2009 at 2:28 PM, Sebastian Kayser wrote: > Philip Brown wrote on 18.12.2009 22:11: >> >> >> As a pre-argument I would mention: what strong argument do you have >> for specifically NOT putting it in? ?It in no way detracts from the >> functionality, and it definately enhances it. It also allows us to >> give it a bit more csw personality at the same time, which is an >> additional bonus. >> >> Not to mention it is a trivial amount of work to do. Just add a symlink. > > A slight concern of mine would be: besides the symlink, it is another > invocation method that one has to keep in mind. update-alternatives on > it's own is canonical and well-known from Debian, add cswua (or similar) > to the mix and it will introduce ambiguity when people start talking > about tools. by that argument, you might say that me naming "pkg-get" as such, and not "apt-get", was just too confusing, because since the userland syntax is the same, and it IS a 90% clone of apt-get, I should have kept the name as apt-get. I posit this argument to be false :-) Taking some of what you said into account, however: I would further suggest, that our OFFICIAL name, for it, be the shorter name, and the longer name of "update-alternatives" be present only for people whose minds are not flexible enough to realize they arent running debian any more. (if people want to pretend they are EXACTLY the same as debian.. that's what nexenta is for, after all? ;-) There, we have resolved the "ambiguity problem" :-D Besides which, it is more than likely down the road, that at some point, we will want the finer points of our alternatives system to be a little different from the debian one. At which point, if we have trained users to refer to it as the debian name, it will be all the more confusing. > In the end I would bet you a crate of beer that there are more OpenCSW > users who would potentially be exposed to update-alternatives/cswua and > ambiguity than there are OpenCSW users who are currently exposed to > non-autocompletion-shells. ;) I would be more willing to take you up on that bet, if we had a decent short-name alternative to put to a vote ;) besides which: you have conflicts even with "autocompletion shells", all the way out to "update". try this: grep bin/update /var/sadm/install/contents |nawk '{print $1}' or worse, grep bin/up /var/sadm/install/contents |nawk '{print $1}' From bwalton at opencsw.org Sat Dec 19 01:27:35 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 18 Dec 2009 19:27:35 -0500 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <4B2C021B.50800@opencsw.org> Message-ID: <1261181863-sup-5150@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Dec 18 17:44:17 -0500 2009: > by that argument, you might say that me naming "pkg-get" as such, and > not "apt-get", was just too confusing, because since the userland > syntax is the same, and it IS a 90% clone of apt-get, I should have > kept the name as apt-get. The difference being pkg-get is an apt-get workalike. The package Maciej has put forward is the 'real deal[1].' While the name used in Debian is long and annoying to type, even with auto-completion, it's really not something you interact with often, if at all. So, my 'vote' is that if we don't do a ground up reimplementation, we stick with the name from Debian. If somebody wants to invest the time tailoring a solution to CSW, pick a new name. Is anyone else out there not making use of auto-completion shell features? Life feels too short for that! :) -Ben [1] It's the identical code/functionality split out from a larger Debian package. -- 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 Dec 19 17:41:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 19 Dec 2009 17:41:26 +0100 Subject: [csw-maintainers] Alternatives In-Reply-To: References: <4B2C021B.50800@opencsw.org> Message-ID: <00611D04-93AA-423F-B656-EE6A512A9190@opencsw.org> Hi Phil, Am 18.12.2009 um 23:44 schrieb Philip Brown: > On Fri, Dec 18, 2009 at 2:28 PM, Sebastian Kayser > wrote: >> Philip Brown wrote on 18.12.2009 22:11: >>> >>> >>> As a pre-argument I would mention: what strong argument do you have >>> for specifically NOT putting it in? It in no way detracts from the >>> functionality, and it definately enhances it. It also allows us to >>> give it a bit more csw personality at the same time, which is an >>> additional bonus. >>> >>> Not to mention it is a trivial amount of work to do. Just add a >>> symlink. >> >> A slight concern of mine would be: besides the symlink, it is another >> invocation method that one has to keep in mind. update-alternatives >> on >> it's own is canonical and well-known from Debian, add cswua (or >> similar) >> to the mix and it will introduce ambiguity when people start talking >> about tools. > > by that argument, you might say that me naming "pkg-get" as such, and > not "apt-get", was just too confusing, because since the userland > syntax is the same, and it IS a 90% clone of apt-get, I should have > kept the name as apt-get. No, because it is not apt-get, but a 90% clone. cswua is 100% update-alternatives. If you as a admin-user do this seldom you won't bother typing it and if you do it regularly then you'll add a shell alias. Or would you also argument to have a "ll" (or "cswll") binary for "ls -l" in GNU coreutils? Best regards -- Dago From rupert at opencsw.org Sat Dec 19 21:24:43 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 19 Dec 2009 21:24:43 +0100 Subject: [csw-maintainers] trac-0.11.6 now in testing Message-ID: <6af4270912191224o187cadadma02e5f7e51ac3590@mail.gmail.com> hi, trac-0.11.6 is now in testing. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Sun Dec 20 02:39:46 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 02:39:46 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? Message-ID: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> hi, while trying to upgrade apache2 i thought it uses the apr package and so i tried to upgrade this as well, and it gives an error while testing: ... testsockets : FAILED 1 of 7 ... Failed Tests Total Fail Failed % =================================================== testsockets 7 1 14.29% gmake[1]: *** [test-work/solaris8-sparc/build-isa-sparcv8/apr-1.3.9/Makefile] Error 2 gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' gmake: *** [merge-isa-sparcv8] Error 2 was this always like this or it is new? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Sun Dec 20 05:40:26 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 05:40:26 +0100 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ Message-ID: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> hi, dagobert filed a subversion bug saying the config file should go in a different place: The configuration for the svn commandline-client is at /etc/subversion/servers instead of /etc/opt/csw/subversion/servers isn't this a standard configuration option and gar should do this? an excerpt from the subversion configure is below: rupert at build8s: ... build-isa-sparcv8/subversion-1.6.6 $ ./configure --help `configure' configures subversion 1.6.6 to adapt to many kinds of systems. ... an installation prefix other than `/usr/local' using `--prefix', for instance `--prefix=$HOME'. For better control, use the options below. Fine tuning of the installation directories: .... --sysconfdir=DIR read-only single-machine data [PREFIX/etc] ... rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Dec 20 12:10:28 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 20 Dec 2009 11:10:28 +0000 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> Message-ID: On Sun, Dec 20, 2009 at 4:40 AM, rupert THURNER wrote: > hi, > > dagobert filed a subversion bug saying the config file should go in a > different place: > > The configuration for the svn commandline-client is at > ??/etc/subversion/servers > instead of > ??/etc/opt/csw/subversion/servers > > isn't this a standard configuration option and gar should do this? It depends on the kind of the operating system. On Solaris, the convention is that if you're not Sun, you have to install everything under a custom prefix. Nothing, if at all possible, goes into /usr or /etc without a prefix. We use /opt/csw for everything, except the directories that must be writable. Those go into /var/opt/csw and /etc/opt/csw. See here, these are files already in this directory put there by other packages: http://www.opencsw.org/search.php?filename=/etc/opt/csw&searchfiles=1&matchtype=partial At the same time, these need to be migrated: http://www.opencsw.org/search.php?filename=/opt/csw/etc&searchfiles=1&matchtype=partial Maciej From maciej at opencsw.org Sun Dec 20 12:26:18 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 20 Dec 2009 11:26:18 +0000 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> References: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> Message-ID: On Sat, Dec 12, 2009 at 2:53 AM, Ben Walton wrote: > Use the dynamic adm script capability in GAR. > > See docbook-style-xsl: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/docbook-style-xsl/trunk/Makefile > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/docbook-style-xsl/trunk/files/CSWdocbookxsl.postinstall > > Just be careful to $$ when you need to use a shell variable as the > script is subject to regular Makefile expansion rules. ?Also, the > final product will be much less readable than a normal script. > > Is this what you're after? Yes, this is it. I have some more questions: - At which stage (fetch, extract, install, merge, package) does the expansion take place? - What if the pkgname contains a dash? Will "define CSWfoo-bar_postinstall" work? From rupert at opencsw.org Sun Dec 20 12:52:24 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 12:52:24 +0100 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> Message-ID: <6af4270912200352pee36f58ge14b8a8ee183f907@mail.gmail.com> On Sun, Dec 20, 2009 at 12:10, Maciej (Matchek) Blizinski < maciej at opencsw.org> wrote: > On Sun, Dec 20, 2009 at 4:40 AM, rupert THURNER > wrote: > > hi, > > > > dagobert filed a subversion bug saying the config file should go in a > > different place: > > > > The configuration for the svn commandline-client is at > > /etc/subversion/servers > > instead of > > /etc/opt/csw/subversion/servers > > > > isn't this a standard configuration option and gar should do this? > > It depends on the kind of the operating system. On Solaris, the > convention is that if you're not Sun, you have to install everything > under a custom prefix. Nothing, if at all possible, goes into /usr or > /etc without a prefix. We use /opt/csw for everything, except the > directories that must be writable. Those go into /var/opt/csw and > /etc/opt/csw. > > the default says " [PREFIX/etc]" which in my understanding means /opt/csw/etc. and i was really wondering who changes this where to make it /etc ? is this a bug in the subversion configure description or implementation, or gar does something? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sun Dec 20 13:30:59 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 20 Dec 2009 07:30:59 -0500 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> Message-ID: <1261312122-sup-4951@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sun Dec 20 06:26:18 -0500 2009: > - At which stage (fetch, extract, install, merge, package) does the > expansion take place? The scripts should be expanded into $(DOWNLOADDIR) during the extract stage. > - What if the pkgname contains a dash? Will "define > CSWfoo-bar_postinstall" work? That should still work. The scripts are activated on seeing variables named like $(PKG)_$(ADMSCRIPT), so the - shouldn't cause problems. Let me know if it does. 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 bwalton at opencsw.org Sun Dec 20 13:32:58 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 20 Dec 2009 07:32:58 -0500 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: <6af4270912200352pee36f58ge14b8a8ee183f907@mail.gmail.com> References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> <6af4270912200352pee36f58ge14b8a8ee183f907@mail.gmail.com> Message-ID: <1261312324-sup-3751@ntdws12.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sun Dec 20 06:52:24 -0500 2009: > /etc ? is this a bug in the subversion configure description or > implementation, or gar does something? I'd suspect subversion's configure here. You should be able to see what it's doing in config.log -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 rupert at opencsw.org Sun Dec 20 14:42:47 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 14:42:47 +0100 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: <1261312324-sup-3751@ntdws12.chass.utoronto.ca> References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> <6af4270912200352pee36f58ge14b8a8ee183f907@mail.gmail.com> <1261312324-sup-3751@ntdws12.chass.utoronto.ca> Message-ID: <6af4270912200542u1313eebav882a32669c2fcf52@mail.gmail.com> On Sun, Dec 20, 2009 at 13:32, Ben Walton wrote: > Excerpts from rupert THURNER's message of Sun Dec 20 06:52:24 -0500 2009: > > > /etc ? is this a bug in the subversion configure description or > > implementation, or gar does something? > > I'd suspect subversion's configure here. You should be able to see > what it's doing in config.log > > config.log says: prefix='/opt/csw' sysconfdir='/opt/csw/etc' but i cannot find sysconfdir in the code. so i guess i do not understand something here. grepping for servers and etc is returning too many files so i am not sure rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Sun Dec 20 17:04:40 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 20 Dec 2009 17:04:40 +0100 Subject: [csw-maintainers] [csw-buildfarm] Out of swap space on build8x In-Reply-To: <4B2E4873.6040003@opencsw.org> References: <4B2E4873.6040003@opencsw.org> Message-ID: Hi Roger, Am 20.12.2009 um 16:53 schrieb Roger H?kansson: > I keep getting "ube: error: Cannot exec '/opt/studio/SOS11/SUNWspro/prod/bin/fbe' : Not enough space" on build8x and there isn't that much free swap space left. > Maybe someone could move /tmp/mbuffer-20091122 and /tmp/doxygen-apptrace out of the way so 400+MB would become free Done. To other maintainers: - Please use your homedirectory for specific stuff. As ZIL flushing is turned off it is as fast as writing to /tmp. - There is now also current8x/9x/10x. Please give them a try. Bets regards -- Dago From rupert at opencsw.org Sun Dec 20 17:48:40 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 17:48:40 +0100 Subject: [csw-maintainers] rebuild kde? In-Reply-To: <6af4270912200845i2206834dmc3cf1dab710f034d@mail.gmail.com> References: <6af4270912200845i2206834dmc3cf1dab710f034d@mail.gmail.com> Message-ID: <6af4270912200848h7ef0188sbeae96ba42e8967b@mail.gmail.com> would it be possible to rebuild kde? i tried to just rebuild kdesdk because of http://www.opencsw.org/bugtrack/view.php?id=3792 - but somehow it seems all kde needs to be built at once and i could not figure out what to start. rupert. From rupert at opencsw.org Sun Dec 20 17:50:11 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 17:50:11 +0100 Subject: [csw-maintainers] [csw-buildfarm] Out of swap space on build8x In-Reply-To: References: <4B2E4873.6040003@opencsw.org> Message-ID: <6af4270912200850t62e83493x31470f814d254646@mail.gmail.com> On Sun, Dec 20, 2009 at 17:04, Dagobert Michelsen wrote: > Hi Roger, > > Am 20.12.2009 um 16:53 schrieb Roger H?kansson: >> I keep getting "ube: error: Cannot exec '/opt/studio/SOS11/SUNWspro/prod/bin/fbe' : Not enough space" on build8x and there isn't that much free swap space left. >> Maybe someone could move /tmp/mbuffer-20091122 and /tmp/doxygen-apptrace out of the way so 400+MB would become free > > Done. To other maintainers: > - Please use your homedirectory for specific stuff. As ZIL flushing > ?is turned off it is as fast as writing to /tmp. > - There is now also current8x/9x/10x. Please give them a try. > rupert at current8x:~ $ PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" rupert at current8x:~ $ echo $PARALLELMFLAGS -l -j 1 is there only one thread, or did the way of querying it change? From skayser at opencsw.org Sun Dec 20 17:55:38 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 20 Dec 2009 17:55:38 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> Message-ID: <4B2E570A.3080708@opencsw.org> Hi Rupert, rupert THURNER wrote on 20.12.2009 02:39: > while trying to upgrade apache2 i thought it uses the apr package are you sure that this is the case, i.e. apache2 using a standalone apr runtime package? I just had a brief look and couldn't find a released apr package in our catalog. Doesn't apache2 ship with a bundled apr? > ... and so > i tried to upgrade this as well, and it gives an error while testing: > > ... > testsockets : FAILED 1 of 7 > ... > Failed Tests Total Fail Failed % > =================================================== > testsockets 7 1 14.29% > > gmake[1]: *** > [test-work/solaris8-sparc/build-isa-sparcv8/apr-1.3.9/Makefile] Error 2 > gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' > gmake: *** [merge-isa-sparcv8] Error 2 > > was this always like this or it is new? Presuming there are some sort of test logfiles, have a look in there so that you know what exactly fails. Maybe it's just IPv6 tests (the build boxes are not yet configure for IPv6). Sebastian From dam at opencsw.org Sun Dec 20 17:57:11 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 20 Dec 2009 17:57:11 +0100 Subject: [csw-maintainers] rebuild kde? In-Reply-To: <6af4270912200848h7ef0188sbeae96ba42e8967b@mail.gmail.com> References: <6af4270912200845i2206834dmc3cf1dab710f034d@mail.gmail.com> <6af4270912200848h7ef0188sbeae96ba42e8967b@mail.gmail.com> Message-ID: <2B41EBA1-A944-4D7D-9304-3A126B5D167D@opencsw.org> Hi Rupert, Am 20.12.2009 um 17:48 schrieb rupert THURNER : > would it be possible to rebuild kde? i tried to just rebuild kdesdk > because of http://www.opencsw.org/bugtrack/view.php?id=3792 - but > somehow it seems all kde needs to be built at once and i could not > figure out what to start. Just add the libs. Rebuilding KDE is a major task. Best regards -- Dago From dam at opencsw.org Sun Dec 20 18:02:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 20 Dec 2009 18:02:28 +0100 Subject: [csw-maintainers] [csw-buildfarm] Out of swap space on build8x In-Reply-To: <6af4270912200850t62e83493x31470f814d254646@mail.gmail.com> References: <4B2E4873.6040003@opencsw.org> <6af4270912200850t62e83493x31470f814d254646@mail.gmail.com> Message-ID: Hi Rupert, Am 20.12.2009 um 17:50 schrieb rupert THURNER : > On Sun, Dec 20, 2009 at 17:04, Dagobert Michelsen > wrote: >> Hi Roger, >> >> Am 20.12.2009 um 16:53 schrieb Roger H?kansson: >>> I keep getting "ube: error: Cannot exec '/opt/studio/SOS11/ >>> SUNWspro/prod/bin/fbe' : Not enough space" on build8x and there >>> isn't that much free swap space left. >>> Maybe someone could move /tmp/mbuffer-20091122 and /tmp/doxygen- >>> apptrace out of the way so 400+MB would become free >> >> Done. To other maintainers: >> - Please use your homedirectory for specific stuff. As ZIL flushing >> is turned off it is as fast as writing to /tmp. >> - There is now also current8x/9x/10x. Please give them a try. >> > > rupert at current8x:~ > $ PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" > > rupert at current8x:~ > $ echo $PARALLELMFLAGS > -l -j 1 > > is there only one thread, or did the way of querying it change? There is only one thread. Build8x is a VM on VMware workstation on Linux where current8x is a vSphere 4 VM, which has experimental support for Solaris 8 which ESX 3.5 didn't have. Unfortunately the idle detection doesn't work with #CPU > 1 on this environment where it does work on workstation. As I want to turn some boxes off I can offer to add current8x2, but that won't speed up your single build. Best regards -- Dago From skayser at opencsw.org Sun Dec 20 18:06:21 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 20 Dec 2009 18:06:21 +0100 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> Message-ID: <4B2E598D.5000806@opencsw.org> rupert THURNER wrote on 20.12.2009 05:40: > dagobert filed a subversion bug saying the config file should go in a > different place: > > The configuration for the svn commandline-client is at > /etc/subversion/servers > instead of > /etc/opt/csw/subversion/servers > > isn't this a standard configuration option and gar should do this? In theory you are right and GAR should pre-set --sysconfdir to /etc/opt/csw (currently it is /opt/csw/etc). Nevertheless, AFAIR this was considered a major change, possibly breaking existing build descriptions. Thus, it was decided to leave it to the maintainer to change his build descriptions. > an > excerpt from the subversion configure is below: > > rupert at build8s: ... build-isa-sparcv8/subversion-1.6.6 > $ ./configure --help > `configure' configures subversion 1.6.6 to adapt to many kinds of systems. > ... > an installation prefix other than `/usr/local' using `--prefix', > for instance `--prefix=$HOME'. > > For better control, use the options below. > > Fine tuning of the installation directories: > .... > --sysconfdir=DIR read-only single-machine data [PREFIX/etc] > ... While sysconfdir defaults to $prefix/etc it is perfectly fine to adjust it when required. Simply add sysconfdir = /etc/opt/csw to your Makefile. Have a look at the orca Makefile [1] for an example. Sebastian [1] https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/orca/trunk/Makefile From skayser at opencsw.org Sun Dec 20 18:09:57 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 20 Dec 2009 18:09:57 +0100 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: <4B2E598D.5000806@opencsw.org> References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> <4B2E598D.5000806@opencsw.org> Message-ID: <4B2E5A65.4070805@opencsw.org> Sebastian Kayser wrote on 20.12.2009 18:06: > rupert THURNER wrote on 20.12.2009 05:40: >> dagobert filed a subversion bug saying the config file should go in a >> different place: >> >> The configuration for the svn commandline-client is at >> /etc/subversion/servers >> instead of >> /etc/opt/csw/subversion/servers >> >> isn't this a standard configuration option and gar should do this? > > In theory you are right and GAR should pre-set --sysconfdir to > /etc/opt/csw (currently it is /opt/csw/etc). Nevertheless, AFAIR this > was considered a major change, possibly breaking existing build > descriptions. Thus, it was decided to leave it to the maintainer to > change his build descriptions. As a related question. Dago, is there a target similar to "modev" or "ccenv" which displays the default ./configure args? Sebastian From skayser at opencsw.org Sun Dec 20 18:17:16 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 20 Dec 2009 18:17:16 +0100 Subject: [csw-maintainers] [csw-buildfarm] Out of swap space on build8x In-Reply-To: References: <4B2E4873.6040003@opencsw.org> <6af4270912200850t62e83493x31470f814d254646@mail.gmail.com> Message-ID: <4B2E5C1C.3010802@opencsw.org> Dagobert Michelsen wrote on 20.12.2009 18:02: > There is only one thread. Build8x is a VM on VMware workstation on > Linux where current8x is a vSphere 4 VM, which has experimental > support for Solaris 8 which ESX 3.5 didn't have. Unfortunately the > idle detection doesn't work with #CPU > 1 on this environment where it > does work on workstation. Interesting. Do you have a KB or release notes reference for this? Sebastian From dam at opencsw.org Sun Dec 20 18:22:09 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 20 Dec 2009 18:22:09 +0100 Subject: [csw-maintainers] [csw-buildfarm] Out of swap space on build8x In-Reply-To: <4B2E5C1C.3010802@opencsw.org> References: <4B2E4873.6040003@opencsw.org> <6af4270912200850t62e83493x31470f814d254646@mail.gmail.com> <4B2E5C1C.3010802@opencsw.org> Message-ID: Hi Sebastian, Am 20.12.2009 um 18:17 schrieb Sebastian Kayser : > Dagobert Michelsen wrote on 20.12.2009 18:02: >> There is only one thread. Build8x is a VM on VMware workstation on >> Linux where current8x is a vSphere 4 VM, which has experimental >> support for Solaris 8 which ESX 3.5 didn't have. Unfortunately the >> idle detection doesn't work with #CPU > 1 on this environment where >> it >> does work on workstation. > > Interesting. Do you have a KB or release notes reference for this? No, that is just my observation and as Solaris 8 support is marked experimental I can't open a bug report. Best regards -- Dago From rupert at opencsw.org Sun Dec 20 18:25:03 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 18:25:03 +0100 Subject: [csw-maintainers] subversion sysconfdir='/opt/csw/etc' - servers file anyway created in /etc/ ? Message-ID: <6af4270912200925lc81f6dex455386c4e730b8a@mail.gmail.com> fyi. ---------- Forwarded message ---------- From: Branko ?ibej Date: Sun, Dec 20, 2009 at 18:16 Subject: Re: sysconfdir='/opt/csw/etc' - servers file anyway created in /etc/ ? To: "rupert.thurner" Cc: dev at subversion.apache.org rupert.thurner wrote: > while compiling subversion-1.6.6 for http://opencsw.org we noticed > that the servers file is created in the /etc directory, even if > configure.log shows the sysconfdir is /opt/csw/etc, and the prefix is / > opt/csw. where in the code do you expect to configure this directory? > Oh my ... it's hardcoded in subversion/libsvh_subr/config_impl.h. Some build system twiddling will be necessary to fix that. -- Brane From dam at opencsw.org Sun Dec 20 20:54:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 20 Dec 2009 20:54:45 +0100 Subject: [csw-maintainers] /etc/subversion, /etc/opt/csw/subversion, /opt/csw/etc/subversion/ In-Reply-To: <4B2E5A65.4070805@opencsw.org> References: <6af4270912192040vd693d24wa80786deca4c3a64@mail.gmail.com> <4B2E598D.5000806@opencsw.org> <4B2E5A65.4070805@opencsw.org> Message-ID: Hi Sebastian, Am 20.12.2009 um 18:09 schrieb Sebastian Kayser: > Sebastian Kayser wrote on 20.12.2009 18:06: >> rupert THURNER wrote on 20.12.2009 05:40: >>> dagobert filed a subversion bug saying the config file should go >>> in a >>> different place: >>> >>> The configuration for the svn commandline-client is at >>> /etc/subversion/servers >>> instead of >>> /etc/opt/csw/subversion/servers >>> >>> isn't this a standard configuration option and gar should do this? >> >> In theory you are right and GAR should pre-set --sysconfdir to >> /etc/opt/csw (currently it is /opt/csw/etc). Nevertheless, AFAIR this >> was considered a major change, possibly breaking existing build >> descriptions. Thus, it was decided to leave it to the maintainer to >> change his build descriptions. > > As a related question. Dago, is there a target similar to "modev" or > "ccenv" which displays the default ./configure args? Unfortunately not. Care to add it? Best regards -- Dago From dam at opencsw.org Sun Dec 20 20:55:23 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 20 Dec 2009 20:55:23 +0100 Subject: [csw-maintainers] subversion sysconfdir='/opt/csw/etc' - servers file anyway created in /etc/ ? In-Reply-To: <6af4270912200925lc81f6dex455386c4e730b8a@mail.gmail.com> References: <6af4270912200925lc81f6dex455386c4e730b8a@mail.gmail.com> Message-ID: <6E823751-C36A-4E91-87FA-F9751ED8D9F8@opencsw.org> Hi Rupert, Am 20.12.2009 um 18:25 schrieb rupert THURNER: > fyi. Thanks. Did you open a bug report upstream? Would they accept a bug report? Best regards -- Dago > > > ---------- Forwarded message ---------- > From: Branko ?ibej > Date: Sun, Dec 20, 2009 at 18:16 > Subject: Re: sysconfdir='/opt/csw/etc' - servers file anyway created > in /etc/ ? > To: "rupert.thurner" > Cc: dev at subversion.apache.org > > > rupert.thurner wrote: >> while compiling subversion-1.6.6 for http://opencsw.org we noticed >> that the servers file is created in the /etc directory, even if >> configure.log shows the sysconfdir is /opt/csw/etc, and the prefix >> is / >> opt/csw. where in the code do you expect to configure this directory? >> > Oh my ... it's hardcoded in subversion/libsvh_subr/config_impl.h. Some > build system twiddling will be necessary to fix that. > > -- Brane > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers From rupert at opencsw.org Sun Dec 20 21:33:35 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 20 Dec 2009 21:33:35 +0100 Subject: [csw-maintainers] subversion sysconfdir='/opt/csw/etc' - servers file anyway created in /etc/ ? In-Reply-To: <6E823751-C36A-4E91-87FA-F9751ED8D9F8@opencsw.org> References: <6af4270912200925lc81f6dex455386c4e730b8a@mail.gmail.com> <6E823751-C36A-4E91-87FA-F9751ED8D9F8@opencsw.org> Message-ID: <6af4270912201233g3e083175j4651738189b1cf0b@mail.gmail.com> On Sun, Dec 20, 2009 at 20:55, Dagobert Michelsen wrote: > Hi Rupert, > > Am 20.12.2009 um 18:25 schrieb rupert THURNER: >> >> fyi. > > Thanks. Did you open a bug report upstream? Would they accept a bug > report? no, i did not. in former tigris times somebody asked to open a bug report. but i am unsure how apache this now, so i thought maybe wait a little what happens. i patched it in opencsw for the moment. rupert. >> ---------- Forwarded message ---------- >> From: Branko ?ibej >> Date: Sun, Dec 20, 2009 at 18:16 >> Subject: Re: sysconfdir='/opt/csw/etc' - servers file anyway created in >> /etc/ ? >> To: "rupert.thurner" >> Cc: dev at subversion.apache.org >> >> >> rupert.thurner wrote: >>> >>> while compiling subversion-1.6.6 for http://opencsw.org we noticed >>> that the servers file is created in the /etc directory, even if >>> configure.log shows the sysconfdir is /opt/csw/etc, and the prefix is / >>> opt/csw. where in the code do you expect to configure this directory? >>> >> Oh my ... it's hardcoded in subversion/libsvh_subr/config_impl.h. Some >> build system twiddling will be necessary to fix that. >> >> -- Brane >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers From rupert at opencsw.org Mon Dec 21 11:59:22 2009 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 21 Dec 2009 11:59:22 +0100 Subject: [csw-maintainers] debug output - all variables Message-ID: <6af4270912210259n23144253pbf65dfc692626721@mail.gmail.com> hi, is there a possibility to display all the defined variables for a debug output? i find it particularly difficult to see through all the variables used in the subversion makefile. just to give you some randomly picked out examples which finally makes then libsvn_ra_dav go into /opt/csw/lib instead of /opt/csw/lib/svn. $(libdir) $(SVNLIB) $(DESTDIR) $(prefix) $(WORKDIR) SVNLIB = $(prefix)/lib/svn CONFIGURE_ARGS = $(DIRPATHS) --libdir=$(SVNLIB) --libexecdir=$(SVNLIB) fix-ra_dav: @# libsvn_ra_dav-1* has been renamed to libsvn_ra_neon-1* @# in the new versions of subversion, @# we need to link for backward compatability @(gln -s $(DESTDIR)$(libdir)/libsvn_ra_neon-1.so.0.0.0 \ $(DESTDIR)$(libdir)/libsvn_ra_dav-1.so.0) @(gln -s $(DESTDIR)$(libdir)/libsvn_ra_neon-1.so.0.0.0 \ $(DESTDIR)$(libdir)/libsvn_ra_dav-1.so) @$(MAKECOOKIE) other usages include: @(grm -fr $(DESTDIR)$(prefix)/lib/perl/5.8.8) i tried "gmake -d" but the output is enourmous - and i could not see the variables. rupert. ---------- Forwarded message ---------- From: Mantis Bug Tracker Date: Mon, Dec 21, 2009 at 10:12 Subject: [subversion 0003792]: libsvn_fs_base-1.so.0 and libsvn_ra_dav-1.so.0 missing To: rupert at opencsw.org A NOTE has been added to this issue. ====================================================================== http://www.opencsw.org/bugtrack/view.php?id=3792 ====================================================================== Reported By: ? ? ? ? ? ? ? ?james Assigned To: ====================================================================== Project: ? ? ? ? ? ? ? ? ? ?subversion Issue ID: ? ? ? ? ? ? ? ? ? 3792 Category: ? ? ? ? ? ? ? ? ? packaging Reproducibility: ? ? ? ? ? ?sometimes Severity: ? ? ? ? ? ? ? ? ? crash Priority: ? ? ? ? ? ? ? ? ? normal Status: ? ? ? ? ? ? ? ? ? ? feedback ====================================================================== Date Submitted: ? ? ? ? ? ? 2009-07-30 16:52 CEST Last Modified: ? ? ? ? ? ? ?2009-12-21 10:12 CET ====================================================================== Summary: ? ? ? ? ? ? ? ? ? ?libsvn_fs_base-1.so.0 and libsvn_ra_dav-1.so.0 missing Description: Previouly svn included libsvn_fs_base-1.so.0 and libsvn_ra_dav-1.so.0. These are no longer in svn but stil needed by 2 dependants. ?Suggest svn packs the old files until the dependants are rebuilt, if that is not possible please expedite the rebuild of the depends. ====================================================================== ---------------------------------------------------------------------- ?(0007114) james (reporter) - 2009-12-21 10:12 ?http://www.opencsw.org/bugtrack/view.php?id=3792#c7114 ---------------------------------------------------------------------- With ldd. If you have fixed this please say so. "please address this to CSWkdesdk and CSWkdevelop if it is still valid." says to me "This is not fixed in SVN, the depends will have to be fixed if they are not fixed already". ?Sorry if that is not the correct interpretation of your words, please qualify what you have done. From dam at opencsw.org Mon Dec 21 13:12:39 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 21 Dec 2009 13:12:39 +0100 Subject: [csw-maintainers] debug output - all variables In-Reply-To: <6af4270912210259n23144253pbf65dfc692626721@mail.gmail.com> References: <6af4270912210259n23144253pbf65dfc692626721@mail.gmail.com> Message-ID: <69CF9F9A-C9C7-4A54-BCDD-BE3BB368DCDF@opencsw.org> Hi Rupert, Am 21.12.2009 um 11:59 schrieb rupert THURNER: > is there a possibility to display all the defined variables for a > debug output? No, you can only output specific variables where the names of the variables must be known. > i find it particularly difficult to see through all the > variables used in the subversion makefile. just to give you some > randomly picked out examples which finally makes then libsvn_ra_dav go > into /opt/csw/lib instead of /opt/csw/lib/svn. > > $(libdir) > $(SVNLIB) > $(DESTDIR) > $(prefix) > $(WORKDIR) Ok, so you want to print out basically the values for the variables in gar.conf.mk or the GAR variable reference, right? > SVNLIB = $(prefix)/lib/svn > > CONFIGURE_ARGS = $(DIRPATHS) --libdir=$(SVNLIB) --libexecdir=$ > (SVNLIB) > > fix-ra_dav: > @# libsvn_ra_dav-1* has been renamed to libsvn_ra_neon-1* > @# in the new versions of subversion, > @# we need to link for backward compatability > @(gln -s $(DESTDIR)$(libdir)/libsvn_ra_neon-1.so.0.0.0 \ > $(DESTDIR)$(libdir)/libsvn_ra_dav-1.so.0) > @(gln -s $(DESTDIR)$(libdir)/libsvn_ra_neon-1.so.0.0.0 \ > $(DESTDIR)$(libdir)/libsvn_ra_dav-1.so) > @$(MAKECOOKIE) This does not work as you don't change the libdir variable. You could do libdir_install = $(prefix)/lib/svn > other usages include: > @(grm -fr $(DESTDIR)$(prefix)/lib/perl/5.8.8) > > i tried "gmake -d" but the output is enourmous - and i could not see > the variables. That does not work, right. I am currently looking at the GNU make debugger "remake" if it would help. Best regards -- Dago From skayser at opencsw.org Mon Dec 21 13:18:49 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 21 Dec 2009 13:18:49 +0100 Subject: [csw-maintainers] debug output - all variables In-Reply-To: <69CF9F9A-C9C7-4A54-BCDD-BE3BB368DCDF@opencsw.org> References: <6af4270912210259n23144253pbf65dfc692626721@mail.gmail.com> <69CF9F9A-C9C7-4A54-BCDD-BE3BB368DCDF@opencsw.org> Message-ID: <20091221121849.GG7667@sebastiankayser.de> * Dagobert Michelsen wrote: > Am 21.12.2009 um 11:59 schrieb rupert THURNER: > >is there a possibility to display all the defined variables for a > >debug output? > > No, you can only output specific variables where the names of the > variables > must be known. > > >i find it particularly difficult to see through all the > >variables used in the subversion makefile. just to give you some > >randomly picked out examples which finally makes then libsvn_ra_dav go > >into /opt/csw/lib instead of /opt/csw/lib/svn. > > > >$(libdir) > >$(SVNLIB) > >$(DESTDIR) > >$(prefix) > >$(WORKDIR) > > Ok, so you want to print out basically the values for the variables in > gar.conf.mk > or the GAR variable reference, right? > > >SVNLIB = $(prefix)/lib/svn > > > >CONFIGURE_ARGS = $(DIRPATHS) --libdir=$(SVNLIB) --libexecdir=$ > >(SVNLIB) > > > >fix-ra_dav: > > @# libsvn_ra_dav-1* has been renamed to libsvn_ra_neon-1* > > @# in the new versions of subversion, > > @# we need to link for backward compatability > > @(gln -s $(DESTDIR)$(libdir)/libsvn_ra_neon-1.so.0.0.0 \ > > $(DESTDIR)$(libdir)/libsvn_ra_dav-1.so.0) > > @(gln -s $(DESTDIR)$(libdir)/libsvn_ra_neon-1.so.0.0.0 \ > > $(DESTDIR)$(libdir)/libsvn_ra_dav-1.so) > > @$(MAKECOOKIE) > > This does not work as you don't change the libdir variable. You could do > libdir_install = $(prefix)/lib/svn It doesn't really answer your question, but as a general rule of thumb: what I found to be helpful (not only when it comes to debugging) is to just drop the @ signs in front of the command lines. This way, you can at least see right away how variables expand when each command is called. Nowadays, I only leave the @ in front of $(MAKECOOKIE). Sebastian From maciej at opencsw.org Mon Dec 21 15:03:14 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 21 Dec 2009 14:03:14 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: I've worked on this program some more. I'm working on incorporating the subversion commit messages. The idea is to include all commit messages since the previous version of the package was released. Here's an example of a larger submission. It's generated with some hand-added content. * new package: pius * It's a small application to assist with tedious GPG key signing. - commit messages: - 'Added archall and a build dep Python' - 'initial commit' + bender:/home/newpkgs/pius-2.0.3,REV=2009.11.29-SunOS5.8-all-CSW.pkg.gz * pysvn: minor version upgrade * replaces the old subversion bindings with the pysvn project files. - commit messages: - 'using CSWbash, disabling tests on Solaris 8 due to lack of UTF-8 locale support' - 'Removed template comments from the Makefile, added blurb' - 'Initial commit' - from: 1.6.2,REV=2009.06.13 - to: 1.7.1,REV=2009.12.17 + bender:/home/newpkgs/pysvn-1.7.1,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/pysvn-1.7.1,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz * python: patchlevel upgrade * Patched it to fix the getpass() issue. - commit messages: - 'Adding the patch from http://bugs.python.org/issue7208' - 'Upgrading to 2.6.4, removing content from CSWpython-rt with the intention to kill it, moving the distutils module to CSWpython, moving smtpd.py to the -devel package.' - from: 2.6.2,REV=2009.05.28 - to: 2.6.4,REV=2009.12.17 + bender:/home/newpkgs/python-2.6.4,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/python-2.6.4,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/python_devel-2.6.4,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/python_devel-2.6.4,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/python_rt-2.6.4,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/python_rt-2.6.4,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/python_tk-2.6.4,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/python_tk-2.6.4,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/idle-2.6.4,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/idle-2.6.4,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz * new package: python_test * Since the install target installs those files, the upstream presumably wants it to be installable. + bender:/home/newpkgs/python_test-2.6.4,REV=2009.12.17-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/python_test-2.6.4,REV=2009.12.17-SunOS5.8-sparc-CSW.pkg.gz * mysql5: patchlevel upgrade * First release with the source-controlled build. - commit messages - 'mysql-5.0.x: Using post-install instead of post-install-modulated' - 'mysql5: 5.0 version bump up to 5.0.87' - 'mysql-5.0.x: Added CSWperl as a dependency for CSWmysql5devel' - 'mysql5-5.0.x: Fixing a problem with the runtime library path.' - 'mysql5-5.0.x: Adjusting the quick start file, adjusting the startup script, shuffling files around the packages (mysql_config in mysql5devel), adding symlinks from /opt/csw/include/mysql and /opt/csw/lib/mysql' - dmichelsen 'mysql-5.0.x: Tweak Makefile' - 'mysql-5.0.x: Fixed runtime library paths, fixed the quickstart file, added a postinstall file.' - 'mysql5: Fixing the cswusergroup path (changing to /etc/opt/csw)' - 'mysql5: Runtime libraries can live together with mysql4.' - 'mysql5: cswusergroup must be listed as well' - 'mysql5: Defined incompatible packages, set runtime dependencies, set the ownership of /var/opt/csw/mysql directory, added a preinstall script with a warning.' - 'mysql5: Better prototypes for mysql5 subpackages.' - 'mysql5: First iteration of slicing it into separate packages. Things left to do: Creating mysql user and group, pre/post install/remove scripts, a check if MySQL database exists' - 'mysql5: Copying mysql-5.1 to branches/mysql-5.0.x\n' - from: 5.0.51,REV=2008.01.20 - to: 5.0.87,REV=2009.11.13 + bender:/home/newpkgs/mysql5-5.0.87,REV=2009.11.13-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/mysql5-5.0.87,REV=2009.11.13-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/mysql5devel-5.0.87,REV=2009.11.13-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/mysql5devel-5.0.87,REV=2009.11.13-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/mysql5rt-5.0.87,REV=2009.11.13-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/mysql5rt-5.0.87,REV=2009.11.13-SunOS5.8-sparc-CSW.pkg.gz - from: 5.0.51,REV=2007.12.19 - to: 5.0.87,REV=2009.11.13 + bender:/home/newpkgs/mysql5bench-5.0.87,REV=2009.11.13-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/mysql5bench-5.0.87,REV=2009.11.13-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/mysql5client-5.0.87,REV=2009.11.13-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/mysql5client-5.0.87,REV=2009.11.13-SunOS5.8-sparc-CSW.pkg.gz + bender:/home/newpkgs/mysql5test-5.0.87,REV=2009.11.13-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/mysql5test-5.0.87,REV=2009.11.13-SunOS5.8-sparc-CSW.pkg.gz -- $Id: opencsw.py 111 2009-12-17 10:59:16Z $ To use it for your package submissions, you can run submitpkg on the login host as follows: svn co https://opencsw.svn.sourceforge.net/svnroot/opencsw/utilities cd utilities ./submit_to_newpkgs.py -h ls -l /home/testing | grep ${LOGNAME} ./submit_to_newpkgs.py -p catalogname1,catalogname2,... Maciej From maciej at opencsw.org Mon Dec 21 16:00:24 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 21 Dec 2009 15:00:24 +0000 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: Message-ID: I can't run cssh with perl from testing: $ cssh ld.so.1: perl: fatal: relocation error: file /opt/csw/lib/perl/csw/auto/Tk/Event /Event.so: symbol Perl_Tstack_sp_ptr: referenced symbol not found Killed This is on Solaris 10 x86. Has anyone else observed it? Maciej From dam at opencsw.org Mon Dec 21 16:11:09 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 21 Dec 2009 16:11:09 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: Message-ID: Hi Maciej, Am 21.12.2009 um 16:00 schrieb Maciej (Matchek) Blizinski: > I can't run cssh with perl from testing: > > $ cssh > ld.so.1: perl: fatal: relocation error: file > /opt/csw/lib/perl/csw/auto/Tk/Event /Event.so: symbol > Perl_Tstack_sp_ptr: referenced symbol not found > Killed > > This is on Solaris 10 x86. > > Has anyone else observed it? Yes. Cited from [1]: "As far as I saw in the source of perl 5.8.8 and 5.10.0 there is a renaming of all Symbols from Perl_T... to Perl_I, in this case in 5.10.0 it's called Perl_Istack_sp_Ptr." It looks like that this one is something we must just accept and rebuild all failing packages. Gary, I installed Perl 5.10.1 on build8st, would you mind giving clusterssh a try against the updated Perl? Best regards -- Dago [1] http://forum.parallels.com/showthread.php?p=343647#post343647 From maciej at opencsw.org Mon Dec 21 16:16:12 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 21 Dec 2009 15:16:12 +0000 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: Message-ID: On Mon, Dec 21, 2009 at 3:11 PM, Dagobert Michelsen wrote: > Gary, I installed Perl 5.10.1 on build8st, would you mind giving clusterssh > a try against the updated Perl? It's not that, at least in this case. clusterssh doesn't contain any shared objects, the package consists only of a perl script and a man page: http://www.opencsw.org/search/clusterssh From skayser at opencsw.org Mon Dec 21 16:20:01 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 21 Dec 2009 16:20:01 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: Message-ID: <20091221152001.GH7667@sebastiankayser.de> * Maciej (Matchek) Blizinski wrote: > On Mon, Dec 21, 2009 at 3:11 PM, Dagobert Michelsen wrote: > > Gary, I installed Perl 5.10.1 on build8st, would you mind giving clusterssh > > a try against the updated Perl? > > It's not that, at least in this case. clusterssh doesn't contain any > shared objects, the package consists only of a perl script and a man > page: > > http://www.opencsw.org/search/clusterssh It relies on pm_tk which in turn is compiled against the previous perl version. We should set up some automated way of re-building all perl modules with shared objects files against the new perl. Sebastian From dam at opencsw.org Mon Dec 21 16:23:14 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 21 Dec 2009 16:23:14 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: Message-ID: <61C77CC1-FA40-4386-8210-602A52B63494@opencsw.org> Hi Maciej, Am 21.12.2009 um 16:16 schrieb Maciej (Matchek) Blizinski: > On Mon, Dec 21, 2009 at 3:11 PM, Dagobert Michelsen > wrote: >> Gary, I installed Perl 5.10.1 on build8st, would you mind giving >> clusterssh >> a try against the updated Perl? > > It's not that, at least in this case. clusterssh doesn't contain any > shared objects, the package consists only of a perl script and a man > page: > > http://www.opencsw.org/search/clusterssh Umh, your right. Gary, sorry to have woken you ;-) No, wait: clusterssh has NO dependencies defined. This is obviously wrong. Looks like there are already bugs reported about this, though: http://www.opencsw.org/mantis/set_project.php?project_id=1661 Looks like it is pm_tk: > ld.so.1: perl: fatal: relocation error: file /opt/csw/lib/perl/csw/ > auto/Tk/Event/Event.so: symbol Perl_Tstack_sp_ptr: referenced symbol > not found > zsh: killed cssh > build8st% grep /opt/csw/lib/perl/csw/auto/Tk/Event/Event.so /var/ > sadm/install/contents > /opt/csw/lib/perl/csw/auto/Tk/Event/Event.so f none 0555 root bin > 114988 15756 1130401998 CSWpmtk This is maintained by Murray Jensen, who is unfortunately not fluent in GAR yet. Murray: Would you mind giving it a look with Perl 5.10.1 from testing/ anyway? Best regards -- Dago From dam at opencsw.org Mon Dec 21 16:26:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 21 Dec 2009 16:26:31 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: <20091221152001.GH7667@sebastiankayser.de> References: <20091221152001.GH7667@sebastiankayser.de> Message-ID: <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> Hi Sebastian, Am 21.12.2009 um 16:20 schrieb Sebastian Kayser: > * Maciej (Matchek) Blizinski wrote: >> On Mon, Dec 21, 2009 at 3:11 PM, Dagobert Michelsen >> wrote: >>> Gary, I installed Perl 5.10.1 on build8st, would you mind giving >>> clusterssh >>> a try against the updated Perl? >> >> It's not that, at least in this case. clusterssh doesn't contain any >> shared objects, the package consists only of a perl script and a man >> page: >> >> http://www.opencsw.org/search/clusterssh > > It relies on pm_tk which in turn is compiled against the previous perl > version. We should set up some automated way of re-building all perl > modules with shared objects files against the new perl. The easiest way would be to update cpan2pkg from CSWcswutils to output GAR Makefile and then mass-update the modules. I won't have much time over christmas as I won a Live Upgrade migration from U6 UFS to U8 ZFS for an 8-machine Sun Ray cluster which will suck up most of my "spare" time... Sebastian, would you mind giving it a look? Best regards -- Dago From bwalton at opencsw.org Mon Dec 21 16:38:55 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 21 Dec 2009 10:38:55 -0500 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: <1261312122-sup-4951@ntdws12.chass.utoronto.ca> References: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> <1261312122-sup-4951@ntdws12.chass.utoronto.ca> Message-ID: <1261409593-sup-7603@ntdws12.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Dec 20 07:30:59 -0500 2009: Hi Maciej, > The scripts should be expanded into $(DOWNLOADDIR) during the extract > stage. I realized yesterday after I'd left the house that this was incorrect. I'd meant to type 'during the fetch' stage. It is expanded as it's placed in $(DOWNLOADDIR), at the same point where the source tarballs, etc are retrieved. Sorry about the typo. -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. From glaw at blastwave.org Wed Dec 2 11:51:51 2009 From: glaw at blastwave.org (Gary Law) Date: Wed, 02 Dec 2009 10:51:51 -0000 Subject: [csw-maintainers] CSWcswclassutils wants to write in /usr Message-ID: Hi all Been chatting with Maciej about a bug/feature I've hit where I can't properly install CSWcswclassutils, as it wants to write in /usr, and that's mounted readonly (it's a non-global zone). Does this mean CSWcswclassutils violates policy? I thought we had to confine ourselves to /opt, /etc/opt/csw and /var/opt/csw Maciej suggested non-global zones and/or non-writable /usr aren't supported by CSW, which may be correct, but is news to me. Thoughts? Gary From blizinski at google.com Mon Dec 21 15:50:06 2009 From: blizinski at google.com (Maciej (Matchek) Blizinski) Date: Mon, 21 Dec 2009 14:50:06 +0000 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh Message-ID: I can't run cssh with perl from testing: $ cssh ld.so.1: perl: fatal: relocation error: file /opt/csw/lib/perl/csw/auto/Tk/Event /Event.so: symbol Perl_Tstack_sp_ptr: referenced symbol not found Killed This is on Solaris 10 x86. Has anyone else observed it? Maciej From phil at bolthole.com Mon Dec 21 20:58:05 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Dec 2009 11:58:05 -0800 Subject: [csw-maintainers] rebuild kde? In-Reply-To: <2B41EBA1-A944-4D7D-9304-3A126B5D167D@opencsw.org> References: <6af4270912200845i2206834dmc3cf1dab710f034d@mail.gmail.com> <6af4270912200848h7ef0188sbeae96ba42e8967b@mail.gmail.com> <2B41EBA1-A944-4D7D-9304-3A126B5D167D@opencsw.org> Message-ID: On Sunday, December 20, 2009, Dagobert Michelsen wrote: > Hi Rupert, > > Just add the libs. Rebuilding KDE is a major task. > it is indeed a major task... that being said, it would be a very very good thing for opencsw if someone would take on this task From phil at bolthole.com Mon Dec 21 21:02:07 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Dec 2009 12:02:07 -0800 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: oh let's NOT include all svn messages please. too much information potentially From phil at bolthole.com Mon Dec 21 21:07:52 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Dec 2009 12:07:52 -0800 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: <4B2E570A.3080708@opencsw.org> References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> <4B2E570A.3080708@opencsw.org> Message-ID: btw as a reminder: while apache2 "can" use the bundled apr there are some benefits to having it use a standalone external package it would be a very nice thing if we had one, and in fact there was some package in recent months that needed one? From glaw at opencsw.org Mon Dec 21 22:27:02 2009 From: glaw at opencsw.org (Gary Law) Date: Mon, 21 Dec 2009 21:27:02 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <4B2BFD68.6090301@opencsw.org> References: <625385e30912021501i9301dcctdcae84b90c10126b@mail.gmail.com> <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> Message-ID: All We seem to be stuck here with a choice, and to avoid lots of quoting I'll summarise: 1) Use CSWcswclassutils and stop those with read-only /usr using our packages; 2) Migrate away from CSWcswclassutils and build another mechanism that's similar. Primary problem with (1) is it rules out using CSW packages on a significant number of machines which have read-only /usr. I'd call that a major issue, a showstopper bug in the case of the package I'm trying to get into GAR. Primary problem with (2) is that we might end up having users have to answer 'yes' to postinstall script questions if they don't have the right sort of admin file set up. Minor issue IMHO. I'd say the benefits of fixing (1) massively outweigh the disbenefits of (2). Thoughts? Gary -- glaw at opencsw.org From maciej at opencsw.org Mon Dec 21 22:28:33 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 21 Dec 2009 21:28:33 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Dec 21, 2009 at 8:02 PM, Philip Brown wrote: > oh let's NOT include all svn messages please. > too much information potentially I'll first explain why I was thinking of including them. I'm aiming at automating all the bits that don't absolutely require human intervention. I assume that as the release manager, you would like to know what has changed since the last release. Compiling a list of commit messages can provide a nice chronological description of changes made to the package. In the future one might envision an automated system in which the maintainer doesn't write an e-mail, but simply states the decision "I want X to be submitted for release" and the rest pf the process, up to the point when the release candidate files are presented to the release manager, is automated. I think that the rest of the crew has a similar vision, please chime in. Since it's impossible to write such a system in one go, I'm working on small bits, and making the commit messages part of the process was one of the things I wanted to do. If you don't care about any sort of comments about the submitted files, we can skip over this functionality, no problem. It was my intuition that you'd want them. There could also be a different solution in which there would be an optional view with the details. E-mail is not suited for that, unfortunately. Perhaps there could be a generated link associated with each piece of software, showing the differences between the build files, such as: http://tinyurl.com/ygvbh7v (A side note: this would be build-system independent. The only requirement would be for the software in question to point at the URL from which it was built and provide the revision number.) What do you think? From maciej at opencsw.org Mon Dec 21 22:47:21 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 21 Dec 2009 21:47:21 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> Message-ID: On Mon, Dec 21, 2009 at 9:27 PM, Gary Law wrote: > All > > We seem to be stuck here with a choice, and to avoid lots of quoting > I'll summarise: > > 1) Use CSWcswclassutils and stop those with read-only /usr using our packages; > > 2) Migrate away from CSWcswclassutils and build another mechanism > that's similar. > > Primary problem with (1) is it rules out using CSW packages on a > significant number of machines which have read-only /usr. I'd call > that a major issue, a showstopper bug in the case of the package I'm > trying to get into GAR. Sad to hear that. > Primary problem with (2) is that we might end up having users have to > answer 'yes' to postinstall script questions if they don't have the > right sort of admin file set up. Minor issue IMHO. > > I'd say the benefits of fixing (1) massively outweigh the disbenefits > of (2). Thoughts? I agree on the point that answering 'yes' to the postinstall scripts is a minor issue. If one maintains numerous of Solaris machines, automated package installs are a must. Maciej From phil at bolthole.com Mon Dec 21 22:51:19 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Dec 2009 13:51:19 -0800 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: On Monday, December 21, 2009, Maciej (Matchek) Blizinski wrote: > On Mon, Dec 21, 2009 at 8:02 PM, Philip Brown wrote: >> oh let's NOT include all svn messages please. >> too much information potentially > > I'll first explain why I was thinking of including them. ?I'm aiming > at automating all the bits that don't absolutely require human > intervention. ?I assume that as the release manager, you would like to > know what has changed since the last release. as release manager, I might like t know if anythng IMPORTANT has changed. parsing all those entries is the antithesis of automaton. it requires detailed human scrutiny, if the maintained has been writng detailed change logs. perhaps it might be beneficial if the tool optionally displayed the logs to the mantainer only. then they can determine if there is anything important to pass on to the release manager? From phil at bolthole.com Mon Dec 21 23:05:28 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 21 Dec 2009 14:05:28 -0800 Subject: [csw-maintainers] Alternatives In-Reply-To: <00611D04-93AA-423F-B656-EE6A512A9190@opencsw.org> References: <4B2C021B.50800@opencsw.org> <00611D04-93AA-423F-B656-EE6A512A9190@opencsw.org> Message-ID: >Or would you also argument to have > a "ll" (or "cswll") binary that is not at all a comperable argument. ls -l. is already short 2chars vs 4 Additionally, noone has yet addressed my concern about it being fully in the "dpkg" namespace. can we get a second party who is competant in perl, give the proposed code an audit please? (and I also think the name sucks. "update-alternatives"? it's very name describes it as an adjunct utility to a separate core software. that is to say, it is an add-on utility to tweak something already set by "the dpkg alternatives system". ie: it's for "updating" only oh hey I've found a command reference in REDHAT. interestingly, they have a manpage that I guess is an alias for "update-alternatives". but the true command is called "alternatives". now that seems more appropriate to me. how about that? (the name, AND possibly the choice of software?) From rupert at opencsw.org Tue Dec 22 00:04:19 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 22 Dec 2009 00:04:19 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> <4B2E570A.3080708@opencsw.org> Message-ID: <6af4270912211504r43f65310t86e00fa22570716e@mail.gmail.com> On Mon, Dec 21, 2009 at 21:07, Philip Brown wrote: > btw as a reminder: while apache2 "can" use the bundled apr there are > some benefits to having it use a standalone external package > > it would be a very nice thing if we had one, and in fact there was > some package in recent months that needed one? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers i commented the tests for the moment, the test code does ipv6. From rupert at opencsw.org Tue Dec 22 00:11:15 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 22 Dec 2009 00:11:15 +0100 Subject: [csw-maintainers] rebuild kde? In-Reply-To: References: <6af4270912200845i2206834dmc3cf1dab710f034d@mail.gmail.com> <6af4270912200848h7ef0188sbeae96ba42e8967b@mail.gmail.com> <2B41EBA1-A944-4D7D-9304-3A126B5D167D@opencsw.org> Message-ID: <6af4270912211511k79b7bec8v7250faa72fa2510d@mail.gmail.com> On Mon, Dec 21, 2009 at 20:58, Philip Brown wrote: > On Sunday, December 20, 2009, Dagobert Michelsen wrote: >> Hi Rupert, > >> >> Just add the libs. Rebuilding KDE is a major task. >> > > it is indeed a major task... that being said, it would be a very very > good thing for opencsw if someone would take on this task could somebody make a short description what needs to be done, and even more basic, how to compile kde on the build farm? rupert. From skayser at opencsw.org Tue Dec 22 00:16:08 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Dec 2009 00:16:08 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: <6af4270912211504r43f65310t86e00fa22570716e@mail.gmail.com> References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> <4B2E570A.3080708@opencsw.org> <6af4270912211504r43f65310t86e00fa22570716e@mail.gmail.com> Message-ID: <4B3001B8.9060408@opencsw.org> Hi Rupert, rupert THURNER wrote on 22.12.2009 00:04: > On Mon, Dec 21, 2009 at 21:07, Philip Brown wrote: >> btw as a reminder: while apache2 "can" use the bundled apr there are >> some benefits to having it use a standalone external package >> >> it would be a very nice thing if we had one, and in fact there was >> some package in recent months that needed one? > > i commented the tests for the moment, the test code does ipv6. glad it helped! There was a similar problem with mbuffer, which also does IPv6 tests. Instead of completely disabling the test suite, it was possible to only skip the IPv6 test. This way one is still alerted (and I already was) if anything else goes wrong. Might be wise to take the same route for apr for future builds. Do any other tests fail right now? Sebastian From skayser at opencsw.org Tue Dec 22 00:22:35 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Dec 2009 00:22:35 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> References: <20091221152001.GH7667@sebastiankayser.de> <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> Message-ID: <4B30033B.6000404@opencsw.org> Dagobert Michelsen wrote on 21.12.2009 16:26: > Am 21.12.2009 um 16:20 schrieb Sebastian Kayser: >> * Maciej (Matchek) Blizinski wrote: >>> On Mon, Dec 21, 2009 at 3:11 PM, Dagobert Michelsen >>> wrote: >>>> Gary, I installed Perl 5.10.1 on build8st, would you mind giving >>>> clusterssh >>>> a try against the updated Perl? >>> It's not that, at least in this case. clusterssh doesn't contain any >>> shared objects, the package consists only of a perl script and a man >>> page: >>> >>> http://www.opencsw.org/search/clusterssh >> It relies on pm_tk which in turn is compiled against the previous perl >> version. We should set up some automated way of re-building all perl >> modules with shared objects files against the new perl. > > The easiest way would be to update cpan2pkg from CSWcswutils to output > GAR Makefile and then mass-update the modules. I won't have much time > over christmas as I won a Live Upgrade migration from U6 UFS to U8 ZFS > for an 8-machine Sun Ray cluster which will suck up most of my "spare" > time... Isn't this perfect training material for apprentices? ;) > Sebastian, would you mind giving it a look? My time is limited also (will be away most of the holidays), but I will have a look. IIRC I even spotted a full blown CPAN-to-build-description utility within another distro. Might well be suitable/adjustable for our purposes. What sort of time pressure do we have with the perl upgrade? Sebastian From rupert at opencsw.org Tue Dec 22 01:27:47 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 22 Dec 2009 01:27:47 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: <4B3001B8.9060408@opencsw.org> References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> <4B2E570A.3080708@opencsw.org> <6af4270912211504r43f65310t86e00fa22570716e@mail.gmail.com> <4B3001B8.9060408@opencsw.org> Message-ID: <6af4270912211627m3e49bc36mbf44ae6a2a4bcb52@mail.gmail.com> On Tue, Dec 22, 2009 at 00:16, Sebastian Kayser wrote: > Hi Rupert, > > rupert THURNER wrote on 22.12.2009 00:04: >> On Mon, Dec 21, 2009 at 21:07, Philip Brown wrote: >>> btw as a reminder: while apache2 "can" use the bundled apr there are >>> some benefits to having it use a standalone external package >>> >>> it would be a very nice thing if we had one, and in fact there was >>> some package in recent months that needed one? >> >> i commented the tests for the moment, the test code does ipv6. > > glad it helped! There was a similar problem with mbuffer, which also > does IPv6 tests. Instead of completely disabling the test suite, it was > possible to only skip the IPv6 test. This way one is still alerted (and > I already was) if anything else goes wrong. Might be wise to take the > same route for apr for future builds. Do any other tests fail right now? > no. i did not find any log file but looked into the code. i do not understand what they really try to do ... but i'd saythe test suite should not test things which are known not to work. the code contains: #if APR_HAVE_IPV6 static void tcp6_socket(abts_case *tc, void *data) and the config log says: configure:34230: checking if APR supports IPv6 configure:34232: result: yes rupert. From bwalton at opencsw.org Tue Dec 22 02:09:29 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 21 Dec 2009 20:09:29 -0500 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: <1261443838-sup-4882@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Dec 21 16:51:19 -0500 2009: > as release manager, I might like t know if anythng IMPORTANT has > changed. parsing all those entries is the antithesis of automaton. it > requires detailed human scrutiny, if the maintained has been writng > detailed change logs. This is a good point... Given the way svn works, I find myself committing things that in a decent VCS, I wouldn't, or, more often, committing a whole bunch of disjoint changes together, making the actual log messages somewhat less useful. Also, I can't correct commit messages if I make a typo, or squash commits together if I forget to update the checksums file after bumping versions, etc. Subversion promotes (or at least doesn't discourage) badness in this area. While I like the overall idea, I agree with Phil that this would become a polluted change log in a hurry. 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 skayser at opencsw.org Tue Dec 22 09:21:35 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Dec 2009 09:21:35 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: <6af4270912211627m3e49bc36mbf44ae6a2a4bcb52@mail.gmail.com> References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> <4B2E570A.3080708@opencsw.org> <6af4270912211504r43f65310t86e00fa22570716e@mail.gmail.com> <4B3001B8.9060408@opencsw.org> <6af4270912211627m3e49bc36mbf44ae6a2a4bcb52@mail.gmail.com> Message-ID: <4B30818F.7030809@opencsw.org> rupert THURNER wrote on 22.12.2009 01:27: > On Tue, Dec 22, 2009 at 00:16, Sebastian Kayser wrote: >> rupert THURNER wrote on 22.12.2009 00:04: >>> i commented the tests for the moment, the test code does ipv6. >> >> glad it helped! There was a similar problem with mbuffer, which also >> does IPv6 tests. Instead of completely disabling the test suite, it was >> possible to only skip the IPv6 test. This way one is still alerted (and >> I already was) if anything else goes wrong. Might be wise to take the >> same route for apr for future builds. Do any other tests fail right now? >> > no. i did not find any log file but looked into the code. i do not > understand what they really try to do ... but i'd saythe test suite > should not test things which are known not to work. Regarding the test suite: There is a bug report about the IPv6 testing problem [1] where the bug reporter would also like to see the IPv6 tests being skipped rather than failed for boxes without IPv6 interfaces. The apr guys take a different stance. Luckily, a configured IPv6 loopback interface is sufficient. @Buildfarm admins: would it be possible to configure IPv6 loopback interfaces for the buildfarm boxes? # ifconfig lo0 inet6 plumb # ifconfig lo0 inet6 ::1 up # touch /etc/hostname6.lo0 > the code contains: > #if APR_HAVE_IPV6 > static void tcp6_socket(abts_case *tc, void *data) > > and the config log says: > configure:34230: checking if APR supports IPv6 > configure:34232: result: yes That's something different. ./configure detects general IPv6 support in the OS and it's libraries and thus build apr with IPv6 support. It is perfectly fine to build apr with IPv6 support - even if the particular build box doesn't have a configured IPv6 interface. This way we end up with an apr package that our users can use, even when they are running it in a configured IPv6 environment. Sebastian [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=45494 From maciej at opencsw.org Tue Dec 22 11:25:52 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Dec 2009 10:25:52 +0000 Subject: [csw-maintainers] Undefined symbol __sync_fetch_and_add_4. In-Reply-To: <4AF6F0A4.60205@opencsw.org> References: <4AF6F0A4.60205@opencsw.org> Message-ID: 2009/11/8 Trygve Laugst?l : > I'm trying to build freehdl on build8s, but when it's linking the final > binary I'm getting an error about a missing symbol "__sync_fetch_and_add_4" > > This seems to be a function that use atomic instructions that's not on i386 > and sparc 8 so i686 has to be used. I assume the problem is similar on > sparc, but I have no idea which flags to use. Does anyone know? > > http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Atomic-Builtins.html#Atomic-Builtins I just saw the same problem: gmake[3]: Entering directory `/home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0' /bin/bash ./libtool --tag=CXX --mode=link /opt/csw/gcc4/bin/g++ -O2 -pipe -mcpu=v8 -L/opt/csw/gcc4/lib/. -mcpu=v8 -L/opt/csw/lib -o samples/sample1_unittest samples/sample1_unittest.o lib/libgtest_main.la samples/libsamples.la /opt/csw/gcc4/bin/g++ -O2 -pipe -mcpu=v8 -mcpu=v8 -o samples/.libs/sample1_unittest samples/sample1_unittest.o -L/opt/csw/gcc4/lib/. -L/opt/csw/lib lib/.libs/libgtest_main.so /home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0/lib/.libs/libgtest.so samples/.libs/libsamples.a /opt/csw/gcc4/lib/libstdc++.so -lm -Wl,-R -Wl,/opt/csw/lib -Wl,-R -Wl,/opt/csw/gcc4/lib ld: warning: file /opt/csw/gcc4/lib/./libstdc++.so: linked to /opt/csw/gcc4/lib/libstdc++.so: attempted multiple inclusion of file Undefined first referenced symbol in file __sync_fetch_and_add_4 /home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0/lib/.libs/libgtest.so ld: fatal: Symbol referencing errors. No output written to samples/.libs/sample1_unittest gmake[3]: *** [samples/sample1_unittest] Error 1 Have you solved it? Maciej From rupert at opencsw.org Tue Dec 22 11:30:24 2009 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 22 Dec 2009 11:30:24 +0100 Subject: [csw-maintainers] Undefined symbol __sync_fetch_and_add_4. In-Reply-To: References: <4AF6F0A4.60205@opencsw.org> Message-ID: <6af4270912220230p200ea3f5rb97ad33f76679b39@mail.gmail.com> On Tue, Dec 22, 2009 at 11:25, Maciej (Matchek) Blizinski wrote: > 2009/11/8 Trygve Laugst?l : >> I'm trying to build freehdl on build8s, but when it's linking the final >> binary I'm getting an error about a missing symbol "__sync_fetch_and_add_4" >> >> This seems to be a function that use atomic instructions that's not on i386 >> and sparc 8 so i686 has to be used. I assume the problem is similar on >> sparc, but I have no idea which flags to use. Does anyone know? >> >> http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Atomic-Builtins.html#Atomic-Builtins > > I just saw the same problem: > > gmake[3]: Entering directory > `/home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0' > /bin/bash ./libtool --tag=CXX ? --mode=link /opt/csw/gcc4/bin/g++ ?-O2 > -pipe -mcpu=v8 ?-L/opt/csw/gcc4/lib/. -mcpu=v8 -L/opt/csw/lib -o > samples/sample1_unittest samples/sample1_unittest.o > lib/libgtest_main.la samples/libsamples.la > /opt/csw/gcc4/bin/g++ -O2 -pipe -mcpu=v8 -mcpu=v8 -o > samples/.libs/sample1_unittest samples/sample1_unittest.o > -L/opt/csw/gcc4/lib/. -L/opt/csw/lib lib/.libs/libgtest_main.so > /home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0/lib/.libs/libgtest.so > samples/.libs/libsamples.a /opt/csw/gcc4/lib/libstdc++.so -lm ?-Wl,-R > -Wl,/opt/csw/lib -Wl,-R -Wl,/opt/csw/gcc4/lib > ld: warning: file /opt/csw/gcc4/lib/./libstdc++.so: linked to > /opt/csw/gcc4/lib/libstdc++.so: attempted multiple inclusion of file > Undefined ? ? ? ? ? ? ? ? ? ? ? first referenced > ?symbol ? ? ? ? ? ? ? ? ? ? ? ? ? ? in file > __sync_fetch_and_add_4 > /home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0/lib/.libs/libgtest.so > ld: fatal: Symbol referencing errors. No output written to > samples/.libs/sample1_unittest > gmake[3]: *** [samples/sample1_unittest] Error 1 > > Have you solved it? maybe use "-march=i486" as compiler flag? rupert. From maciej at opencsw.org Tue Dec 22 11:34:29 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Dec 2009 10:34:29 +0000 Subject: [csw-maintainers] Undefined symbol __sync_fetch_and_add_4. In-Reply-To: <6af4270912220230p200ea3f5rb97ad33f76679b39@mail.gmail.com> References: <4AF6F0A4.60205@opencsw.org> <6af4270912220230p200ea3f5rb97ad33f76679b39@mail.gmail.com> Message-ID: On Tue, Dec 22, 2009 at 10:30 AM, rupert THURNER wrote: > maybe use "-march=i486" as compiler flag? I saw these hints, but this is a sparc processor. From dam at opencsw.org Tue Dec 22 14:01:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Dec 2009 14:01:32 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: <85BE3575-4118-4A28-9D83-E6FCA34ACE15@opencsw.org> Hi Maciej, Am 21.12.2009 um 22:28 schrieb Maciej (Matchek) Blizinski: > In the future one might envision an > automated system in which the maintainer doesn't write an e-mail, but > simply states the decision "I want X to be submitted for release" and > the rest pf the process, up to the point when the release candidate > files are presented to the release manager, is automated. I think > that the rest of the crew has a similar vision, please chime in. Yes. +1 > Perhaps there could be a generated link associated with each piece of > software, showing the differences between the build files, such as: > http://tinyurl.com/ygvbh7v (A side note: this would be build-system > independent. The only requirement would be for the software in > question to point at the URL from which it was built and provide the > revision number.) Sounds promising. I am looking forwards to see this implemented. Best regards -- Dago From dam at opencsw.org Tue Dec 22 14:24:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Dec 2009 14:24:26 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: Hi, Am 21.12.2009 um 22:51 schrieb Philip Brown: > On Monday, December 21, 2009, Maciej (Matchek) Blizinski > wrote: >> On Mon, Dec 21, 2009 at 8:02 PM, Philip Brown >> wrote: >>> oh let's NOT include all svn messages please. >>> too much information potentially >> >> I'll first explain why I was thinking of including them. I'm aiming >> at automating all the bits that don't absolutely require human >> intervention. I assume that as the release manager, you would like >> to >> know what has changed since the last release. > > as release manager, I might like t know if anythng IMPORTANT has > changed. parsing all those entries is the antithesis of automaton. it > requires detailed human scrutiny, if the maintained has been writng > detailed change logs. > > perhaps it might be beneficial if the tool optionally displayed the > logs to the mantainer only. then they can determine if there is > anything important to pass on to the release manager? When we are talking about automation it may be useful to work towards automatic build: When someone makes a tag the comment to the tag may include the relevant message what has changed since the last tag only. Best regards -- Dago From dam at opencsw.org Tue Dec 22 14:27:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Dec 2009 14:27:19 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: <4B30033B.6000404@opencsw.org> References: <20091221152001.GH7667@sebastiankayser.de> <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> <4B30033B.6000404@opencsw.org> Message-ID: Hi Sebastian, Am 22.12.2009 um 00:22 schrieb Sebastian Kayser: >> Sebastian, would you mind giving it a look? > > My time is limited also (will be away most of the holidays), but I > will > have a look. IIRC I even spotted a full blown CPAN-to-build- > description > utility within another distro. Might well be suitable/adjustable for > our > purposes. What sort of time pressure do we have with the perl upgrade? Well, the Perl in current is broken to the point that some packages can't be compiled due to conflict in current vs. shipped MakeMaker. Perl 5.10.1 solves this, so timely shipping would certainly be good. BTW, the cpan2pkg script I mentioned is based on the script you cited, but already has all the stuff from CSW in it with the exception of producing packages instead of GAR Makefiles. Best regards -- Dago From dam at opencsw.org Tue Dec 22 15:50:16 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Dec 2009 15:50:16 +0100 Subject: [csw-maintainers] apr-1.3.9 - test failure ? In-Reply-To: <4B30818F.7030809@opencsw.org> References: <6af4270912191739n67f31117pd5b526dfbb163de3@mail.gmail.com> <4B2E570A.3080708@opencsw.org> <6af4270912211504r43f65310t86e00fa22570716e@mail.gmail.com> <4B3001B8.9060408@opencsw.org> <6af4270912211627m3e49bc36mbf44ae6a2a4bcb52@mail.gmail.com> <4B30818F.7030809@opencsw.org> Message-ID: <53850355-EA7E-4B2A-A23F-EEBBEA937ACB@opencsw.org> Hi Sebastian, Am 22.12.2009 um 09:21 schrieb Sebastian Kayser: > Regarding the test suite: There is a bug report about the IPv6 testing > problem [1] where the bug reporter would also like to see the IPv6 > tests > being skipped rather than failed for boxes without IPv6 interfaces. > The > apr guys take a different stance. > > Luckily, a configured IPv6 loopback interface is sufficient. > @Buildfarm > admins: would it be possible to configure IPv6 loopback interfaces for > the buildfarm boxes? > > # ifconfig lo0 inet6 plumb > # ifconfig lo0 inet6 ::1 up > # touch /etc/hostname6.lo0 Done on all build machines. Best regards -- Dago From dam at opencsw.org Tue Dec 22 16:01:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 Dec 2009 16:01:17 +0100 Subject: [csw-maintainers] Package naming of splitting of library-packages Message-ID: Hi, I am currently packaging up libcdio and libcddb. Both packages consist of some libraries and some binaries. The libraries are somewhat self-contained and do not depend on each other while the binaries of both packages require each their and the other library. The upstream author recommended splitting up the library from the binaries. In terms of OpenCSW that would mean having two build recipes libcddbrt libcdiort which produce the CSWlibcddbrt and CSWlibcdiort packages. Then two other build descriptions libcddb libcdio will produce CSWlibcddb and CSWlibcdio containing the binaries. Now the question: library-packages usually don't have runtime-subpackages, but in this case it would IMHO be useful. Thoughts? Phil? Best regards -- Dago From maciej at opencsw.org Tue Dec 22 16:15:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Dec 2009 15:15:46 +0000 Subject: [csw-maintainers] Package naming of splitting of library-packages In-Reply-To: References: Message-ID: On Tue, Dec 22, 2009 at 3:01 PM, Dagobert Michelsen wrote: > Now the question: library-packages usually don't have > runtime-subpackages, but in this case it would IMHO be > useful. Thoughts? Phil? The solutions I've seen in other places were to create a *-tools optional package with the binaries. For example, Debian has libnss3 with the libraries and libnss3-tools with the binaries. In the case of libcddb it would make something along the lines of: CSWlibcddb CSWlibcddb-tools Maciej From phil at bolthole.com Tue Dec 22 16:35:48 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 22 Dec 2009 07:35:48 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> Message-ID: On Monday, December 21, 2009, Gary Law wrote: > ... > 1) Use CSWcswclassutils and stop those with read-only /usr using our packages; > > Primary problem with (1) is it rules out using CSW packages on a > significant number of machines which have read-only /usr. I'd call > that a major issue, a showstopper bug in the case of the package I'm > trying to get into GAR. > I'd say that you are overestimating this "significant number". nor is it usually a "showstopper" First of all, most places that have "read only usr" still have mechanisms for needed updates. Secondly, there are direct workarounds even for difficult cases, as I have pointed out. Thirdly, there are sometimes Indirect workarounds. for example, Rupert has found a workarounds in his situation I believe. lastly; this is not our Only deployment into /usr. We deploy under /opt/csw , except when the nature of solaris requires us to deploy in a specific location elsewhere. For example, our dtlogin integration packages, which deploy under /usr/dt From phil at bolthole.com Tue Dec 22 16:42:26 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 22 Dec 2009 07:42:26 -0800 Subject: [csw-maintainers] rebuild kde? In-Reply-To: <6af4270912211511k79b7bec8v7250faa72fa2510d@mail.gmail.com> References: <6af4270912200845i2206834dmc3cf1dab710f034d@mail.gmail.com> <6af4270912200848h7ef0188sbeae96ba42e8967b@mail.gmail.com> <2B41EBA1-A944-4D7D-9304-3A126B5D167D@opencsw.org> <6af4270912211511k79b7bec8v7250faa72fa2510d@mail.gmail.com> Message-ID: unfortunately it is a very multilayer process. 21 packages not counting the i18n packages. one way to handle this might be to build a "dry run" set of packages on one of our test machines. (you get root that way so can install test packages yourself) once you have a working proceedure then do it "for real". On Monday, December 21, 2009, rupert THURNER wrote: > On Mon, Dec 21, 2009 at 20:58, Philip Brown wrote: >> On Sunday, December 20, 2009, Dagobert Michelsen wrote: >>> Hi Rupert, >> >>> >>> Just add the libs. Rebuilding KDE is a major task. >>> >> >> it is indeed a major task... that being said, it would be a very very >> good thing for opencsw if someone would take on this task > > could somebody make a short description what needs to be done, and > even more basic, how to compile kde on the build farm? > > rupert. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > From james at opencsw.org Tue Dec 22 17:05:13 2009 From: james at opencsw.org (James Lee) Date: Tue, 22 Dec 2009 16:05:13 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> Message-ID: <20091222.16051300.3754394574@gyor.oxdrove.co.uk> On 22/12/09, 15:35:48, Philip Brown wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > We deploy under /opt/csw , except when the nature of solaris requires > us to deploy in a specific location elsewhere. For example, our > dtlogin integration packages, which deploy under /usr/dt /etc/dt can be used and most CSW dtlogins do. CSWicewm is the only one that does not, bug report: http://www.opencsw.org/bugtrack/view.php?id=1120 Other (ab)users of /usr/... CSWdialog (REV=2003.03.18) and CSWsambawb (REV=2006.08.09b) are old and have pending bug reports. CSWpmmailspf, updates existing /usr/ directories, bug report: http://www.opencsw.org/bugtrack/view.php?id=4079 CSWtun, CSWtop and CSWdosexec are drivers and write to /usr/kernal. Leaving only CSWclassutils. From bwalton at opencsw.org Tue Dec 22 17:38:53 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 22 Dec 2009 11:38:53 -0500 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091222.16051300.3754394574@gyor.oxdrove.co.uk> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> Message-ID: <1261499782-sup-5582@ntdws12.chass.utoronto.ca> Excerpts from James Lee's message of Tue Dec 22 11:05:13 -0500 2009: > Other (ab)users of /usr/... What about things like CSWexim, and presumably CSWpostfix that might move /usr/lib/sendmail out of the way as part of the postinstall. CSWexim uses a prompt to handle this and has allows you to skip it. I don't know about CSWpostfix and I don't use it. This is a somewhat different case, since it's the postinstall script, but there is still potential for 'partially installed' status here. -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 Tue Dec 22 17:40:56 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 22 Dec 2009 11:40:56 -0500 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: <20091221152001.GH7667@sebastiankayser.de> <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> <4B30033B.6000404@opencsw.org> Message-ID: <1261499988-sup-5699@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Dec 22 08:27:19 -0500 2009: > BTW, the cpan2pkg script I mentioned is based on the script you cited, > but already has all the stuff from CSW in it with the exception of > producing packages instead of GAR Makefiles. The GAR support for quickly building a CPAN module is quite good too though. Updating any of the pm_* packages should be trivial if they're already in GAR and near-so[1] if not. -Ben [1] Barring any solaris specific issues that have popped up in newer versions. -- 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 james at opencsw.org Tue Dec 22 18:09:08 2009 From: james at opencsw.org (James Lee) Date: Tue, 22 Dec 2009 17:09:08 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <1261499782-sup-5582@ntdws12.chass.utoronto.ca> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> Message-ID: <20091222.17090800.2208031977@gyor.oxdrove.co.uk> On 22/12/09, 16:38:53, Ben Walton wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > What about things like CSWexim, and presumably CSWpostfix that might > move /usr/lib/sendmail out of the way as part of the postinstall. > CSWexim uses a prompt to handle this and has allows you to skip it. They might but needn't and maybe shouldn't. My exim works with /usr/sendmail in place although it needs manual "svcadm disable sendmail" to get access to port 25. A reason not to move system files might be that system patches can't work. e.g. If you move sendmail, patch it, move it back you have an unpatched sendmail (or maybe an error in the patch process, not sure, I've never actually done it). James. From maciej at opencsw.org Tue Dec 22 18:14:23 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Dec 2009 17:14:23 +0000 Subject: [csw-maintainers] CSWpython-rt is now deprecated Message-ID: Executive summary: CSWpython-rt is deprecated, please re-point your dependencies at CSWpython. The upcoming release of Python (2.6.4) has a change related to packaging. The CSWpython-rt package is now an empty, deprecated package. It used to contain shared objects from Python. It was a confusing package, because it made the impression that it's enough for other Python-dependent packages to only depend on CSWpython-rt. In fact, in all the cases, the whole Python package is necessary. It was necessary to declare dependencies to both CSWpython and CSWpython-rt, even though CSWpython required CSWpython-rt, so there was redundancy involved. In python-2.6.4, all the shared objects are in the CSWpython package. Bugs will be filed against all the dependent projects to remove the dependency on CSWpython-rt. When all the dependencies are removed, the -rt package will be removed too. If there is a package which does depend on CSWpython-rt but doesn't depend on CSWpython, it can get into trouble if CSWpython happens to be uninstalled. The potentially affected packages are: pymysql pysqlite ooocore trac silvercity pysqlite2 genshi graphvizpython I think that in the case of most these packages it's dead obvious that CSWpython is necessary, since they're Python libraries. The package that may be the most affected here is ooocore. Maciej From phil at bolthole.com Tue Dec 22 18:15:30 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 22 Dec 2009 09:15:30 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091222.17090800.2208031977@gyor.oxdrove.co.uk> References: <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> Message-ID: I was just reminded of something that I hadn't mentioned much on the list before now. When I first came up with the idea of us using class action scripts, I had always thought that it would be beneficial to also provide some utils to run needful things manually (primarily for the case of nfs shared /opt/csw) Before now, this has not been seen as important. But now would seem to be a good time to bring this up again :) if we provide an alternative CSWcswclassutils package, whose function is, "go run actions that normally get done at pkgadd time", then we could cover the very small amount of people who are "blocked" by our regular version of the package deploying to /usr. This would be an ALTERNATIVE to our regular ?package, rather than replacing it. the major changes required would be: 1 making sure all cswclassutils input files are homed under /opt/csw instead of /etc 2 providing an alternative implementation script, for each of our class actions in use. ( and possibly 3: providing some sort of automated hook for scanning for "new" packages that haven't had their class actions run for them ) From james at opencsw.org Tue Dec 22 18:43:58 2009 From: james at opencsw.org (James Lee) Date: Tue, 22 Dec 2009 17:43:58 GMT Subject: [csw-maintainers] CSWpython-rt is now deprecated In-Reply-To: References: Message-ID: <20091222.17435800.1351067935@gyor.oxdrove.co.uk> On 22/12/09, 17:14:23, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] CSWpython-rt is now deprecated: > Executive summary: CSWpython-rt is deprecated, please re-point your > dependencies at CSWpython. ... > In python-2.6.4, all the shared objects are in the CSWpython package. > Bugs will be filed against all the dependent projects to remove the > dependency on CSWpython-rt. I presume you have made CSWpython-rt depend on CSWpython so there is no urgency to the change. James. From bwalton at opencsw.org Tue Dec 22 19:10:13 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 22 Dec 2009 13:10:13 -0500 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091222.17090800.2208031977@gyor.oxdrove.co.uk> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> Message-ID: <1261505240-sup-8636@ntdws12.chass.utoronto.ca> Excerpts from James Lee's message of Tue Dec 22 12:09:08 -0500 2009: > They might but needn't and maybe shouldn't. My exim works with > /usr/sendmail in place although it needs manual "svcadm disable > sendmail" to get access to port 25. That's all well and good until something wants to inject mail via /usr/lib/sendmail. At that point, it's fairly important to have /usr/lib/sendmail be the CSW file and not the SUNW one. Replacing mailq and aliases is also useful (creature comfort-wise) but not essential. I'd actually consider CSWexim broken if it didn't at least offer to make the switch. > A reason not to move system files might be that system patches can't > work. e.g. If you move sendmail, patch it, move it back you have an > unpatched sendmail (or maybe an error in the patch process, not > sure, I've never actually done it). I have cfengine was this file and ensure it stays 'right.' Patching will trample it unless your provide the correct admin files or options, etc. It's a pita, but a small price to pay to be rid of sendmail. -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 Dec 22 19:30:05 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Dec 2009 18:30:05 +0000 Subject: [csw-maintainers] CSWpython-rt is now deprecated In-Reply-To: <20091222.17435800.1351067935@gyor.oxdrove.co.uk> References: <20091222.17435800.1351067935@gyor.oxdrove.co.uk> Message-ID: On Tue, Dec 22, 2009 at 5:43 PM, James Lee wrote: > I presume you have made CSWpython-rt depend on CSWpython so there is > no urgency to the change. I haven't made CSWpython-rt depend on CSWpython initially, but I've followed this suggestion and I've sent the updated CSWpython-rt to Phil. From maciej at opencsw.org Tue Dec 22 21:18:51 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 22 Dec 2009 20:18:51 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: On Tue, Dec 22, 2009 at 1:24 PM, Dagobert Michelsen wrote: > When we are talking about automation it may be useful to work towards > automatic build: When someone makes a tag the comment to the tag may > include the relevant message what has changed since the last tag only. I tend to disagree with the tagging idea. Tags are good when you want to preserve a version of the build before making major changes. You can argue that tags are good for marking certain revisions of interest, and package releases could count. But it strikes me as a model which doesn't take into account other factors playing role in how we work with subversion. There are two main problems with it. One is that we don't have the habit of using tags and I don't think we'll acquire it unless it's mandatory. If you make it mandatory, it will be annoying to people and will do more harm than good. If it won't be mandatory, nobody will use it, because it will make no benefit to the maintainer. The second problem is that if we start tagging every release, our source repository will quickly become so crowded, that doing a checkout of the gar/pkg directory will take forever. You can even try to estimate the time based on current checkout speed and the projected number of files after, say, a year. I really like the current setup in which the package has an embedded information about the subversion path from which it was built, and the revision number. You don't need more. If you have this information, you can work out which release was built from which revision. If we want something faster than downloading and dissecting a package, we can cache this information in a database. I think we can achieve the same functionality (automated builds) in a more transparent, non-intrusive way. Maciej From glaw at opencsw.org Tue Dec 22 23:28:35 2009 From: glaw at opencsw.org (Gary Law) Date: Tue, 22 Dec 2009 22:28:35 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> Message-ID: Hi all What a can of worms I've opened, sorry... anyway... 2009/12/22 Philip Brown : > I was just reminded of something that I hadn't mentioned much on the > list before now. > > When I first came up with the idea of us using class action scripts, I > had always thought that it would be beneficial to also provide some > utils to run needful things manually (primarily for the case of nfs > shared /opt/csw) I have to say the number of installations with shared nfs /opt/csw would -- I guess -- be far fewer than the number with zones with read only /usr. > Before now, this has not been seen as important. But now would seem to > be a good time to bring this up again :) > > if we provide an alternative CSWcswclassutils package, whose function > is, "go run actions that normally get done at pkgadd time", then we > could cover the very small amount of people who are "blocked" by our > regular version of the package deploying to /usr. > > This would be an ALTERNATIVE to our regular ?package, rather than replacing it. That gets my vote if there's a way to handle the dependencies. Gary -- glaw at opencsw.org From glaw at opencsw.org Tue Dec 22 23:30:36 2009 From: glaw at opencsw.org (Gary Law) Date: Tue, 22 Dec 2009 22:30:36 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091222.17090800.2208031977@gyor.oxdrove.co.uk> References: <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> Message-ID: 2009/12/22 James Lee : > On 22/12/09, 16:38:53, Ben Walton wrote regarding Re: > [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > >> What about things like CSWexim, and presumably CSWpostfix that might >> move /usr/lib/sendmail out of the way as part of the postinstall. >> CSWexim uses a prompt to handle this and has allows you to skip it. > > They might but needn't and maybe shouldn't. +1 -- glaw at opencsw.org From skayser at opencsw.org Tue Dec 22 23:36:41 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 22 Dec 2009 23:36:41 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> Message-ID: <4B3149F9.5060109@opencsw.org> Gary Law wrote on 22.12.2009 23:30: > 2009/12/22 James Lee : >> On 22/12/09, 16:38:53, Ben Walton wrote regarding Re: >> [csw-maintainers] CSWcswclassutils: it wants to write in /usr: >> >>> What about things like CSWexim, and presumably CSWpostfix that might >>> move /usr/lib/sendmail out of the way as part of the postinstall. >>> CSWexim uses a prompt to handle this and has allows you to skip it. >> They might but needn't and maybe shouldn't. > > +1 What's the alternative then? Don't do anything, put instructions in README.CSW and let the user do whatever he wants/needs to do? Sebastian From james at opencsw.org Wed Dec 23 10:28:39 2009 From: james at opencsw.org (James Lee) Date: Wed, 23 Dec 2009 09:28:39 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <1261505240-sup-8636@ntdws12.chass.utoronto.ca> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> <1261505240-sup-8636@ntdws12.chass.utoronto.ca> Message-ID: <20091223.9283900.1782552105@gyor.oxdrove.co.uk> On 22/12/09, 18:10:13, Ben Walton wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > > They might but needn't and maybe shouldn't. My exim works with > > /usr/sendmail in place although it needs manual "svcadm disable > > sendmail" to get access to port 25. > That's all well and good until something wants to inject mail via > /usr/lib/sendmail. At that point, it's fairly important to have > /usr/lib/sendmail be the CSW file and not the SUNW one. Replacing > mailq and aliases is also useful (creature comfort-wise) but not > essential. I'd actually consider CSWexim broken if it didn't at least > offer to make the switch. I'd consider anything that directly used /usr/lib/sendmail to be broken and I realise that includes system functions like cron output. However, it does work, this gets to my normal IMAP account on another zone/machine with exim but using sendmail as the first local hop: $ echo "hello me" | mailx -s "test" $USER It's not important to me because sendmail does work. The reason I use exim is because I want to do more than just deliver locally generated mail and exim is easier to configure and do the advanced things like use SQL for routing variables. It would be best if mailx etc. were more aware, eg, the system looked for "mailhost" in the hosts list and used SMTP (analogous to loghost and syslog). James. From glaw at opencsw.org Wed Dec 23 11:24:10 2009 From: glaw at opencsw.org (Gary Law) Date: Wed, 23 Dec 2009 10:24:10 +0000 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <4B3149F9.5060109@opencsw.org> References: <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> <4B3149F9.5060109@opencsw.org> Message-ID: 2009/12/22 Sebastian Kayser : >>>> What about things like CSWexim, and presumably CSWpostfix that might >>>> move /usr/lib/sendmail out of the way as part of the postinstall. >>>> CSWexim uses a prompt to handle this and has allows you to skip it. >>> They might but needn't and maybe shouldn't. >> >> +1 > > What's the alternative then? Don't do anything, put instructions in > README.CSW and let the user do whatever he wants/needs to do? I would really not expect a CSW install to move, delete or link things that are already in /usr/lib. Especially something as core to many admins assumptions as sendmail. It just doesn't follow the 'least surprise' approach, never mind the 'nothing in /usr' policy. What if I have a working sendmail setup I'm happy with, but want to test CSW sendmail or exim or postfix? I'd be very unhappy if something came along and blatted default sendmail. Perhaps I'm in a minority of one on this. As for alternatives, a big fat message echoing to the console on install would be handy, and the documentation you suggest explaining why the link might be needed in some cases, but I don't think it should be automatically created. There's perhaps a case for creating the link if /usr/lib doesn't already have a sendmail in it, but I'd prefer it didn't*. Gary * And of course the link could point to the newly proposed alternative selection mechanism, for those crazy admins who want the full selection of available CSW MTAs installed. -- glaw at opencsw.org From bwalton at opencsw.org Wed Dec 23 13:40:11 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Dec 2009 07:40:11 -0500 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <20091223.9283900.1782552105@gyor.oxdrove.co.uk> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> <1261505240-sup-8636@ntdws12.chass.utoronto.ca> <20091223.9283900.1782552105@gyor.oxdrove.co.uk> Message-ID: <1261571233-sup-6117@ntdws12.chass.utoronto.ca> Excerpts from James Lee's message of Wed Dec 23 04:28:39 -0500 2009: > I'd consider anything that directly used /usr/lib/sendmail to be > broken and I realise that includes system functions like cron > output. Yes, but we've got a _lot_ of years of history here that aren't about to be corrected any time soon. exim and postfix emulate sendmail options for a reason. This isn't an issue on solaris only, either. It extends to any *nix I've encountered, although we now typically look for sendmail in /usr/bin elsewhere. > However, it does work, this gets to my normal IMAP account on another > zone/machine with exim but using sendmail as the first local hop: ...but this is only by chance, and is site/setup dependent. What if you only allow relay internally using LMTP or submission(587) w/tls? Your setup would then fail unless you also maintained a separate sendmail config...at which point, why replace it in the first place? It's fragile at best. > It's not important to me because sendmail does work. The reason I > use exim is because I want to do more than just deliver locally > generated mail and exim is easier to configure and do the advanced > things like use SQL for routing variables. I use it for the same reasons. > It would be best if mailx etc. were more aware, eg, the system looked > for "mailhost" in the hosts list and used SMTP (analogous to loghost > and syslog). Without something like this, there is a lot of opportunity for mail policy problems. Say you need all mail routed out via a designated relay machine, or qualified with your $tld. The default sendmail config will talk directly to the world and doesn't do 'good things' with qualification of local addresses without a bit of hand holding. You now need to maintain a separate sendmail.cf to match what you're doing with the exim config. Somewhat self defeating. The other thing to consider with a setup like this, straddling two mailers, is that you've now got two queues and if sendmail isn't active, you'd need to push it's queue manually in the event that there are hiccups on the initial delivery. Two mailers is just plain broken. A bug, if you will. -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 Wed Dec 23 13:46:39 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Dec 2009 07:46:39 -0500 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> <4B3149F9.5060109@opencsw.org> Message-ID: <1261572054-sup-10@ntdws12.chass.utoronto.ca> Excerpts from Gary Law's message of Wed Dec 23 05:24:10 -0500 2009: > I would really not expect a CSW install to move, delete or link things > that are already in /usr/lib. Especially something as core to many > admins assumptions as sendmail. It just doesn't follow the 'least > surprise' approach, never mind the 'nothing in /usr' policy. What if I > have a working sendmail setup I'm happy with, but want to test CSW > sendmail or exim or postfix? I'd be very unhappy if something came > along and blatted default sendmail. Yes, and in this case, CSWexim (and CSWpostfix?) does the right thing. It's an interactive (which sucks for jumpstart/automation) postinstall script, giving you the choice. You can leave the sendmail binaries in place or replace them, at your choosing. > As for alternatives, a big fat message echoing to the console on > install would be handy, and the documentation you suggest explaining > why the link might be needed in some cases, but I don't think it > should be automatically created. There's perhaps a case for creating It's not automatically created. You need to select the right option in the postinstall and can certainly opt to leave it alone. The bigger picture here is that no matter how superior the CSW packages are (CSWsendmail included), we're still trespassing on the system. Solaris doesn't provide the functionality to transparently replace important system functions like the mailer. I used to leverage the RHEL alternatives system to redirect mail functions to use exim until I modified our kickstart to omit sendmail and provide only exim. Unfortunately, we can't do that here since the solaris side of things would remain ignorant of the feature. -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 Dec 23 15:39:08 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 23 Dec 2009 15:39:08 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <1261499782-sup-5582@ntdws12.chass.utoronto.ca> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 22.12.2009 um 17:38 schrieb Ben Walton: > Excerpts from James Lee's message of Tue Dec 22 11:05:13 -0500 2009: > >> Other (ab)users of /usr/... > > What about things like CSWexim, and presumably CSWpostfix that might > move /usr/lib/sendmail out of the way as part of the postinstall. > CSWexim uses a prompt to handle this and has allows you to skip it. I > don't know about CSWpostfix and I don't use it. > > This is a somewhat different case, since it's the postinstall script, > but there is still potential for 'partially installed' status here. As we already talked about it the best solution is to have a separate "Sun Functionality Replacement Package" in a different catalog which is incompatible with the Sun package and doesn't break "install-all". Best regards -- Dago From dam at opencsw.org Wed Dec 23 15:40:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 23 Dec 2009 15:40:19 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: <1261499988-sup-5699@ntdws12.chass.utoronto.ca> References: <20091221152001.GH7667@sebastiankayser.de> <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> <4B30033B.6000404@opencsw.org> <1261499988-sup-5699@ntdws12.chass.utoronto.ca> Message-ID: <53CA2294-0E21-4B25-9970-D528D61D6FA9@opencsw.org> Hi Ben, Am 22.12.2009 um 17:40 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Tue Dec 22 08:27:19 > -0500 2009: > >> BTW, the cpan2pkg script I mentioned is based on the script you >> cited, >> but already has all the stuff from CSW in it with the exception of >> producing packages instead of GAR Makefiles. > > The GAR support for quickly building a CPAN module is quite good too > though. Updating any of the pm_* packages should be trivial if > they're already in GAR and near-so[1] if not. Manually updating a package with GAR takes about 10 minutes whereas a package update with a modified cpan2pkg will most certainly take about 1 minute. As we have 100+ package to update this is something. Best regards -- Dago From bwalton at opencsw.org Wed Dec 23 15:55:00 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Dec 2009 09:55:00 -0500 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: <53CA2294-0E21-4B25-9970-D528D61D6FA9@opencsw.org> References: <20091221152001.GH7667@sebastiankayser.de> <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> <4B30033B.6000404@opencsw.org> <1261499988-sup-5699@ntdws12.chass.utoronto.ca> <53CA2294-0E21-4B25-9970-D528D61D6FA9@opencsw.org> Message-ID: <1261579955-sup-6008@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Dec 23 09:40:19 -0500 2009: > Manually updating a package with GAR takes about 10 minutes whereas > a package update with a modified cpan2pkg will most certainly take > about 1 minute. As we have 100+ package to update this is something. Ok. I didn't realize there was that much difference in time required. When you count 100+ though, I assume you're counting all pm_* packages. This breakage only affects modules that provide .so files correct? That would make the number much less, most likely[1]. I'm not advocating either way here, I just thought that GAR was a good option for this too. Thanks -Ben [1] No, I haven't looked at package contents. -- 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 Wed Dec 23 16:12:38 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Dec 2009 10:12:38 -0500 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> Message-ID: <1261581091-sup-9562@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Dec 23 09:39:08 -0500 2009: > As we already talked about it the best solution is to have a separate > "Sun Functionality Replacement Package" in a different catalog which > is incompatible with the Sun package and doesn't break > "install-all". Ah yes, I'd forgotten about the cups discussion. Hoops++. :) -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 Dec 23 18:10:44 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Dec 2009 17:10:44 +0000 Subject: [csw-maintainers] Determining shared object dependencies Message-ID: Let's suppose there's a shared object which depends on libstdc++.so.6. I'd like to determine its dependencies. Unfortunately, libstdc++.so.6 exists in more than one place in the filesystem: maciej at build8s [build8s]:~ > ls -l /opt/csw/{,gcc4/}lib/libstdc++.so.6 lrwxrwxrwx 1 root other 19 May 11 2009 /opt/csw/gcc4/lib/libstdc++.so.6 -> libstdc++.so.6.0.10 lrwxrwxrwx 1 root other 20 Aug 7 11:50 /opt/csw/lib/libstdc++.so.6 -> ./libstdc++.so.6.0.3 How am I supposed to tell which one is the right one? (Without trussing the running program, of course.) The best idea I have is looking at the RUNPATH property of the library and assuming that the first one is the right one. For example, if the RUNPATH was ['/opt/csw/gcc4/lib', '/opt/csw/lib/$ISALIST', '/opt/csw/lib', '/opt/csw/lib', '/opt/csw/lib/svn'], I would assume that /opt/csw/gcc4/lib/libstdc++.so.6 is the right one, because '/opt/csw/gcc4/lib' appears first on the RUNPATH list. Do you this this is a reliable method? From maciej at opencsw.org Wed Dec 23 18:16:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 23 Dec 2009 17:16:13 +0000 Subject: [csw-maintainers] Determining shared object dependencies In-Reply-To: References: Message-ID: I think my previous e-mail lacked a clarification of what is the task about. It's about mapping from a list of SONAMEs to a list of corresponding files on the filesystem. (Which will be later mapped to the list of installed packages.) From phil at bolthole.com Wed Dec 23 18:47:39 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Dec 2009 09:47:39 -0800 Subject: [csw-maintainers] Determining shared object dependencies In-Reply-To: References: Message-ID: On Wed, Dec 23, 2009 at 9:10 AM, Maciej (Matchek) Blizinski wrote: > Let's suppose there's a shared object which depends on libstdc++.so.6. > ?I'd like to determine its dependencies. ?Unfortunately, > libstdc++.so.6 exists in more than one place in the filesystem: > > maciej at build8s [build8s]:~ > ls -l /opt/csw/{,gcc4/}lib/libstdc++.so.6 > lrwxrwxrwx ? 1 root ? ? other ? ? ? ? 19 May 11 ?2009 > /opt/csw/gcc4/lib/libstdc++.so.6 -> libstdc++.so.6.0.10 > lrwxrwxrwx ? 1 root ? ? other ? ? ? ? 20 Aug ?7 11:50 > /opt/csw/lib/libstdc++.so.6 -> ./libstdc++.so.6.0.3 > > How am I supposed to tell which one is the right one? ?(Without > trussing the running program, of course.) ?The best idea I have is > looking at the RUNPATH property of the library and assuming that the > first one is the right one. ?For example, if the RUNPATH was > ['/opt/csw/gcc4/lib', '/opt/csw/lib/$ISALIST', '/opt/csw/lib', > '/opt/csw/lib', '/opt/csw/lib/svn'], I would assume that > /opt/csw/gcc4/lib/libstdc++.so.6 is the right one, because > '/opt/csw/gcc4/lib' appears first on the RUNPATH list. > > Do you this this is a reliable method? It is in theory what will actually get loaded at runtime. so yes :-) From phil at bolthole.com Wed Dec 23 18:57:37 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 23 Dec 2009 09:57:37 -0800 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: References: <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> Message-ID: On Tue, Dec 22, 2009 at 2:28 PM, Gary Law wrote: > > I have to say the number of installations with shared nfs /opt/csw > would -- I guess -- be far fewer than the number with zones with read > only /usr. The problem set isnt "all zones that have read only /usr". The problem set is "all zones that have read only /usr, AND the sysadmin is unwilling/unable to update it". Which is a much smaller set. I would guess comparable in size to the "nfs shared, or otherwise replicated /opt/csw". Rupert, for one, counts as a thousand installs of the "otherwise replicated /opt/csw" case ;-) But anyways, moving on to some implementation details... >> if we provide an alternative CSWcswclassutils package, whose function >> is, "go run actions that normally get done at pkgadd time", then we >> could cover the very small amount of people who are "blocked" by our >> regular version of the package deploying to /usr. >> >> This would be an ALTERNATIVE to our regular ?package, rather than replacing it. > > That gets my vote if there's a way to handle the dependencies. sure, no problem. The "alternative" package, would be outside the regular catalog, but have the exact same name. So things would work as follows: regular catalog offers CSWcswclassutils, REV=2009.12.23 "alternative" download url/catalog, offers the "alternative workaround" package, that is ALSO NAMED, "CSWcswclassutils, REV=2009.12.23". Neither pkg-get nor pkgutil do any fancy checks about point of origin, of an already installed package. So, installing "lftp", the util would say to itself, "Hmm. this program need CSWcswclassutils. My catalog says I need REV=2009.12.23 of that. Checking current installed version.... version number matches. Ok, moving on..." no problem. We just need to keep updates of cswclassutils infrequent, to avoid inconveniencing the manual updaters. From bwalton at opencsw.org Thu Dec 24 00:18:55 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 23 Dec 2009 18:18:55 -0500 Subject: [csw-maintainers] Determining shared object dependencies In-Reply-To: References: Message-ID: <1261610257-sup-6818@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Dec 23 12:47:39 -0500 2009: > It is in theory what will actually get loaded at runtime. so yes :-) Alternately, you could compare the NEEDED (soname) items from dump with the output from ldd. Not perfect, but the resolution is handled there. The only trick is that ldd will resolve things recursively, so you need to know what you're after 'up front.' 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 james at opencsw.org Thu Dec 24 11:23:52 2009 From: james at opencsw.org (James Lee) Date: Thu, 24 Dec 2009 10:23:52 GMT Subject: [csw-maintainers] Determining shared object dependencies In-Reply-To: References: Message-ID: <20091224.10235200.1408762620@gyor.oxdrove.co.uk> On 23/12/09, 17:10:44, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] Determining shared object dependencies: > Let's suppose there's a shared object which depends on libstdc++.so.6. > I'd like to determine its dependencies. Unfortunately, > libstdc++.so.6 exists in more than one place in the filesystem: > maciej at build8s [build8s]:~ > ls -l /opt/csw/{,gcc4/}lib/libstdc++.so.6 > lrwxrwxrwx 1 root other 19 May 11 2009 > /opt/csw/gcc4/lib/libstdc++.so.6 -> libstdc++.so.6.0.10 > lrwxrwxrwx 1 root other 20 Aug 7 11:50 > /opt/csw/lib/libstdc++.so.6 -> ./libstdc++.so.6.0.3 > How am I supposed to tell which one is the right one? The one that was used to build it. /opt/csw/lib/libstdc++.so.6 comes with gcc3 /opt/csw/gcc4/lib/libstdc++.so.6.0.10 come with gcc4 ldd shows which will be used and served with a side dish of -s explains why. The one that will be used isn't always right due to changes/bugs in gcc4. Compare this output from 2 different installations: $ ldd /opt/csw/bin/aspell libaspell.so.15 => /opt/csw/lib/libaspell.so.15 libcurses.so.1 => /lib/libcurses.so.1 libdl.so.1 => /lib/libdl.so.1 libstdc++.so.6 => /opt/csw/gcc4/lib/libstdc++.so.6 libintl.so.3 => /opt/csw/lib/libintl.so.3 libiconv.so.2 => /opt/csw/lib/libiconv.so.2 libm.so.1 => /lib/libm.so.1 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1 libgcc_s.so.1 (GCC_4.3.0) => (version not found) libm.so.2 => /lib/libm.so.2 /platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1 $ ldd /opt/csw/bin/aspell libaspell.so.15 => /opt/csw/lib/libaspell.so.15 libcurses.so.1 => /usr/lib/libcurses.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libstdc++.so.6 => /opt/csw/lib/libstdc++.so.6 libintl.so.3 => /opt/csw/lib/libintl.so.3 libiconv.so.2 => /opt/csw/lib/libiconv.so.2 libm.so.1 => /usr/lib/libm.so.1 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1 /usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1 Ref: http://www.opencsw.org/bugtrack/view.php?id=4040 From rupert at opencsw.org Thu Dec 24 11:24:23 2009 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 24 Dec 2009 11:24:23 +0100 Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <4B3149F9.5060109@opencsw.org> References: <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> <4B3149F9.5060109@opencsw.org> Message-ID: <6af4270912240224m64ca038cld50c05b7b83929bd@mail.gmail.com> On Tue, Dec 22, 2009 at 23:36, Sebastian Kayser wrote: > Gary Law wrote on 22.12.2009 23:30: >> 2009/12/22 James Lee : >>> On 22/12/09, 16:38:53, Ben Walton wrote regarding Re: >>> [csw-maintainers] CSWcswclassutils: it wants to write in /usr: >>> >>>> What about things like CSWexim, and presumably CSWpostfix that might >>>> move /usr/lib/sendmail out of the way as part of the postinstall. >>>> CSWexim uses a prompt to handle this and has allows you to skip it. >>> They might but needn't and maybe shouldn't. >> >> +1 > > What's the alternative then? Don't do anything, put instructions in > README.CSW and let the user do whatever he wants/needs to do? that would be fine. or provide an "enable" script like debian apache does for enabling sites? rupert. From james at opencsw.org Thu Dec 24 11:27:34 2009 From: james at opencsw.org (James Lee) Date: Thu, 24 Dec 2009 10:27:34 GMT Subject: [csw-maintainers] CSWpython-rt is now deprecated In-Reply-To: References: <20091222.17435800.1351067935@gyor.oxdrove.co.uk> Message-ID: <20091224.10273400.2125556663@gyor.oxdrove.co.uk> On 22/12/09, 18:30:05, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] CSWpython-rt is now deprecated: > On Tue, Dec 22, 2009 at 5:43 PM, James Lee wrote: > > I presume you have made CSWpython-rt depend on CSWpython so there is > > no urgency to the change. > I haven't made CSWpython-rt depend on CSWpython initially, but I've > followed this suggestion and I've sent the updated CSWpython-rt to > Phil. Thanks for the change. That's save me repackaging 400MB of files. 3.2 is coming soon and I'll make the change at upgrade time. James. From rupert at opencsw.org Thu Dec 24 11:56:04 2009 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 24 Dec 2009 11:56:04 +0100 Subject: [csw-maintainers] Change the dependency from CSWpython-rt to CSWpython - decommit silvercity Message-ID: <6af4270912240256g701aaa1t9fbea5e051702ec8@mail.gmail.com> hi, is it possible to remove / decommit silvercity instead of fixing it? it was there because of trac, but they changed their mind quite a while ago, see http://trac.edgewall.org/wiki/SilverCity. rupert. ---------- Forwarded message ---------- From: Mantis Bug Tracker Date: Tue, Dec 22, 2009 at 18:19 Subject: [trac 0004091]: Change the dependency from CSWpython-rt to CSWpython To: rupert at opencsw.org The following issue has been SUBMITTED. ====================================================================== http://www.opencsw.org/bugtrack/view.php?id=4091 ====================================================================== Reported By: ? ? ? ? ? ? ? ?maciej Assigned To: ====================================================================== Project: ? ? ? ? ? ? ? ? ? ?trac Issue ID: ? ? ? ? ? ? ? ? ? 4091 Category: ? ? ? ? ? ? ? ? ? packaging Reproducibility: ? ? ? ? ? ?always Severity: ? ? ? ? ? ? ? ? ? major Priority: ? ? ? ? ? ? ? ? ? normal Status: ? ? ? ? ? ? ? ? ? ? new ====================================================================== Date Submitted: ? ? ? ? ? ? 2009-12-22 18:19 CET Last Modified: ? ? ? ? ? ? ?2009-12-22 18:19 CET ====================================================================== Summary: ? ? ? ? ? ? ? ? ? ?Change the dependency from CSWpython-rt to CSWpython Description: Executive summary: CSWpython-rt is deprecated, please re-point your dependencies at CSWpython. ====================================================================== From phil at bolthole.com Thu Dec 24 18:27:22 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Dec 2009 09:27:22 -0800 Subject: [csw-maintainers] Change the dependency from CSWpython-rt to CSWpython - decommit silvercity In-Reply-To: <6af4270912240256g701aaa1t9fbea5e051702ec8@mail.gmail.com> References: <6af4270912240256g701aaa1t9fbea5e051702ec8@mail.gmail.com> Message-ID: On Thu, Dec 24, 2009 at 2:56 AM, rupert THURNER wrote: > hi, > > is it possible to remove / decommit silvercity instead of fixing it? > it was there because of trac, but they changed their mind quite a > while ago, see http://trac.edgewall.org/wiki/SilverCity. > huh. well, if silvercity was only in our packages because of trac, and if trac no longer uses it... then yes it is possible. however... Im' confused.. we donthave a pygments package... ? > rupert. > > > > ---------- Forwarded message ---------- > From: Mantis Bug Tracker > Date: Tue, Dec 22, 2009 at 18:19 > Subject: [trac 0004091]: Change the dependency from CSWpython-rt to CSWpython > To: rupert at opencsw.org > > > > The following issue has been SUBMITTED. > ====================================================================== > http://www.opencsw.org/bugtrack/view.php?id=4091 > ====================================================================== > Reported By: ? ? ? ? ? ? ? ?maciej > Assigned To: > ====================================================================== > Project: ? ? ? ? ? ? ? ? ? ?trac > Issue ID: ? ? ? ? ? ? ? ? ? 4091 > Category: ? ? ? ? ? ? ? ? ? packaging > Reproducibility: ? ? ? ? ? ?always > Severity: ? ? ? ? ? ? ? ? ? major > Priority: ? ? ? ? ? ? ? ? ? normal > Status: ? ? ? ? ? ? ? ? ? ? new > ====================================================================== > Date Submitted: ? ? ? ? ? ? 2009-12-22 18:19 CET > Last Modified: ? ? ? ? ? ? ?2009-12-22 18:19 CET > ====================================================================== > Summary: ? ? ? ? ? ? ? ? ? ?Change the dependency from CSWpython-rt to CSWpython > Description: > Executive summary: CSWpython-rt is deprecated, please re-point your > dependencies at CSWpython. > > ====================================================================== > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers From maciej at opencsw.org Thu Dec 24 19:46:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 24 Dec 2009 18:46:46 +0000 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing Message-ID: I've spent some time hacking away at checkpkg, the one to which I have write access. I've created a v2-checkpkg branch in gar and re-implemented the part of checkpkg which analyzes shared library dependencies. My implementation takes into account the RPATH set in the analyzed shared libraries, which allows it to correctly identify GCC runtime dependencies. To test it, set the svn:externals property on the 'trunk' directory to https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2-checkpkg The output of the modified checkpkg is slightly different. When it checks multiple packages, it prints the dependency report at the end of the run, reporting each package in a separate section. For example: CSWgnupg-agent: SUGGESTION: you may want to add some or all of the following as depends: (Feel free to ignore SUNW or SPRO packages) > SUNWcsl The following dependencies might be unnecessary: < CSWpinentry CSWgnupg2: SUGGESTION: you may want to add some or all of the following as depends: (Feel free to ignore SUNW or SPRO packages) > SUNWcsl The following dependencies might be unnecessary: < CSWlibidn < CSWosslrt < CSWgnupg-agent < CSWlibassuan The potentially unnecessary dependencies are a new feature. I'd be happy if people tested this change to see if it works with their builds. I'd also like to ask Dago for review if he's happy with the change. Here's the diff: http://tinyurl.com/yj9pgr9 I talked with Ben who was also working on a checkpkg replacement. He didn't mind me coding up an update to checkpkg, and offered his code if I wanted to use it. I've looked at it and I think there's a large portion of design views that we share, and I think that I'll be able to use some parts of his code. The main difference in approach is that Ben wanted to remove the existing code and deploy a complete rewrite. I took a more gradual approach, where I started to make smaller changes, which allow to gradually replace old code with new one. It also allows to easily write new, isolated tests which don't need any changes to the main checkpkg code. I've tested my new code against a number of builds, but I guess there will be some corner cases, and the sooner we find them, the better. If there are no objections, I'll merge the change to the v2 branch in few days. Maciej From phil at bolthole.com Thu Dec 24 19:59:56 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 24 Dec 2009 10:59:56 -0800 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Thu, Dec 24, 2009 at 10:46 AM, Maciej (Matchek) Blizinski wrote: > I've spent some time hacking away at checkpkg, the one to which I have > write access. ?I've created a v2-checkpkg branch in gar and > re-implemented the part of checkpkg which analyzes shared library > dependencies. ?My implementation takes into account the RPATH set in > the analyzed shared libraries, which allows it to correctly identify > GCC runtime dependencies. >...(n more!) Wow, great! I'm really glad someone has sat down to code this. Thanks From james at opencsw.org Fri Dec 25 13:18:42 2009 From: james at opencsw.org (James Lee) Date: Fri, 25 Dec 2009 12:18:42 GMT Subject: [csw-maintainers] CSWcswclassutils: it wants to write in /usr In-Reply-To: <1261571233-sup-6117@ntdws12.chass.utoronto.ca> References: <625385e30912100427m2c29a552q433c736c72cf0c4b@mail.gmail.com> <20091210130501.GA7667@sebastiankayser.de> <625385e30912100606i47cdd0e6ie6e98b55ffaecb4f@mail.gmail.com> <4B2BEBFC.4040601@opencsw.org> <4B2BFD68.6090301@opencsw.org> <20091222.16051300.3754394574@gyor.oxdrove.co.uk> <1261499782-sup-5582@ntdws12.chass.utoronto.ca> <20091222.17090800.2208031977@gyor.oxdrove.co.uk> <1261505240-sup-8636@ntdws12.chass.utoronto.ca> <20091223.9283900.1782552105@gyor.oxdrove.co.uk> <1261571233-sup-6117@ntdws12.chass.utoronto.ca> Message-ID: <20091225.12184200.360440408@gyor.oxdrove.co.uk> On 23/12/09, 12:40:11, Ben Walton wrote regarding Re: [csw-maintainers] CSWcswclassutils: it wants to write in /usr: > > However, it does work, this gets to my normal IMAP account on another > > zone/machine with exim but using sendmail as the first local hop: > ...but this is only by chance, and is site/setup dependent. It's not chance, I know it works. > What if > you only allow relay internally using LMTP or submission(587) w/tls? I don't, which isn't chance either. > Your setup would then fail unless you also maintained a separate > sendmail config...at which point, No, it's the default sendmail config used to relay the dregs one hop only. Not ideal but it's my comprise solution that works. > Two mailers is just plain broken. A bug, if you will. Risking the wrath of the Unix gods, anyone using /usr/lib/sendmail directly deserves to fail. James. From pfelecan at opencsw.org Fri Dec 25 17:10:21 2009 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 25 Dec 2009 17:10:21 +0100 Subject: [csw-maintainers] the catalog is corrupted Message-ID: The catalog is corrupted since yesterday: - the catalog shows (end of lines trimmed): openssh 5.3,REV=2009.10.10_rev=p1 CSWossh openssh-5.3,REV=2009.10.10_rev=p1-SunOS5.8-i386-CSW.pkg.gz openssh_client 5.3,REV=2009.10.10_rev=p1 CSWosshclient openssh_client-5.3,REV=2009.10.10_rev=p1-SunOS5.8-i386-CSW.pkg.gz - the file system shows: openssh-5.3p1,REV=2009.12.16-SunOS5.8-i386-CSW.pkg.gz openssh_client-5.3p1,REV=2009.12.16-SunOS5.8-i386-CSW.pkg.gz -- Peter From maciej at opencsw.org Fri Dec 25 18:05:19 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 25 Dec 2009 17:05:19 +0000 Subject: [csw-maintainers] the catalog is corrupted In-Reply-To: References: Message-ID: On Fri, Dec 25, 2009 at 4:10 PM, Peter FELECAN wrote: > The catalog is corrupted since yesterday: I saw the same thing. There was also an anomaly in the GPG signature near the top of the file. - -----BEGIN instead of: -----BEGIN From bonivart at opencsw.org Fri Dec 25 19:43:19 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 25 Dec 2009 19:43:19 +0100 Subject: [csw-maintainers] the catalog is corrupted In-Reply-To: References: Message-ID: <625385e30912251043r430c140dsd026640292975e95@mail.gmail.com> On Fri, Dec 25, 2009 at 6:05 PM, Maciej (Matchek) Blizinski wrote: > On Fri, Dec 25, 2009 at 4:10 PM, Peter FELECAN wrote: >> The catalog is corrupted since yesterday: > > I saw the same thing. There was also an anomaly in the GPG signature > near the top of the file. > > - -----BEGIN > > instead of: > > -----BEGIN How is the catalog produced during updates? Is it hand-edited or is it produced from a package database? I think the latter should make for a higher quality catalog and also allow for different catalog formats produced at the same time without extra effort. -- /peter From william at wbonnet.net Fri Dec 25 20:16:35 2009 From: william at wbonnet.net (William Bonnet) Date: Fri, 25 Dec 2009 20:16:35 +0100 Subject: [csw-maintainers] Merry X-Mas Message-ID: <4B350F93.9000601@wbonnet.net> Hi guys Merry Christmas everyone :) cheers W. From phil at bolthole.com Sat Dec 26 04:54:46 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 25 Dec 2009 19:54:46 -0800 Subject: [csw-maintainers] the catalog is corrupted In-Reply-To: References: Message-ID: thanks for noticing . I have refreshed catalog , pushed it out, and added an extra check in the push script From maciej at opencsw.org Sun Dec 27 02:00:29 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 27 Dec 2009 01:00:29 +0000 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) In-Reply-To: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> References: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> Message-ID: On Tue, Sep 1, 2009 at 3:32 PM, Dagobert Michelsen wrote: > (...) > I guess I'll switch package compression in GAR to pigz after > release. What's the status of pigz usage/deployment? Some packages I work with, take quite a long time to gzip. Maciej From maciej at opencsw.org Sun Dec 27 02:09:11 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 27 Dec 2009 01:09:11 +0000 Subject: [csw-maintainers] Building MySQL 5.1.x In-Reply-To: <48E837C1-8FC2-41D0-9379-6BEABF129BD4@opencsw.org> References: <48E837C1-8FC2-41D0-9379-6BEABF129BD4@opencsw.org> Message-ID: On Fri, Dec 4, 2009 at 11:03 AM, Dagobert Michelsen wrote: > Hi Maciej, > >> libtool: Version mismatch error. ?This is libtool 2.2.6, but the >> libtool: definition of this LT_INIT comes from libtool 2.2.6b. >> libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 >> libtool: and run autoconf again. >> gmake[4]: *** [conf_to_src] Error 63 >> gmake[4]: *** Waiting for unfinished jobs.... >> gmake[4]: Leaving directory >> >> `/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/strings' >> >> This is a completely clean build, no preexisting files. ?Has anyone >> seen this problem before? > > *Sigh* I did update libtool to 2.2.6b a couple of days ago. > Most certainly this is the cause for the problem. However, > I don't understand why it actually *is* a problem as the > macros should only be pulled in when the autoconf-files are > regenerated. I can offer to look at the problem but won't > consider myself a libtool wizard. The problem appears to be in MySQL sources rather than our installation. Rerunning autoconf fixes the issue. Meanwhile, I've got a question about the 5.1 version: do we release CSWmysql51* as a new set of packages or do we upgrade CSWmysql5 with the 5.1 version? From rupert at opencsw.org Sun Dec 27 16:59:18 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 27 Dec 2009 16:59:18 +0100 Subject: [csw-maintainers] Building MySQL 5.1.x In-Reply-To: References: <48E837C1-8FC2-41D0-9379-6BEABF129BD4@opencsw.org> Message-ID: <6af4270912270759n100696e2r45e2d5fd940814ed@mail.gmail.com> On Sun, Dec 27, 2009 at 02:09, Maciej (Matchek) Blizinski wrote: > On Fri, Dec 4, 2009 at 11:03 AM, Dagobert Michelsen wrote: >> Hi Maciej, >> >>> libtool: Version mismatch error. ?This is libtool 2.2.6, but the >>> libtool: definition of this LT_INIT comes from libtool 2.2.6b. >>> libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 >>> libtool: and run autoconf again. >>> gmake[4]: *** [conf_to_src] Error 63 >>> gmake[4]: *** Waiting for unfinished jobs.... >>> gmake[4]: Leaving directory >>> >>> `/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.1.x-optcsw/work/solaris8-sparc/build-isa-sparcv8/mysql-5.1.40/strings' >>> >>> This is a completely clean build, no preexisting files. ?Has anyone >>> seen this problem before? >> >> *Sigh* I did update libtool to 2.2.6b a couple of days ago. >> Most certainly this is the cause for the problem. However, >> I don't understand why it actually *is* a problem as the >> macros should only be pulled in when the autoconf-files are >> regenerated. I can offer to look at the problem but won't >> consider myself a libtool wizard. > > The problem appears to be in MySQL sources rather than our > installation. ?Rerunning autoconf fixes the issue. > > Meanwhile, I've got a question about the 5.1 version: do we release > CSWmysql51* as a new set of packages or do we upgrade CSWmysql5 with > the 5.1 version? the upgrade and incompatible change list is quite impressing: http://dev.mysql.com/doc/refman/5.1/en/upgrading-from-previous-series.html rupert. From phil at bolthole.com Mon Dec 28 15:24:56 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 28 Dec 2009 06:24:56 -0800 Subject: [csw-maintainers] vacation, package releases... Message-ID: <20091228142456.GA61726@bolthole.com> Please note; I'll be going on a bit of a vacation today, so package releases will be slow at best. For anything *critical* that needs to be released, please nudge James. Otherwise, you might wait until friday. From maciej at opencsw.org Mon Dec 28 17:05:24 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 28 Dec 2009 16:05:24 +0000 Subject: [csw-maintainers] GAR: isaexec symlink loop Message-ID: I ran a MySQL 5.0 build and I've taken a look at the symlink/isaexec structure. > grep mysqlimport work/solaris8-sparc/build-global/CSWmysql5client.prototype-sparc s none /opt/csw/bin/mysqlimport=../mysql5/bin/mysqlimport l none /opt/csw/mysql5/bin/mysqlimport=/opt/csw/bin/isaexec 0755 root bin f none /opt/csw/mysql5/bin/sparcv8/mysqlimport=/opt/csw/mysql5/bin/mysqlimport 0755 root bin f none /opt/csw/mysql5/bin/sparcv9/mysqlimport 0755 root bin f none /opt/csw/mysql5/share/man/man1/mysqlimport.1 0644 root bin Let's consider a sparcv8 system. We want to execute "mysqlimport". /opt/csw/bin/mysqlimport is a symlink to /opt/csw/mysql5/bin/mysqlimport, which is a symlink to /opt/csw/bin/isaexec, which will attempt to execute /opt/csw/mysql5/bin/sparcv8/mysqlimport. All would be good if /opt/csw/mysql5/bin/sparcv8/mysqlimport was a binary, but it's a symlink to /opt/csw/mysql5/bin/mysqlimport (which is a symlink to isaexec). It looks to me as if there was a circle of symlinks. Isaexec would basically try to run itself. The sparcv9 binary runs fine, because /opt/csw/mysql5/bin/sparcv9/mysqlimport is an actual binary, not a symlink. Dago, what do you think? Is there a problem during merge? The code is at https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.0.x Maciej From skayser at opencsw.org Mon Dec 28 23:35:39 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 28 Dec 2009 23:35:39 +0100 Subject: [csw-maintainers] Perl v5.10.1 in testing versus cssh In-Reply-To: References: <20091221152001.GH7667@sebastiankayser.de> <81447451-FB9C-46F6-8954-3604A0FE3882@opencsw.org> <4B30033B.6000404@opencsw.org> Message-ID: <4B3932BB.6030807@opencsw.org> Dagobert Michelsen wrote on 22.12.2009 14:27: > Am 22.12.2009 um 00:22 schrieb Sebastian Kayser: >>> Sebastian, would you mind giving it a look? >> My time is limited also (will be away most of the holidays), but I >> will >> have a look. IIRC I even spotted a full blown CPAN-to-build- >> description >> utility within another distro. Might well be suitable/adjustable for >> our >> purposes. What sort of time pressure do we have with the perl upgrade? > > Well, the Perl in current is broken to the point that some packages > can't be compiled due to conflict in current vs. shipped MakeMaker. Perl > 5.10.1 solves this, so timely shipping would certainly be good. > > BTW, the cpan2pkg script I mentioned is based on the script you cited, > but already has all the stuff from CSW in it with the exception of > producing packages instead of GAR Makefiles. Time flies. Will be away until the 02.01. and didn't get to do anything aside from the "family schedule" so far, sorry. If anyone feels like hacking away on the cpan2pkg/cpan2gar script in the meantime, please give it a go. Dago, for reference purposes, was this script inspired by Gentoo's g-cpan [1] or something else? Couldn't find a reference in the script itself. Sebastian [1] http://www.gentoo.org/proj/en/perl/g-cpan.xml From maciej at opencsw.org Wed Dec 30 00:58:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 29 Dec 2009 23:58:47 +0000 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Thu, Dec 24, 2009 at 6:59 PM, Philip Brown wrote: > On Thu, Dec 24, 2009 at 10:46 AM, Maciej (Matchek) Blizinski > wrote: >> I've spent some time hacking away at checkpkg, the one to which I have >> write access. ?I've created a v2-checkpkg branch in gar and >> re-implemented the part of checkpkg which analyzes shared library >> dependencies. ?My implementation takes into account the RPATH set in >> the analyzed shared libraries, which allows it to correctly identify >> GCC runtime dependencies. >>...(n more!) > > Wow, great! > > I'm really glad someone has sat down to code this. Thanks It needed a fair bit of work to get it to work properly. I used my MySQL and PostgreSQL builds to test it some more, and squashed more bugs. Two main things I've added since: 1. expanding the $ISALIST from the runtime search path 2. emulating the /opt/csw/lib/64 --> amd64 symlink There are also smaller changes, mainly related to the output formatting. For instance, the most basic SUNW libraries aren't reported as missing, since they're needed by virtually any package, so they don't carry any signal; they're noise. Here's a sample output from the current version: libmysqlclient.so.15 is provided by the package itself libCstd.so.1 is provided by u'*SUNWlibC' and required by: mysql mysql_tzinfo_to_sql mysqladmin mysqlbinlog mysqld mysqlmanager libCrun.so.1 is provided by u'*SUNWlibC' and required by: mysql mysql_tzinfo_to_sql mysqladmin mysqlbinlog mysqld mysqlmanager librt.so.1 is provided by u'SUNWcsl' and required by: comp_err innochecksum libmysqlclient.so.15.0.0 my_print_defaults myisam_ftdump myisamchk myisamlog myisampack mysql mysql_client_test mysql_tzinfo_to_sql mysql_upgrade mysql_waitpid mysqladmin mysqlbinlog mysqlcheck mysqld mysqldump mysqlimport mysqlmanager mysqlshow mysqltest mysqltestmanager-pwgen mysqltestmanagerc perror replace resolve_stack_dump (...) CSWmysql5rt: + Dependencies of CSWmysql5rt look good. CSWmysql5client: + Dependencies of CSWmysql5client look good. CSWmysql5: The following packages might be unnecessary dependencies: ? CSWmysql5client The reason why it thinks that CSWmysql5 might not need to depend on CSWmysql5client is that there are no libraries in CSWmysql5client that CSWmysql5 would use. We know that if one runs a server, client binaries are also necessary. There's no obvious way in which this could be automated. Other dependencies can be automated, for instance the checker will guess that CSWfoo-devel should depend on CSWfoo, and will suggest adding the dependency. The main worry I have about the code is that has grew in line count beyond what I initially anticipated, and I doubt that it's easy to understand at the first glance. There is a number of unit tests, which should make code refactoring easier. I have one more bit to implement: checking the data modification timestamp of /var/sadm/install/contents and updating the cache. I should be able to implement it this week. I'd be interested to hear if anybody has tested this code. It should make the biggest difference when used with packages built with gcc. Maciej From dam at opencsw.org Thu Dec 31 12:59:06 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 31 Dec 2009 12:59:06 +0100 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) In-Reply-To: References: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> Message-ID: Hi Maciej, Am 27.12.2009 um 02:00 schrieb Maciej (Matchek) Blizinski: > On Tue, Sep 1, 2009 at 3:32 PM, Dagobert Michelsen > wrote: >> (...) >> I guess I'll switch package compression in GAR to pigz after >> release. > > What's the status of pigz usage/deployment? Some packages I work with, > take quite a long time to gzip. It works fine. The place to patch would be bin/mkpackage. I guess it would be best to add usepigz as extra option, but I haven't gotten around to do so. Would you mind patching it in? Best regards -- Dago From trygvis at opencsw.org Thu Dec 31 13:11:33 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Thu, 31 Dec 2009 13:11:33 +0100 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) In-Reply-To: References: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> Message-ID: <4B3C94F5.1080302@opencsw.org> Dagobert Michelsen wrote: > Hi Maciej, > > Am 27.12.2009 um 02:00 schrieb Maciej (Matchek) Blizinski: >> On Tue, Sep 1, 2009 at 3:32 PM, Dagobert Michelsen >> wrote: >>> (...) >>> I guess I'll switch package compression in GAR to pigz after >>> release. >> >> What's the status of pigz usage/deployment? Some packages I work with, >> take quite a long time to gzip. > > It works fine. The place to patch would be bin/mkpackage. I guess it would > be best to add usepigz as extra option, but I haven't gotten around to > do so. > Would you mind patching it in? I may have asked this before, but is there really a need for compressing the packages before they're sent to testing/? I don't know how you guys work, but I always end up with a long command ala this when I'm developing packages: gunzip -f ~/opencsw/pkgs/CSWfoo-1.2.3*.tar.gz && pkgadd -d ~/opencsw/.. So the first think I'm doing after creating the package is to uncompress it, just so that I can install it. How about getting "make package" create the uncompressed package and "make package.gz" create the compressed one? -- Trygve From dam at opencsw.org Thu Dec 31 13:19:54 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 31 Dec 2009 13:19:54 +0100 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) In-Reply-To: <4B3C94F5.1080302@opencsw.org> References: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> <4B3C94F5.1080302@opencsw.org> Message-ID: <243BFE5C-E361-4A91-85B3-7977BC5CCFEF@opencsw.org> Hi Trygve, Am 31.12.2009 um 13:11 schrieb Trygve Laugst?l: > Dagobert Michelsen wrote: >> Hi Maciej, >> Am 27.12.2009 um 02:00 schrieb Maciej (Matchek) Blizinski: >>> On Tue, Sep 1, 2009 at 3:32 PM, Dagobert Michelsen >>> wrote: >>>> (...) >>>> I guess I'll switch package compression in GAR to pigz after >>>> release. >>> >>> What's the status of pigz usage/deployment? Some packages I work >>> with, >>> take quite a long time to gzip. >> It works fine. The place to patch would be bin/mkpackage. I guess >> it would >> be best to add usepigz as extra option, but I haven't gotten around >> to do so. >> Would you mind patching it in? > > I may have asked this before, but is there really a need for > compressing the packages before they're sent to testing/? > > I don't know how you guys work, but I always end up with a long > command ala this when I'm developing packages: > > gunzip -f ~/opencsw/pkgs/CSWfoo-1.2.3*.tar.gz && pkgadd -d ~/ > opencsw/.. > > So the first think I'm doing after creating the package is to > uncompress it, just so that I can install it. How about getting > "make package" create the uncompressed package and "make package.gz" > create the compressed one? That would mean the package delivery script to newpkgs/ from Maciej would do the compression on the fly? Maybe we should talk about the general workflow in conjunction with this: Best regards -- Dago From trygvis at opencsw.org Thu Dec 31 13:47:23 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Thu, 31 Dec 2009 13:47:23 +0100 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) In-Reply-To: <243BFE5C-E361-4A91-85B3-7977BC5CCFEF@opencsw.org> References: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> <4B3C94F5.1080302@opencsw.org> <243BFE5C-E361-4A91-85B3-7977BC5CCFEF@opencsw.org> Message-ID: <4B3C9D5B.7040702@opencsw.org> Dagobert Michelsen wrote: > Hi Trygve, > > Am 31.12.2009 um 13:11 schrieb Trygve Laugst?l: >> Dagobert Michelsen wrote: >>> Hi Maciej, >>> Am 27.12.2009 um 02:00 schrieb Maciej (Matchek) Blizinski: >>>> On Tue, Sep 1, 2009 at 3:32 PM, Dagobert Michelsen >>>> wrote: >>>>> (...) >>>>> I guess I'll switch package compression in GAR to pigz after >>>>> release. >>>> >>>> What's the status of pigz usage/deployment? Some packages I work with, >>>> take quite a long time to gzip. >>> It works fine. The place to patch would be bin/mkpackage. I guess it >>> would >>> be best to add usepigz as extra option, but I haven't gotten around >>> to do so. >>> Would you mind patching it in? >> >> I may have asked this before, but is there really a need for >> compressing the packages before they're sent to testing/? >> >> I don't know how you guys work, but I always end up with a long >> command ala this when I'm developing packages: >> >> gunzip -f ~/opencsw/pkgs/CSWfoo-1.2.3*.tar.gz && pkgadd -d ~/opencsw/.. >> >> So the first think I'm doing after creating the package is to >> uncompress it, just so that I can install it. How about getting "make >> package" create the uncompressed package and "make package.gz" create >> the compressed one? > > That would mean the package delivery script to newpkgs/ from Maciej > would do the compression on the fly? Maybe we should talk about > the general workflow in conjunction with this: > To me that would be a natural place to compress stuff. It's also quite possible to script the moving from testing/ to testing-compressed/ so that the maintainer doesn't have to do anything (nor do we have to create extra scripts for it). -- Trygve From bwalton at opencsw.org Thu Dec 31 14:45:57 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 31 Dec 2009 08:45:57 -0500 Subject: [csw-maintainers] New in testing: parallel gzip 'pigz' (pronounced pig-zee) In-Reply-To: <4B3C94F5.1080302@opencsw.org> References: <12435D87-4BB6-4BC1-A4E4-D3F4110AAA01@opencsw.org> <4B3C94F5.1080302@opencsw.org> Message-ID: <1262266971-sup-128@ntdws12.chass.utoronto.ca> Excerpts from Trygve Laugst?l's message of Thu Dec 31 07:11:33 -0500 2009: > I don't know how you guys work, but I always end up with a long command > ala this when I'm developing packages: > > gunzip -f ~/opencsw/pkgs/CSWfoo-1.2.3*.tar.gz && pkgadd -d > ~/opencsw/.. I do this, but typically only after a: scp login.bo:staging/CSWfoo-1.2.3*.tar.gz . I don't usually build locally at all since I don't have any sol8 dev boxes and I prefer to do all of my building there first to shake out bugs that might not be found in 10. For some packages, not being zipped would be fine. For others, this would add to my transfer time significantly. I think I'd still upvote the change though, as overall, it makes more sense. Compress for release. It would have a side benefit of making checkpkg faster since it wouldn't need to unzip each package being inspected either. -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 rupert at opencsw.org Thu Dec 31 17:56:01 2009 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 31 Dec 2009 17:56:01 +0100 Subject: [csw-maintainers] how to use the gnu linker? or is there anything else what can be done? Message-ID: <6af4270912310856jdca43b9s5361db04adf5d72d@mail.gmail.com> when trying to build lzip lzlib linking does not work. how can one correct this? rupert at build8s:~/mgar/pkg/lzlib/trunk $ gmake package [===== NOW BUILDING: lzlib-0.8-rc1 =====] [prerequisite] complete for lzlib. [fetch] complete for lzlib. [checksum] complete for lzlib. [checksum-global] complete for lzlib. [checksum-modulated] complete for lzlib. [===== NOW BUILDING: lzlib-0.8-rc1 MODULATION global: ISA= =====] [extract-modulated] complete for lzlib. [===== Building modulation 'isa-sparcv8' on host 'build8s' =====] gmake PLATFORM=solaris8-sparc MODULATION=isa-sparcv8 ISA=sparcv8 merge-modulated gmake[1]: Entering directory `/home/rupert/mgar/pkg/lzlib/trunk' [===== NOW BUILDING: lzlib-0.8-rc1 MODULATION isa-sparcv8: ISA=sparcv8 =====] [extract-modulated] complete for lzlib. [patch-modulated] complete for lzlib. [configure-modulated] complete for lzlib. ==> Running make in work/solaris8-sparc/build-isa-sparcv8/lzlib-0.8-rc1 gmake[2]: Entering directory `/home/rupert/mgar/pkg/lzlib/trunk/work/solaris8-sparc/build-isa-sparcv8/lzlib-0.8-rc1' c++ -shared -Wl,--soname=liblz.so.0 -o liblz.so.0.8-rc1 sh_decoder.o sh_encoder.o sh_lzlib.o /usr/ccs/bin/ld: illegal option -- - ld: warning: option -o appears more than once, first setting taken usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) From bwalton at opencsw.org Thu Dec 31 18:29:05 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 31 Dec 2009 12:29:05 -0500 Subject: [csw-maintainers] how to use the gnu linker? or is there anything else what can be done? In-Reply-To: <6af4270912310856jdca43b9s5361db04adf5d72d@mail.gmail.com> References: <6af4270912310856jdca43b9s5361db04adf5d72d@mail.gmail.com> Message-ID: <1262280366-sup-6237@ntdws12.chass.utoronto.ca> Excerpts from rupert THURNER's message of Thu Dec 31 11:56:01 -0500 2009: Hi Rupert, > c++ -shared -Wl,--soname=liblz.so.0 -o liblz.so.0.8-rc1 sh_decoder.o > sh_encoder.o sh_lzlib.o > /usr/ccs/bin/ld: illegal option -- - > ld: warning: option -o appears more than once, first setting taken > usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) I think what you're seeing here is actually some gcc options being passed to the compiler regardless of the fact you're not using gcc. These are likely hard coded in a Makefile somewhere. I'd suggest first trying GARCOMPILER = GCC4 before trying to make it use gld for linking. Trying to use gld will be an exercise in frustration, so hopefully you don't need to go there. Alternately, you can track down where the bad options sneak in and correct that instead. 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 rupert at opencsw.org Thu Dec 31 18:34:01 2009 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 31 Dec 2009 18:34:01 +0100 Subject: [csw-maintainers] how to use the gnu linker? or is there anything else what can be done? In-Reply-To: <1262280366-sup-6237@ntdws12.chass.utoronto.ca> References: <6af4270912310856jdca43b9s5361db04adf5d72d@mail.gmail.com> <1262280366-sup-6237@ntdws12.chass.utoronto.ca> Message-ID: <6af4270912310934p2a8f9bb9r104b102b49558d4a@mail.gmail.com> On Thu, Dec 31, 2009 at 18:29, Ben Walton wrote: > Excerpts from rupert THURNER's message of Thu Dec 31 11:56:01 -0500 2009: > > Hi Rupert, > >> c++ -shared -Wl,--soname=liblz.so.0 -o liblz.so.0.8-rc1 sh_decoder.o >> sh_encoder.o sh_lzlib.o >> /usr/ccs/bin/ld: illegal option -- - >> ld: warning: option -o appears more than once, first setting taken >> usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) > > I think what you're seeing here is actually some gcc options being > passed to the compiler regardless of the fact you're not using gcc. > These are likely hard coded in a Makefile somewhere. ?I'd suggest > first trying GARCOMPILER = GCC4 before trying to make it use gld for > linking. ?Trying to use gld will be an exercise in frustration, so > hopefully you don't need to go there. i am using GARCOMPILER = GCC, is this different? i think the options are hardcoded, yes. therefor i thought gld might fix this - and it would be easy :) rupert. From rupert at opencsw.org Thu Dec 31 19:04:53 2009 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 31 Dec 2009 19:04:53 +0100 Subject: [csw-maintainers] clean without cleaning the downloaded file, unpackaged file ? Message-ID: <6af4270912311004k73ae3a67m677af8f684c931fc@mail.gmail.com> how can the build result can be cleaned without deleting the downloaded file, or maybe even avoiding unzipping it again? i try to build qt4 as base for kde4, and the download is more than 100 mb. as i got an error on build8s, i also tried to build on build10s, and i am wondering if it is correct that it says "sparvc8": rupert at build10s:~/mgar/pkg/qt4/trunk $ gmake package gar/gar.pkg.mk:682: *** You are building this package on a non-requested platform host 'build10s'. The follow platforms were requested: gar/gar.pkg.mk:682: *** - solaris8-sparc to be build on host 'build8s' rupert at build10s:~/mgar/pkg/qt4/trunk $ gmake build gmake[1]: Entering directory `/home/rupert/mgar/pkg/qt4/trunk' gmake -s MODULATION=global checksum gmake[2]: Entering directory `/home/rupert/mgar/pkg/qt4/trunk' [===== NOW BUILDING: qt4-4.6.0 =====] ... ==> Running configure in work/build-isa-sparcv8/qt-everywhere-opensource-src-4.6.0 rupert.