From dam at opencsw.org Mon Nov 2 14:09:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Nov 2009 14:09:28 +0100 Subject: [csw-maintainers] Update of libevent and memcached Message-ID: Hi Rupert, hi Ben, I would need an updated libevent and memcached and I noticed you already did most of the work :-) I took the liberty of adding the legacy lib to the recipe of libevent and 64 bit to it and put it in testing/. Feel free to rebuild and release libevent. Next thing I need is memcached. It needs stdbool and stdint which I added from gnulib. However, the header files end up in lib/ and are not added to the include path. Ben, would you please enlighten me what is going wrong here? Additionally, I found these excellent Blog posts from Trond Norbye: http://blogs.sun.com/trond/category/Memcached regarding memcached on Solaris. Nice, but only starting from OpenSolaris. I wonder if we can get the manifest and stuff for our package. Best regards -- Dago From maciej at opencsw.org Mon Nov 2 15:05:26 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 2 Nov 2009 14:05:26 +0000 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: On Tue, Oct 27, 2009 at 9:28 AM, Dagobert Michelsen wrote: > In addition to migrating single files is there the possibility to migrate > complete directories? Like > ?/opt/csw/var/postgresql/ ?to ?/var/opt/csw/posgresql/ ? Yes, it is possible. For copying directories, tar is being used, to preserve the whole tree structure that's being copied. Files and directories can be specified the same way; you don't have to say which one is a file and which one is a directory. Maciej From dam at opencsw.org Mon Nov 2 15:13:10 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Nov 2009 15:13:10 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: Hi Maciej, Am 02.11.2009 um 15:05 schrieb Maciej (Matchek) Blizinski: > On Tue, Oct 27, 2009 at 9:28 AM, Dagobert Michelsen > wrote: >> In addition to migrating single files is there the possibility to >> migrate >> complete directories? Like >> /opt/csw/var/postgresql/ to /var/opt/csw/posgresql/ ? > > Yes, it is possible. For copying directories, tar is being used, to > preserve the whole tree structure that's being copied. Files and > directories can be specified the same way; you don't have to say which > one is a file and which one is a directory. Excellent! Unfortunately now I no longer have an excuse for not relocating ;-) I guess I'll make a try with fontconfig first which is waiting in testing with the old layout scheme. Best regards -- Dago From maciej at opencsw.org Mon Nov 2 15:49:48 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 2 Nov 2009 14:49:48 +0000 Subject: [csw-maintainers] New library 'jack' wants to be build with 'waf' In-Reply-To: <47F4C2E7-7170-4DA0-B287-ED592FE6328C@opencsw.org> References: <47F4C2E7-7170-4DA0-B287-ED592FE6328C@opencsw.org> Message-ID: On Thu, Oct 29, 2009 at 10:21 AM, Dagobert Michelsen wrote: > Hi, > > I just tried to build a dependency for libsndfile 'jack' which wants > to be built with the waf build system: > ?http://code.google.com/p/waf/ > > I haven't seen much of it, by I already hate it... Maybe someone has already > gained some experience with it? I tried adding support for WAF to GAR > and made preliminary makefile for jack, everything is in GAR. Are you sure it's not using autotools? A quick look at the jack sources: http://subversion.jackaudio.org/jack/trunk/jack/ Looks autotools-ey to me. Maciej From dam at opencsw.org Mon Nov 2 15:59:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Nov 2009 15:59:45 +0100 Subject: [csw-maintainers] New library 'jack' wants to be build with 'waf' In-Reply-To: References: <47F4C2E7-7170-4DA0-B287-ED592FE6328C@opencsw.org> Message-ID: Hi Maciej, Am 02.11.2009 um 15:49 schrieb Maciej (Matchek) Blizinski: > On Thu, Oct 29, 2009 at 10:21 AM, Dagobert Michelsen > wrote: >> I just tried to build a dependency for libsndfile 'jack' which wants >> to be built with the waf build system: >> http://code.google.com/p/waf/ >> >> I haven't seen much of it, by I already hate it... Maybe someone >> has already >> gained some experience with it? I tried adding support for WAF to GAR >> and made preliminary makefile for jack, everything is in GAR. > > Are you sure it's not using autotools? A quick look at the jack > sources: > > http://subversion.jackaudio.org/jack/trunk/jack/ > > Looks autotools-ey to me. That is "Jack", while for Solaris "Jack2" is needed: http://jackaudio.org/download That code is here: http://subversion.jackaudio.org/jack/jack2/trunk/jackmp/ and no longer based on autotools :-( Best regards -- Dago From schwindt at dfki.uni-kl.de Mon Nov 2 17:31:51 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 02 Nov 2009 17:31:51 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: Your message of "Wed, 28 Oct 2009 18:04:08 +0100." <4AE87988.5070401@dogan.ch> Message-ID: <200911021631.nA2GVptx008068@dfki.uni-kl.de> [...] > It would be really great if you could take over this package. As the > others already mentioned, Gar is really not difficult and you can always > ask here on the maintainers list. Sorry for the late feedback - I've been offline for a week now. I'll try to work through the docs and give it a try. Nicolai From schwindt at dfki.uni-kl.de Mon Nov 2 17:33:27 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 02 Nov 2009 17:33:27 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: Your message of "Wed, 28 Oct 2009 10:59:34 +0100." <625385e30910280259y77676329u8fc476812b82e5dc@mail.gmail.com> Message-ID: <200911021633.nA2GXRIw008101@dfki.uni-kl.de> > Dago found that people having well patched servers ;-) could run into > this due to a new cool feature in Solaris 10 called turbo charged > packages. Writes to the contents file are being delayed and synced > regularly instead of written immediately which should give a > significant performance boost. This is included in Solaris 10 update 8 > (10/09) and you can also get it via patch 119254/199255. I am setting up an old x4200 with exact that DVD rightnow. I`ll let you know when installed ssh etc. Nicolai From dam at opencsw.org Mon Nov 2 21:56:15 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Nov 2009 21:56:15 +0100 Subject: [csw-maintainers] Update of fftw In-Reply-To: References: <608B825C-14C2-4F48-9AD6-749E5FE4E9DA@opencsw.org> Message-ID: <64BAD361-8556-4CF5-B6FD-F183D8C9A7D6@opencsw.org> Hi, as it seems of general interest here the repost on-list: Am 02.11.2009 um 17:51 schrieb Maciej (Matchek) Blizinski: > On Mon, Nov 2, 2009 at 4:39 PM, Dagobert Michelsen > wrote: >>> Von: Dagobert Michelsen >>> Datum: 2. November 2009 17:00:05 MEZ >>> An: Joshua Buysse , Josh Buysse >>> Kopie: Philip Brown >>> Betreff: Update of fftw >>> >>> Hi Joshua, >>> >>> I have been playing around with fftw and made an updated package >>> for fftw including the 3.2.2 version. Usually it is policy to >>> add older libraries to the main package, but we already have the >>> fftw2 package. So I guess it will be best to add an fftw3 package >>> or should we go integrating both versioned libs in a main CSWfftw >>> package? > > My first thought is that it's better to have one fftw package, > including all the versions. > > Gentoo has a nice was of going around this. They have something called > 'slots'. If multiple major versions of a package need to coexist, they > occupy numbered slots. For instance, fftw-1.x would be assigned to > slot 0, fftw-2.x to slot 1 and fftw-3.x to slot 2. We don't have the > notion of slots, but we can merge multiple library versions in one > package. I had to wrap my mind around version modulations in GAR, but > it looks fairly easy now. (Until I run into problems again, that is. > :-) ) > > I would be for providing one package with all the versions. > > Maciej > > P.S. Dago, you can loop this e-mail in with the rest of the discussion > participants. Best regards -- Dago From ihsan at opencsw.org Tue Nov 3 12:41:16 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Tue, 03 Nov 2009 12:41:16 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <200911021631.nA2GVptx008068@dfki.uni-kl.de> References: <200911021631.nA2GVptx008068@dfki.uni-kl.de> Message-ID: <4AF016DB.9030200@opencsw.org> Hello Nicolai, On 02.11.2009 17:31, Nicolai Schwindt wrote: >> It would be really great if you could take over this package. As the >> others already mentioned, Gar is really not difficult and you can always >> ask here on the maintainers list. > Sorry for the late feedback - I've been offline for a week now. No problem. > I'll try to work through the docs and give it a try. Thanks a lot. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Tue Nov 3 16:35:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Nov 2009 16:35:17 +0100 Subject: [csw-maintainers] X11 linkage problem strategy Message-ID: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> Hi, there is a problem related to linkage against the new OpenCSW X11 libraries. The error is seen as undefined symbol XSolarisIASetProcessInfo as in here: > configure:19228: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 - > xarch=v8 -I/opt/csw/X11/include -I/opt/csw/include -I/opt/csw/ > include/gtk-1.2 -I/opt/csw/include/glib-1.2 -I/opt/csw/lib/glib/ > include -I/opt/csw/X11/include -I/opt/csw/include -xarch=v8 -L/opt/ > csw/lib -L/opt/csw/X11/lib conftest.c -L/opt/csw/lib -lgtk -lgdk - > lgmodule -lglib -ldl -lXi -lXext -lX11 -lsocket -lnsl -lm >&5 > Undefined first referenced > symbol in file > XSolarisIASetProcessInfo /lib/libX11.so.4 > ld: fatal: Symbol referencing errors. No output written to conftest The problem is caused by programs linking to CSW libXext first and then later to Solaris libX11 which also needs libXext. As the provided dependency libXext.so.0 is already provided by CSW libXext the already bound one is used - unfortunately it does not have the needed symbol in it. The easy workaround of adding Solaris libXext explicitly by adding EXTRA_LINKER_FLAGS = /usr/openwin/lib/libXext.so to the Makefile may or may not work. It does explicitly not work if the CSW libXext is also pulled in: > configure:19228: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 - > xarch=v8 -I/opt/csw/X11/include -I/opt/csw/include -I/opt/csw/ > include/gtk-1.2 -I/opt/csw/include/glib-1.2 -I/opt/csw/lib/glib/ > include -I/opt/csw/X11/include -I/opt/csw/include -xarch=v8 -L/opt/ > csw/lib -L/opt/csw/X11/lib /usr/openwin/lib/libXext.so conftest.c -L/ > opt/csw/lib -lgtk -lgdk -lgmodule -lglib -ldl -lXi -lXext -lX11 - > lsocket -lnsl -lm >&5 > ld: fatal: recording name conflict: file `/usr/openwin/lib/ > libXext.so' and file `/opt/csw/X11/lib/libXext.so' provide identical > dependency names: libXext.so.0 (possible multiple inclusion of the > same file) Maybe someone has a good solution on how to cope this in the general case. Of course the trivial one would be to recompile everything needing x11 against the CSW libs, which would pull in loads of stuff even if the Solaris library would be sufficient. Best regards -- Dago From maciej at opencsw.org Tue Nov 3 17:02:32 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 3 Nov 2009 16:02:32 +0000 Subject: [csw-maintainers] zlibCompileFlags symbol missing on sparcv9 Message-ID: Before I invest larger chunks of time in debugging this issue, I'm going to ask here. I'm trying to compile MySQL 5 on build8s, and I'm getting an error during the configure phase. It only happens with the sparcv9 modulation. configure:21806: checking for zlib compression library configure:21974: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 -xarch=v9 -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ -I/opt/csw/include -I/opt/csw/mysql5/include -D_FILE_OFFSET_BITS=64 -I/opt/csw/include -I/opt/csw/include -I/opt/csw/mysql5/include -xarch=v9 -L/opt/csw/mysql5/lib/64 -L/opt/csw/mysql5/lib//mysql/64 conftest.c -lposix4 -lresolv -lgen -lsocket -lnsl -lm -L/opt/csw/lib -lz >&5 "conftest.c", line 147: warning: statement not reached Undefined first referenced symbol in file zlibCompileFlags conftest.o ld: fatal: Symbol referencing errors. No output written to conftest Has anyone run into this problem before? Any ideas why does it work fine on sparcv8, but not on sparcv9? If anyone wants to reproduce it: svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.0.x/ cd mysql-5.0.x gmake package Maciej From dam at opencsw.org Tue Nov 3 17:11:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Nov 2009 17:11:51 +0100 Subject: [csw-maintainers] zlibCompileFlags symbol missing on sparcv9 In-Reply-To: References: Message-ID: <1676DF44-9F4E-4F0A-B662-28D032C3CC12@opencsw.org> Hi Maciej, Am 03.11.2009 um 17:02 schrieb Maciej (Matchek) Blizinski: > Before I invest larger chunks of time in debugging this issue, I'm > going to ask here. I'm trying to compile MySQL 5 on build8s, and I'm > getting an error during the configure phase. It only happens with the > sparcv9 modulation. > > configure:21806: checking for zlib compression library > configure:21974: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 > -xarch=v9 -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ > -I/opt/csw/include -I/opt/csw/mysql5/include -D_FILE_OFFSET_BITS=64 > -I/opt/csw/include -I/opt/csw/include -I/opt/csw/mysql5/include > -xarch=v9 -L/opt/csw/mysql5/lib/64 -L/opt/csw/mysql5/lib//mysql/64 > conftest.c -lposix4 -lresolv -lgen -lsocket -lnsl -lm -L/opt/csw/lib > -lz >&5 > "conftest.c", line 147: warning: statement not reached > Undefined first referenced > symbol in file > zlibCompileFlags conftest.o > ld: fatal: Symbol referencing errors. No output written to conftest > > Has anyone run into this problem before? Any ideas why does it work > fine on sparcv8, but not on sparcv9? > > If anyone wants to reproduce it: > svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.0.x/ > cd mysql-5.0.x > gmake package You are using some pathes that are unsuitable for 64 bit compilation. I'll commit the fix and repost the delta/revision. Best regards -- Dago From dam at opencsw.org Tue Nov 3 17:39:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Nov 2009 17:39:18 +0100 Subject: [csw-maintainers] zlibCompileFlags symbol missing on sparcv9 In-Reply-To: <1676DF44-9F4E-4F0A-B662-28D032C3CC12@opencsw.org> References: <1676DF44-9F4E-4F0A-B662-28D032C3CC12@opencsw.org> Message-ID: <5F92AAA4-A709-4E23-B9C9-293E1805365F@opencsw.org> Hi Maciej, Am 03.11.2009 um 17:11 schrieb Dagobert Michelsen: > Am 03.11.2009 um 17:02 schrieb Maciej (Matchek) Blizinski: > >> Before I invest larger chunks of time in debugging this issue, I'm >> going to ask here. I'm trying to compile MySQL 5 on build8s, and I'm >> getting an error during the configure phase. It only happens with >> the >> sparcv9 modulation. >> >> configure:21806: checking for zlib compression library >> configure:21974: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 >> -xarch=v9 -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ >> -I/opt/csw/include -I/opt/csw/mysql5/include -D_FILE_OFFSET_BITS=64 >> -I/opt/csw/include -I/opt/csw/include -I/opt/csw/mysql5/include >> -xarch=v9 -L/opt/csw/mysql5/lib/64 -L/opt/csw/mysql5/lib//mysql/64 >> conftest.c -lposix4 -lresolv -lgen -lsocket -lnsl -lm -L/opt/csw/lib >> -lz >&5 >> "conftest.c", line 147: warning: statement not reached >> Undefined first referenced >> symbol in file >> zlibCompileFlags conftest.o >> ld: fatal: Symbol referencing errors. No output written to conftest >> >> Has anyone run into this problem before? Any ideas why does it work >> fine on sparcv8, but not on sparcv9? >> >> If anyone wants to reproduce it: >> svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.0.x/ >> cd mysql-5.0.x >> gmake package > > You are using some pathes that are unsuitable for 64 bit > compilation. I'll commit > the fix and repost the delta/revision. The build still runs, but I have some early comments: > Index: Makefile > =================================================================== > --- Makefile (revision 7091) > +++ Makefile (working copy) > @@ -51,8 +51,6 @@ > SPKG_DESC_CSWmysql5rt = MySQL 5 runtime files > SPKG_DESC_CSWmysql5test = MySQL 5 testing files > > -support64 = (/(amd64|i386))? > - While you can insert this conditionally there is a special function which expands to all buildable ISAs. You would use it as $(call baseisadirs,,) It expands to / // // and it works on all platforms. This is more important if you add more modulations for optimized libraries. > # Defining the client programs, which are going to pick up the 32- > and 64-bit > # binaries, symbolic links, isaexec stuff and man pages. > CSWmysql5client_programs = myisamlog > @@ -75,11 +73,11 @@ > > PKGFILES_CSWmysql5bench = $(prefix)/sql-bench.* > PKGFILES_CSWmysql5client = $(bindir) > -PKGFILES_CSWmysql5client += $(foreach bin_name,$ > (CSWmysql5client_programs),$(bindir)$(support64)/$(bin_name)) > +PKGFILES_CSWmysql5client += $(foreach bin_name,$ > (CSWmysql5client_programs),$(call baseisadirs,$(bindir),$(bin_name))) > PKGFILES_CSWmysql5client += $(foreach bin_name,$ > (CSWmysql5client_programs),$(mandir)/man1/$(bin_name)\.1) > PKGFILES_CSWmysql5client += $(foreach bin_name,$ > (CSWmysql5client_programs),/opt/csw/bin/$(bin_name)) > PKGFILES_CSWmysql5client += $(foreach bin_name,$ > (CSWmysql5client_programs),/opt/csw/sbin/$(bin_name)) > -PKGFILES_CSWmysql5devel += $(bindir)$(support64)/mysql_config > +PKGFILES_CSWmysql5devel += $(call baseisadirs,$ > (bindir),mysql_config) > PKGFILES_CSWmysql5devel += $(mandir)/man1/mysql_config\.1 > PKGFILES_CSWmysql5devel = $(prefix)/include.* > PKGFILES_CSWmysql5rt = $(prefix)/lib/.*\.so.* > @@ -105,8 +103,8 @@ > > # because we alter the prefix. this gets us proper linking as well > as > # LD_OPTIONS (RPATH) > -EXTRA_LIB = /opt/csw/lib > -EXTRA_INC = /opt/csw/include > +# EXTRA_LIB = /opt/csw/lib > +# EXTRA_INC = /opt/csw/include It should not be necessary to add these explicitly, even if you redefine "prefix". The BUILD_PREFIX defaults to /opt/csw and it is the base where everything goes. If you reset prefix to a subdir of BUILD_PREFIX the necessary library pathes and include dirs are adjusted automatically. This is all done in gar.conf.mk. If you must add additional library dirs always use something like $(abspath $(libdir)/$(MM_BINDIR)) for pathes to binaries $(abspath $(libdir)/$(MM_LIBDIR)) for libraries to honour bitwidth-specific directories. I'll verify that it really works with MySQL, please stand by. > @@ -130,14 +128,16 @@ > BUILD64 = 1 > > USERGROUP = /etc/opt/csw/pkg/CSWmysql5/cswusergroup > -PROTOTYPE_FILTER = awk ' \ > - $$$$3 ~ /\/var\/opt\/csw\/mysql5$$$$/ { $$$$2 = "ugfiles"; \ > - $$$$4 = "0700"; \ > - $$$$5 = "mysql"; \ > - $$$$6 = "mysql" } \ > - { print }' > -SPKG_CLASSES = none cswusergroup ugfiles > > +PROTOTYPE_MODIFIERS = ownmysql > +PROTOTYPE_FILES_ownmysql = /var/opt/csw/mysql5 > +PROTOTYPE_USER_ownmysql = mysql > +PROTOTYPE_GROUP_ownmysql = mysql > +PROTOTYPE_PERMS_ownmysql = 0700 > +PROTOTYPE_CLASS_ownmysql = ugfiles > + > +SPKG_CLASSES = none ugfiles > + > include gar/category.mk > > post-install-modulated: > Ok, as you suggested prototype tweaks yourself you probably know how they work and why they are better than prototype filters ;-) http://sourceforge.net/apps/trac/gar/wiki/Prototypes Best regards -- Dago From dam at opencsw.org Tue Nov 3 21:23:34 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Nov 2009 21:23:34 +0100 Subject: [csw-maintainers] zlibCompileFlags symbol missing on sparcv9 In-Reply-To: <5F92AAA4-A709-4E23-B9C9-293E1805365F@opencsw.org> References: <1676DF44-9F4E-4F0A-B662-28D032C3CC12@opencsw.org> <5F92AAA4-A709-4E23-B9C9-293E1805365F@opencsw.org> Message-ID: <28FFE8F4-F607-424A-9A5A-2352BCF63129@opencsw.org> Hi, the problem to the linker flags have been fixed in r7096. If a different prefix was used the additional pathes were only added to the runtime linker path, not the normal linker path. If you encounter any such issues don't hesitate to post the list! Best regards -- Dago From ihsan at opencsw.org Wed Nov 4 10:27:14 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 04 Nov 2009 10:27:14 +0100 Subject: [csw-maintainers] Unbound build error Message-ID: <4AF148F2.7050807@opencsw.org> Hello, Have been there any changes on the build system recently? While building unbound: ./libtool --tag=CC --mode=link /opt/csw/gcc4/bin/gcc ./linktest.c -I. -I. -I/opt/csw/include -I/opt/csw/include -DHAVE_CONFIG_H -I. -I. -Wwrite-strings -W -Wall -O2 -g -O2 -pipe -mcpu=v8 -I/opt/csw/include -std=c99 -D__EXTENSIONS__ -D_BSD_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE -lldns -lnsl -lsocket -lcrypto -o linktest libtool: link: /opt/csw/gcc4/bin/gcc ./linktest.c -I. -I. -I/opt/csw/include -I/opt/csw/include -DHAVE_CONFIG_H -I. -I. -Wwrite-strings -W -Wall -O2 -g -O2 -pipe -mcpu=v8 -I/opt/csw/include -std=c99 -D__EXTENSIONS__ -D_BSD_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE -o linktest -lldns -lnsl -lsocket -lcrypto ld: fatal: library -lldns: not found ld: fatal: library -lcrypto: not found ld: fatal: File processing errors. No output written to linktest Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From schwindt at dfki.uni-kl.de Wed Nov 4 10:49:01 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Wed, 04 Nov 2009 10:49:01 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: Your message of "Wed, 28 Oct 2009 10:59:34 +0100." <625385e30910280259y77676329u8fc476812b82e5dc@mail.gmail.com> Message-ID: <200911040949.nA49n15n006224@dfki.uni-kl.de> [...] > So please help test cswclassutils 1.27 in testing. Some packages to > test with are: CSWclamav, CSWossh and CSWcacertificates. If you > maintain packages that use cpsampleconf or preserveconf, please test > them. > > http://mirror.opencsw.org/testing/cswclassutils-1.27,REV=2009.10.28-SunOS5.8- all-CSW.pkg.gz Do you want this in mantis ? pkg-get -i trac ... Compiling py files to normal bytecode ... Traceback (most recent call last): File "/var/opt/csw/cswclassutils/pycomp.318.20091104102411.py", line 143, in except PyCompileError: NameError: name 'PyCompileError' is not defined Compiling py files to optimized bytecode ... Traceback (most recent call last): File "/var/opt/csw/cswclassutils/pycomp.318.20091104102411.py", line 143, in except PyCompileError: NameError: name 'PyCompileError' is not defined [ verifying class ] From bonivart at opencsw.org Wed Nov 4 11:17:35 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 4 Nov 2009 11:17:35 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: <200911040949.nA49n15n006224@dfki.uni-kl.de> References: <625385e30910280259y77676329u8fc476812b82e5dc@mail.gmail.com> <200911040949.nA49n15n006224@dfki.uni-kl.de> Message-ID: <625385e30911040217o753ad117hd160eedfe86fa955@mail.gmail.com> On Wed, Nov 4, 2009 at 10:49 AM, Nicolai Schwindt wrote: > [...] >> So please help test cswclassutils 1.27 in testing. Some packages to >> test with are: CSWclamav, CSWossh and CSWcacertificates. If you >> maintain packages that use cpsampleconf or preserveconf, please test >> them. >> >> http://mirror.opencsw.org/testing/cswclassutils-1.27,REV=2009.10.28-SunOS5.8- > all-CSW.pkg.gz > > Do you want this in mantis ? > > pkg-get -i trac > > ... > > Compiling py files to normal bytecode ... > Traceback (most recent call last): > ?File "/var/opt/csw/cswclassutils/pycomp.318.20091104102411.py", line 143, in > > ? ?except PyCompileError: > NameError: name 'PyCompileError' is not defined > Compiling py files to optimized bytecode ... > Traceback (most recent call last): > ?File "/var/opt/csw/cswclassutils/pycomp.318.20091104102411.py", line 143, in > > ? ?except PyCompileError: > NameError: name 'PyCompileError' is not defined > [ verifying class ] Please file a new bug, this is unrelated to what I wanted tested (cpsampleconf and preserveconf). This is about the pycompile script. -- /peter From dam at opencsw.org Wed Nov 4 12:11:27 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 12:11:27 +0100 Subject: [csw-maintainers] Unbound build error In-Reply-To: <4AF148F2.7050807@opencsw.org> References: <4AF148F2.7050807@opencsw.org> Message-ID: <9450D423-FC6B-4FBB-87F6-DE93A0AD2789@opencsw.org> Hi Ihsan, Am 04.11.2009 um 10:27 schrieb Ihsan Dogan: > Have been there any changes on the build system recently? > > While building unbound: > ./libtool --tag=CC --mode=link /opt/csw/gcc4/bin/gcc ./linktest.c -I. > -I. -I/opt/csw/include -I/opt/csw/include -DHAVE_CONFIG_H -I. -I. > -Wwrite-strings -W -Wall -O2 -g -O2 -pipe -mcpu=v8 -I/opt/csw/include > -std=c99 -D__EXTENSIONS__ -D_BSD_SOURCE -D_POSIX_C_SOURCE=200112 > -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE -lldns > -lnsl -lsocket -lcrypto -o linktest > libtool: link: /opt/csw/gcc4/bin/gcc ./linktest.c -I. -I. > -I/opt/csw/include -I/opt/csw/include -DHAVE_CONFIG_H -I. -I. > -Wwrite-strings -W -Wall -O2 -g -O2 -pipe -mcpu=v8 -I/opt/csw/include > -std=c99 -D__EXTENSIONS__ -D_BSD_SOURCE -D_POSIX_C_SOURCE=200112 > -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE -o > linktest > -lldns -lnsl -lsocket -lcrypto > ld: fatal: library -lldns: not found > ld: fatal: library -lcrypto: not found > ld: fatal: File processing errors. No output written to linktest Obviously -L/opt/csw/lib is missing here. When I try to reproduce it I cannot see this problem and I get a package. Some tests are failing though, which may or may not be related this issue. Additionally it looks like ldns_devel was not installed on the farm. Did you split off _devel lately? Anyway, I have installed CSWldnsdevel on all buildfarm servers. Best regards -- Dago From dam at opencsw.org Wed Nov 4 12:37:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 12:37:28 +0100 Subject: [csw-maintainers] Update of libevent and memcached In-Reply-To: References: Message-ID: <57C4220F-0C05-45AD-B025-305DE61331E4@opencsw.org> Hi Ben, Am 02.11.2009 um 14:09 schrieb Dagobert Michelsen: > Next thing I need is memcached. It needs stdbool and stdint which I > added from gnulib. However, the header files end up in lib/ and > are not added to the include path. Ben, would you please enlighten > me what is going wrong here? > > Additionally, I found these excellent Blog posts from Trond Norbye: > http://blogs.sun.com/trond/category/Memcached > regarding memcached on Solaris. Nice, but only starting from > OpenSolaris. I wonder if we can get the manifest and stuff for > our package. Trond fixed this upstream, so it will already be in the next version. Anyway, thanks Ben for your commitment :-) Best regards -- Dago From ihsan at dogan.ch Wed Nov 4 14:12:56 2009 From: ihsan at dogan.ch (Ihsan Dogan) Date: Wed, 04 Nov 2009 14:12:56 +0100 Subject: [csw-maintainers] Unbound build error In-Reply-To: <9450D423-FC6B-4FBB-87F6-DE93A0AD2789@opencsw.org> References: <4AF148F2.7050807@opencsw.org> <9450D423-FC6B-4FBB-87F6-DE93A0AD2789@opencsw.org> Message-ID: <4AF17DD8.1000302@dogan.ch> Hi Dago, On 04.11.2009 12:11, Dagobert Michelsen wrote: >> While building unbound: >> ./libtool --tag=CC --mode=link /opt/csw/gcc4/bin/gcc ./linktest.c -I. >> -I. -I/opt/csw/include -I/opt/csw/include -DHAVE_CONFIG_H -I. -I. >> -Wwrite-strings -W -Wall -O2 -g -O2 -pipe -mcpu=v8 -I/opt/csw/include >> -std=c99 -D__EXTENSIONS__ -D_BSD_SOURCE -D_POSIX_C_SOURCE=200112 >> -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE -lldns >> -lnsl -lsocket -lcrypto -o linktest >> libtool: link: /opt/csw/gcc4/bin/gcc ./linktest.c -I. -I. >> -I/opt/csw/include -I/opt/csw/include -DHAVE_CONFIG_H -I. -I. >> -Wwrite-strings -W -Wall -O2 -g -O2 -pipe -mcpu=v8 -I/opt/csw/include >> -std=c99 -D__EXTENSIONS__ -D_BSD_SOURCE -D_POSIX_C_SOURCE=200112 >> -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE -o linktest >> -lldns -lnsl -lsocket -lcrypto >> ld: fatal: library -lldns: not found >> ld: fatal: library -lcrypto: not found >> ld: fatal: File processing errors. No output written to linktest > > Obviously -L/opt/csw/lib is missing here. When I try to reproduce it > I cannot see this problem and I get a package. Some tests are > failing though, which may or may not be related this issue. > > Additionally it looks like ldns_devel was not installed on the farm. > Did you split off _devel lately? Anyway, I have installed CSWldnsdevel > on all buildfarm servers. After you have installed ldns_devel as well, but in the first place I've tried to build it against the builtin ldns library. In theory, this should work as well. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Wed Nov 4 14:13:28 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 04 Nov 2009 08:13:28 -0500 Subject: [csw-maintainers] pkginstall question In-Reply-To: <625385e30911040217o753ad117hd160eedfe86fa955@mail.gmail.com> References: <625385e30910280259y77676329u8fc476812b82e5dc@mail.gmail.com> <200911040949.nA49n15n006224@dfki.uni-kl.de> <625385e30911040217o753ad117hd160eedfe86fa955@mail.gmail.com> Message-ID: <1257340379-sup-4770@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Wed Nov 04 05:17:35 -0500 2009: > > Compiling py files to normal bytecode ... > > Traceback (most recent call last): > > ?File "/var/opt/csw/cswclassutils/pycomp.318.20091104102411.py", line 143, in > > > > ? ?except PyCompileError: > > NameError: name 'PyCompileError' is not defined > > Compiling py files to optimized bytecode ... > > Traceback (most recent call last): > > ?File "/var/opt/csw/cswclassutils/pycomp.318.20091104102411.py", line 143, in > > > > ? ?except PyCompileError: > > NameError: name 'PyCompileError' is not defined Yes, a new bug please. Please provide the version of python on your system as well. 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 ihsan at opencsw.org Wed Nov 4 15:29:58 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 04 Nov 2009 15:29:58 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <7D96D3D3-FA0A-40E1-9549-9114E56174DC@opencsw.org> References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> <4AD1C002.1050409@opencsw.org> <7D96D3D3-FA0A-40E1-9549-9114E56174DC@opencsw.org> Message-ID: <4AF18FE6.9040703@opencsw.org> Hello Dago, On 11.10.2009 14:00, Dagobert Michelsen wrote: >>> Let me know if you encounter anything unusual or feel the docs >>> need some clarification :-) >> >> I have two packages, ldns and unbound, which are build with gcc on >> Solaris 8, while the Solaris 10 version is built with Studio 12. >> >> Does this change has any influence to this very specific case? > > Yes! Please add > PACKAGING_PLATFORMS = solaris8-sparc solaris8-i386 solaris10-sparc > solaris10-i386 > to you Makefile. This tells GAR about all platforms you want packages > built on. Ok. Thanks for the hint. > It may needs additional tweaking. Have you committed all your local > changes? No, not yet. > Than I'd love to take a look and allow > gmake platforms > to automatically build packages for all 4 platforms without intervention. Something does not work yet. The Solaris 8 x86 package was built, but the Solaris 10 package fails: gmake: warning: Clock skew detected. Your build may be incomplete. gmake: Leaving directory `/home/ihsan/gar/csw/mgar/pkg/unbound/trunk' Connection to build8x closed. bash: gmake: command not found Connection to build10s closed. gmake: *** [platforms] Error 127 Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Wed Nov 4 15:35:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 15:35:19 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <4AF18FE6.9040703@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> Message-ID: Hi Ihsan, Am 04.11.2009 um 15:29 schrieb Ihsan Dogan: > On 11.10.2009 14:00, Dagobert Michelsen wrote: > >>>> Let me know if you encounter anything unusual or feel the docs >>>> need some clarification :-) >>> >>> I have two packages, ldns and unbound, which are build with gcc on >>> Solaris 8, while the Solaris 10 version is built with Studio 12. >>> >>> Does this change has any influence to this very specific case? >> >> Yes! Please add >> PACKAGING_PLATFORMS = solaris8-sparc solaris8-i386 solaris10-sparc >> solaris10-i386 >> to you Makefile. This tells GAR about all platforms you want packages >> built on. > > Ok. Thanks for the hint. > >> It may needs additional tweaking. Have you committed all your local >> changes? > > No, not yet. Please do, so that I can reproduce the problems. >> Than I'd love to take a look and allow >> gmake platforms >> to automatically build packages for all 4 platforms without >> intervention. > > Something does not work yet. The Solaris 8 x86 package was built, but > the Solaris 10 package fails: > > gmake: warning: Clock skew detected. Your build may be incomplete. > gmake: Leaving directory `/home/ihsan/gar/csw/mgar/pkg/unbound/trunk' > Connection to build8x closed. > bash: gmake: command not found > Connection to build10s closed. > gmake: *** [platforms] Error 127 Ok, what command have you issued at what host? Best regards -- Dago From dam at opencsw.org Wed Nov 4 16:29:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 16:29:28 +0100 Subject: [csw-maintainers] Package update: libgmp Message-ID: <70385B8A-E54B-4D89-B9EA-AF90C18786FB@opencsw.org> Hi, I have just finished recompiling libgmp with at least that many optimizations as the previous one :-) -rw-r--r-- 1 dam csw 701750 Nov 4 16:25 libgmp-4.3.1,REV=2009.11.04-SunOS5.8-i386-CSW.pkg.gz -rw-r--r-- 1 dam csw 866243 Nov 4 16:24 libgmp-4.3.1,REV=2009.11.04-SunOS5.8-sparc-CSW.pkg.gz Unfortunately, the new libraries now have a dependency to the gcc4 runtime: dam at login [login]:/home/dam/mgar/pkg/libgmp/trunk/work/solaris8-sparc/ pkgroot/opt/csw/lib > ldd libgmp.so libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /opt/csw/gcc4/lib/libgcc_s.so.1 libm.so.2 => /lib/libm.so.2 As the library can be used to compile gcc itself this may be unhandy. Feedback welcome! Best regards -- Dago From dam at opencsw.org Wed Nov 4 16:43:29 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 16:43:29 +0100 Subject: [csw-maintainers] Update of fftw In-Reply-To: <64BAD361-8556-4CF5-B6FD-F183D8C9A7D6@opencsw.org> References: <608B825C-14C2-4F48-9AD6-749E5FE4E9DA@opencsw.org> <64BAD361-8556-4CF5-B6FD-F183D8C9A7D6@opencsw.org> Message-ID: <2D2A97DD-86CD-4E9B-BF90-61127253B6D5@opencsw.org> Hi, Am 02.11.2009 um 21:56 schrieb Dagobert Michelsen: > as it seems of general interest here the repost on-list: > > Am 02.11.2009 um 17:51 schrieb Maciej (Matchek) Blizinski: >> On Mon, Nov 2, 2009 at 4:39 PM, Dagobert Michelsen >> wrote: >>>> Von: Dagobert Michelsen >>>> Datum: 2. November 2009 17:00:05 MEZ >>>> An: Joshua Buysse , Josh Buysse >>>> >>>> Kopie: Philip Brown >>>> Betreff: Update of fftw >>>> >>>> Hi Joshua, >>>> >>>> I have been playing around with fftw and made an updated package >>>> for fftw including the 3.2.2 version. Usually it is policy to >>>> add older libraries to the main package, but we already have the >>>> fftw2 package. So I guess it will be best to add an fftw3 package >>>> or should we go integrating both versioned libs in a main CSWfftw >>>> package? >> >> My first thought is that it's better to have one fftw package, >> including all the versions. >> >> Gentoo has a nice was of going around this. They have something >> called >> 'slots'. If multiple major versions of a package need to coexist, >> they >> occupy numbered slots. For instance, fftw-1.x would be assigned to >> slot 0, fftw-2.x to slot 1 and fftw-3.x to slot 2. We don't have the >> notion of slots, but we can merge multiple library versions in one >> package. I had to wrap my mind around version modulations in GAR, but >> it looks fairly easy now. (Until I run into problems again, that is. >> :-) ) >> >> I would be for providing one package with all the versions. >> >> Maciej >> >> P.S. Dago, you can loop this e-mail in with the rest of the >> discussion >> participants. Humm, no feedback yet. So I guess I make a version modulation for 2.x, put everything in fftw, make fftw2 depend on fftw and then make fftw2 an emty stub. On the other hand there are **NO** packages depending on fftw2, so can I skip including the old version? Josh: Be invited to release the updated package at will, just let me know :-) Phil: Are you ok with this? I don't want to package everything up just to redo things on submission ;-) Best regards -- Dago From ihsan at opencsw.org Wed Nov 4 16:47:40 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 04 Nov 2009 16:47:40 +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> Message-ID: <4AF1A21C.4060201@opencsw.org> Hello Dago, On 04.11.2009 15:35, Dagobert Michelsen wrote: >>> It may needs additional tweaking. Have you committed all your local >>> changes? >> No, not yet. > Please do, so that I can reproduce the problems. I just committed revision 7108. >>> Than I'd love to take a look and allow >>> gmake platforms >>> to automatically build packages for all 4 platforms without >>> intervention. >> Something does not work yet. The Solaris 8 x86 package was built, but >> the Solaris 10 package fails: >> >> gmake: warning: Clock skew detected. Your build may be incomplete. >> gmake: Leaving directory `/home/ihsan/gar/csw/mgar/pkg/unbound/trunk' >> Connection to build8x closed. >> bash: gmake: command not found >> Connection to build10s closed. >> gmake: *** [platforms] Error 127 > Ok, what command have you issued at what host? "gmake platforms" on build8s. Same happens on build10s. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From phil at bolthole.com Wed Nov 4 18:44:39 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 4 Nov 2009 09:44:39 -0800 Subject: [csw-maintainers] Update of fftw In-Reply-To: <2D2A97DD-86CD-4E9B-BF90-61127253B6D5@opencsw.org> References: <608B825C-14C2-4F48-9AD6-749E5FE4E9DA@opencsw.org> <64BAD361-8556-4CF5-B6FD-F183D8C9A7D6@opencsw.org> <2D2A97DD-86CD-4E9B-BF90-61127253B6D5@opencsw.org> Message-ID: Huh. I didnt noticed that the usual reply-to thing didnt kick in. Seems that i replied in private email to Dagobert on this subject. On Wed, Nov 4, 2009 at 7:43 AM, Dagobert Michelsen wrote: > > Phil: Are you ok with this? I don't want to package everything up just > to redo things on submission ;-) > From maciej at opencsw.org Wed Nov 4 21:38:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 4 Nov 2009 20:38:47 +0000 Subject: [csw-maintainers] GAR: tweaking distribution file names Message-ID: I have the following problem: The purveyor of software distributes binaries. There are different binaries for x86, amd64, sparcv8 and sparcv9, but they are all named the same: http://www.example.com/download/x86/foo http://www.example.com/download/amd64/foo http://www.example.com/download/sparcv8/foo http://www.example.com/download/sparcv9/foo I can't just say DISTFILES = foo, because there is an assumption that different files have distinct file names. I want to do some sort of mapping: DISTFILES = foo-$(GARVERSION)-x86 DISTFILES += foo-$(GARVERSION)-amd64 DISTFILES += foo-$(GARVERSION)-sparcv8 DISTFILES += foo-$(GARVERSION)-sparcv9 It means that I want to download http://www.example.com/download/x86/foo and after downloading it, rename it to foo-$(GARVERSION)-x86, and associate the checksum with foo-$(GARVERSION)-x86, not just foo. What's the most elegant way of going about it? I tried defining targets such as: $(DOWNLOADDIR)/foo-$(GARVERSION)-x86 ...but it did not work. gmake seems to be ignoring these targets. Help? Maciej From dam at opencsw.org Wed Nov 4 22:14:25 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 22:14:25 +0100 Subject: [csw-maintainers] GAR: tweaking distribution file names In-Reply-To: References: Message-ID: <8752ACC6-2202-4B04-8C26-5A46BE19A31F@opencsw.org> Hi Maciej, Am 04.11.2009 um 21:38 schrieb Maciej (Matchek) Blizinski: > I have the following problem: The purveyor of software distributes > binaries. There are different binaries for x86, amd64, sparcv8 and > sparcv9, but they are all named the same: > > http://www.example.com/download/x86/foo > http://www.example.com/download/amd64/foo > http://www.example.com/download/sparcv8/foo > http://www.example.com/download/sparcv9/foo > > I can't just say DISTFILES = foo, because there is an assumption that > different files have distinct file names. I want to do some sort of > mapping: > > DISTFILES = foo-$(GARVERSION)-x86 > DISTFILES += foo-$(GARVERSION)-amd64 > DISTFILES += foo-$(GARVERSION)-sparcv8 > DISTFILES += foo-$(GARVERSION)-sparcv9 > > It means that I want to download > http://www.example.com/download/x86/foo and after downloading it, > rename it to foo-$(GARVERSION)-x86, and associate the checksum with > foo-$(GARVERSION)-x86, not just foo. > > What's the most elegant way of going about it? I tried defining > targets such as: > > $(DOWNLOADDIR)/foo-$(GARVERSION)-x86 > > ...but it did not work. gmake seems to be ignoring these targets. Mmhhh, looks like the download-section needs some more work. There are other issues also with the current scheme when you have 10 files from 10 different locations where GAR tries every file at every location taking forever when you don't prime /home/src. What is in the files? Would they unpack to different directories? Or do you want modulation-specific sources? Best regards -- Dago From dam at opencsw.org Wed Nov 4 22:16:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 22:16:55 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <4AF1A21C.4060201@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> Message-ID: <25FB7213-E65F-4115-8DC9-50D57113E275@opencsw.org> Hi Ihsan, Am 04.11.2009 um 16:47 schrieb Ihsan Dogan: >>>> Than I'd love to take a look and allow >>>> gmake platforms >>>> to automatically build packages for all 4 platforms without >>>> intervention. >>> Something does not work yet. The Solaris 8 x86 package was built, >>> but >>> the Solaris 10 package fails: >>> >>> gmake: warning: Clock skew detected. Your build may be incomplete. >>> gmake: Leaving directory `/home/ihsan/gar/csw/mgar/pkg/unbound/ >>> trunk' >>> Connection to build8x closed. >>> bash: gmake: command not found >>> Connection to build10s closed. >>> gmake: *** [platforms] Error 127 >> Ok, what command have you issued at what host? > > "gmake platforms" on build8s. Same happens on build10s. I can reproduce it: > gmake: Leaving directory `/home/dam/mgar/pkg/unbound/trunk' > Connection to build8x closed. > zsh: command not found: gmake > Connection to build10s closed. I'll have a closer look tomorrow. Best regards -- Dago From phil at bolthole.com Wed Nov 4 22:28:28 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 4 Nov 2009 13:28:28 -0800 Subject: [csw-maintainers] X11 linkage problem strategy In-Reply-To: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> Message-ID: On Tue, Nov 3, 2009 at 7:35 AM, Dagobert Michelsen wrote: > > Maybe someone has a good solution on how to cope this in the general case. > Of course the trivial one would be to recompile everything needing x11 > against the CSW libs, which would pull in loads of stuff even if the > Solaris library would be sufficient. This was the core of my original reluctance to have these new libs in. I described explicitly that this sort of thing would be inevitable :-( Recompiling certain things for the newer, csw-bundled X11 libs will then become required.. not because those things themselves need the newer stuff... but because yet other packages, depend on the first set of packages, and also require the newer X11 libs :-( Technically, we dont need to require *everything* of ours that uses X11. But pretty close. Pretty much anything of ours that touches gnome libs... or anything of ours that is touched BY something that touches gnome libs... will need to be relinked now, I think :-( From maciej at opencsw.org Thu Nov 5 09:19:38 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 5 Nov 2009 08:19:38 +0000 Subject: [csw-maintainers] GAR: tweaking distribution file names In-Reply-To: <8752ACC6-2202-4B04-8C26-5A46BE19A31F@opencsw.org> References: <8752ACC6-2202-4B04-8C26-5A46BE19A31F@opencsw.org> Message-ID: On Wed, Nov 4, 2009 at 9:14 PM, Dagobert Michelsen wrote: > Mmhhh, looks like the download-section needs some more work. There are > other issues also with the current scheme when you have 10 files from > 10 different locations where GAR tries every file at every location > taking forever when you don't prime /home/src. > > What is in the files? Would they unpack to different directories? Or do > you want modulation-specific sources? The files are just binaries, they just need to be put into the packages as they are. There's no unpacking. Modulation-specific directories would do it, if the file names were different for each modulation. This scenario would work: http://www.example.com/download/x86/foo-x86 http://www.example.com/download/amd64/foo-amd64 http://www.example.com/download/sparcv8/foo-sparcv8 http://www.example.com/download/sparcv9/foo-sparcv9 But in this case we have: http://www.example.com/download/x86/foo http://www.example.com/download/amd64/foo http://www.example.com/download/sparcv8/foo http://www.example.com/download/sparcv9/foo I think that file renames are necessary. Maciej From dam at opencsw.org Thu Nov 5 11:08:38 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 5 Nov 2009 11:08:38 +0100 Subject: [csw-maintainers] X11 linkage problem strategy In-Reply-To: References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> Message-ID: Hi Phil, Am 04.11.2009 um 22:28 schrieb Philip Brown: > On Tue, Nov 3, 2009 at 7:35 AM, Dagobert Michelsen > wrote: >> >> Maybe someone has a good solution on how to cope this in the >> general case. >> Of course the trivial one would be to recompile everything needing >> x11 >> against the CSW libs, which would pull in loads of stuff even if the >> Solaris library would be sufficient. > > This was the core of my original reluctance to have these new libs in. > I described explicitly that this sort of thing would be inevitable :-( The problem is that we didn't introduce the dependency just for the kicks. Without them most the stuff from William simply wouldn't work on Solaris 8. > Recompiling certain things for the newer, csw-bundled X11 libs will > then become required.. not because those things themselves need the > newer stuff... but because yet other packages, depend on the first set > of packages, and also require the newer X11 libs :-( > > Technically, we dont need to require *everything* of ours that uses > X11. But pretty close. > > Pretty much anything of ours that touches gnome libs... or anything of > ours that is touched BY something that touches gnome libs... will need > to be relinked now, I think :-( It may be worthwhile to avoid this X11 dependency when we start with OpenSolaris or even Solaris 10. William? Best regards -- Dago From dam at opencsw.org Thu Nov 5 16:02:53 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 5 Nov 2009 16:02:53 +0100 Subject: [csw-maintainers] Enhanced pkgcheck in GAR Message-ID: Hi, with the putback of r7123 all produced packages by a recipe will now be checked at once. Errors about missing libs from uninstalled packages residing in a dependent built package should now no longer occur. Thanks to Ben for updating checkpkg so that GAR can make use of it! The following packages disable ENABLE_CHECK. Please remove this line and see if no errors reported on pkgcheck: bind botnet cacti clamav clearsilver cswutils cyrus_imapd dante dhcp dovecot gail graphviz htmldoc icinga jdk5 munin nagios nagvis ndoutils openssl1 php4 php5 pnp pysetuptools python sendmail xchat Best regards -- Dago From maciej at opencsw.org Thu Nov 5 17:02:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 5 Nov 2009 16:02:47 +0000 Subject: [csw-maintainers] Missing my_attribute.h from CSWmysql5devel In-Reply-To: <1250707455-sup-5092@ntdws12.chass.utoronto.ca> References: <1250703965-sup-847@ntdws12.chass.utoronto.ca> <1250704892-sup-1276@ntdws12.chass.utoronto.ca> <1250707455-sup-5092@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Aug 19, 2009 at 6:45 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Wed Aug 19 14:40:13 -0400 2009: > >> What I thought of doing is taking your mysql5 gar Makefile, and >> compiling mysql-5.0.x with it. Whether the new packages roughly match >> the old ones, can be checked by comparing the prototype files. I've >> done that when rewriting cups. What do you think about this idea? > > If you've got the time and energy, go for it. ?At the very least, it > would fix this bug with the current version of the package. ?I'm > hoping to have time in September to dig into the 5.1 stuff again. I spent some time working on 5.0.x; I've copied the existing 5.1 build and worked in a branch. I got it to build for 5.8 with 64-bit support. The package is reworked from the ground up. It contains different binary layout, and different ISAs support. Previously, there were pentium-specific x86 binaries. The new packages conform to our x86 + amd64 standard. I tried the new packages to be similar to the old ones, but some differences were inevitable. I still have things on my TODO list before the package is complete, but I decided to release it at its current state so that people could provide feedback. Maciej From dam at opencsw.org Thu Nov 5 17:16:42 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 5 Nov 2009 17:16:42 +0100 Subject: [csw-maintainers] Preview of the new mirror structure available Message-ID: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> Hi, I did some work towards the enhanced directory structure for the mirror we talked about. Goals: - subscription of master mirror layout should be kept unchanged - additional subscriptions should be cheap - mirroring allpkgs/ and experimental/ should be optional - Skripts to show deltas between catalogs - especially experimental- vs. testing vs. current - also between current freezes - put that information in README There are still some things to be done but I could also use some feedback now, so here it is :-) ** The intended layout looks like this: opencsw/ experimental/ / pkgs/ (confined to this directory) mytest.pkg.gz sparc/ 5.8/ mytest.pkg.gz (hardlinked to pkgs/mytest.pkg.gz) testing/ pkgs/ sparc/ 5.8/ distribution/ allcatalogs/ catalog-sparc-5.8-20091002 allpkgs/ mypkg.tar.gz stable/ sparc/ 5.8/ current/ sparc/ 5.8/ pkg.tar.gz (also hardlinked from allpkgs) freeze/ current-20091002/ README.20091002 sparc/ 5.8/ catalog pkg.tar.gz (hardlinked from allpkgs) 5.9/ pkg.tar.gz (symlinked to 5.8, same as in current/) current-20091003/ sparc/ ... current-20091004/ -> symlinked to current-20091003 if no change in catalog stable-20091004/ ... ** TBD: experimental/ should be filled with the subdirectories from what is now in testing/. Subdirectories can be created by each maintainer and for each folder a subproject is created in experimental which can be synced to separately. ** TBD: packages/ can the go from experimental/ to testing/ when no open issues persist. This can be used to drive servers. Only packages proven there can go to current/. See http://wiki.opencsw.org/automated-release-process for details. ** The repository is browsable via http://mirror.opencsw.org/opencsw/distribution/ Of course you can subscribe with pkg-get/pkgutil to it, but please be careful as the bandwith it limited to 2 MBit. ** rsync is available. Make sure you don't forget the -H to ** keep hardlinks when syncing! dam at shell [shell]:/home/dam > rsync rsync://mirror.opencsw.org/opencsw- withfreeze drwxr-xr-x 7 2009/10/30 15:34:22 . drwxr-xr-x 416 2009/10/30 13:28:29 allcatalogs drwxrwxr-x 6483 2009/10/28 23:54:53 allpkgs drwxrwxr-x 4 2009/10/28 23:54:46 current drwxr-xr-x 66 2009/10/30 16:57:31 freeze drwxr-xr-x 4 2008/10/24 21:10:13 stable ** TBD: There should be a readme in each freeze stating the changes: Layout README 20091003 ---------------------- Changes 20091003: Added packages: - mypkg-1.0.tar.gz Updated packages: - yourpkg 1.1 replace 1.0 Removed packages: - oldpkg 1.1 Changes 20091002: ... From maciej at opencsw.org Thu Nov 5 18:30:03 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 5 Nov 2009 17:30:03 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) Message-ID: I'm working on the MySQL-5.0.x package. I've reached a stage at which it can be installed and runs, as far as my testing has shown. It still has some rough edges, but it's usable. The package is reworked from the ground up. It contains different binary layout, and different ISAs support. Previously, there were pentium-specific x86 binaries. The new packages conform to our x86 + amd64 standard. I tried the new packages to be similar to the old ones, but some differences were inevitable. I still have things on my TODO list before the package is complete, but I decided to release it at its current state, so that feedback could be provided. Maciej From yann at pleiades.fr.eu.org Thu Nov 5 19:36:14 2009 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 05 Nov 2009 19:36:14 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> Message-ID: <4AF31B1E.80508@pleiades.fr.eu.org> Hi Dago, I successfully used your new system to build distinct packages for different architecture on multiple host and it works perfectly, thanks for your work. However I would like to use it for openssl to build the 64 libs (and not the whole package) on build10x, but I am not sure I understand how to do it. Could you explain me how to do it ? Yann Dagobert Michelsen a ?crit : > Hi, > > I just activated the new Platform build feature ("v2-pbuild") > in GAR. It is available under the regular name gar/v2 in the > repository, the old experimental branch gar/v2-build has been > deleted. A simple > svn update --ignore externals > should be sufficient to update your tree. The new features have > been documented at > > > (see "Prototype Modifiers"). > > Let me know if you encounter anything unusual or feel the docs > need some clarification :-) > > > Best regards > > -- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers From dam at opencsw.org Thu Nov 5 20:41:36 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 5 Nov 2009 20:41:36 +0100 Subject: [csw-maintainers] GAR Tutorial: Building OpenSSL with multiple ISAs In-Reply-To: <4AF31B1E.80508@pleiades.fr.eu.org> References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> <4AF31B1E.80508@pleiades.fr.eu.org> Message-ID: <68E829EC-A951-4D6D-A653-0E472786D6D7@opencsw.org> Hi Yann, Am 05.11.2009 um 19:36 schrieb Yann Rouillard: > I successfully used your new system to build distinct packages for > different architecture on multiple host and it works perfectly, > thanks for your work. > > However I would like to use it for openssl to build the 64 libs (and > not the whole package) on build10x, but I am not sure I understand > how to do it. Could you explain me how to do it ? Sure. I take the liberty of commenting some techniques on your Makefile: > ##################################################################### > # OpenCSW build recipe for OpenSSL > # > # Copyright 2009 Yann Rouillard > # All rights reserved. Use is subject to license terms. > # > # Redistribution and/or use, with or without modification, is > # permitted. This software is without warranty of any kind. The > # author(s) shall not be liable in the event that use of the > # software causes damage. > ##################################################################### > > ###### Package information ####### > > GARNAME = openssl > GARVERSION = 0.9.8k > OPENSSL_VERSION := $(shell echo $(GARVERSION) | sed -e 's/[a-z]//g') > OPENSSL_RELEASE := $(shell echo $(GARVERSION) | sed -e 's/[^a-z]//g') Why not OPENSSL_VESION = 0.9.8 OPENSSL_RELEASE = k GARVERSION = $(OPENSSL_VERSION)$(OPENSSL_RELEASE) But the used version is equally good. > CATEGORIES = lib > > DESCRIPTION = The Open Source toolkit for SSL and TLS > define BLURB > The OpenSSL Project is a collaborative effort to develop a robust, > commercial-grade, fully featured, and Open Source toolkit > implementing the > Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS > v1) as well > as a full-strength general-purpose cryptography library. > endef > > PACKAGES = CSWossl CSWosslrt CSWossldevel CSWosslutils > > SPKG_DESC_CSWossl = Openssl meta package > CATALOGNAME_CSWossl = openssl > REQUIRED_PKGS_CSWossl = CSWossldevel CSWosslutils CSWosslrt > > SPKG_DESC_CSWosslrt = Openssl runtime libraries > CATALOGNAME_CSWosslrt = openssl_rt > REQUIRED_PKGS_CSWosslrt = CSWcacertificates > > SPKG_DESC_CSWossldevel = Openssl development files > CATALOGNAME_CSWossldevel = openssl_devel > REQUIRED_PKGS_CSWossldevel = CSWosslrt > > SPKG_DESC_CSWosslutils = Openssl binaries and related tools > CATALOGNAME_CSWosslutils = openssl_utils > REQUIRED_PKGS_CSWosslutils = CSWosslrt > SPKG_CLASSES_CSWosslutils = none cswpreserveconf > > > ###### Upstream and opencsw files information ####### > > MASTER_SITES = http://www.openssl.org/source/ http://openssl.org/news/ > > # We define upstream file regex so we can be notifed of new upstream > software release > UFILES_REGEX = $(GARNAME)-(\d+(?:\.\d+)*[a-z]?).tar.gz > > DISTNAME = $(GARNAME)-$(GARVERSION) This is default, no need to redefine it. > DISTFILES = $(GARNAME)-$(GARVERSION).tar.gz > DISTFILES += CSWossl.prototype For this there is a more elegant way: dynamic prototypes where you specify the files for a package with regular expressions. This is more robust on version updates. Details can be found at or as practical examples at cd mgar/pkg grep PKGFILES */trunk/Makefile > DISTFILES += CSWosslrt.checkinstall CSWosslrt.preinstall > CSWosslrt.postinstall CSWosslrt.prototype-i386 CSWosslrt.prototype- > sparc > DISTFILES += CSWossldevel.prototype-i386 CSWossldevel.prototype-sparc > DISTFILES += CSWosslutils.prototype > DISTFILES += changelog.CSW README.CSW > > DOCFILES = CHANGES CHANGES.SSLeay PROBLEMS README FAQ README.ASN1 > INSTALL NEWS README.ENGINE > > PATCHFILES = openssl.$(OPENSSL_VERSION).patch > > > ##### Build and installation information ##### > > GARCOMPILER = SOS11 > > # The list of instructions set for which we will > # provide optimized libraries and binaries > EXTRA_BUILD_ISAS_i386 = pentium_pro amd64 > EXTRA_BUILD_ISAS_sparc = sparcv8plus+vis sparcv9 > > # we don't yet use isaexec support so we disable > # isa relocation for default isa > NO_ISAEXEC = 1 > # GAR wants and puts sparcv9 in lib/64 but openssl build system > # isn't the standard autoconf/automake one so we disable this > # relocation for now > ISALIBDIR_sparcv9 = . > libdir = /opt/csw/lib > > # we redefine the default merge exclude so *.a files are not excluded > MERGE_EXCLUDE_DEFAULT = $(MERGE_EXCLUDE_INFODIR) In gar.conf.mk the MERGE_EXCLUDE_DEFAULT is assembled from a list of items excluded by default. If you don't want a specific thing to be excluded it is easier to just clean the specific item you don't want excluded. In your cases this is MERGE_EXCLUDE_STATICLIBS = This way there is no need to adjust the definition when the default changes to exclude other things depending on the general packaging policy. > # The corresponding os/compiler to pass to the > # openssl Configure script > i386_OS_COMPILER = solaris-386-cc > pentium_OS_COMPILER = solaris-pentium-cc > pentium_pro_OS_COMPILER = solaris-pentium_pro-cc > amd64_OS_COMPILER = solaris64-x86_64-cc > > sparcv8_OS_COMPILER = solaris-sparcv8-cc > sparcv8plus_OS_COMPILER = solaris-sparcv9-cc > sparcv8plus+vis_OS_COMPILER = solaris-sparcv9+vis-cc > sparcv9_OS_COMPILER = solaris64-sparcv9-cc > > CONFIGURE_ARGS = --prefix=$(prefix) shared $($(ISA)_OS_COMPILER) -- > install_prefix=$(DESTDIR) > > # We want the csw perl to be used > #CONFIGURE_ENV += PERL="/opt/csw/bin/perl" > # For now we want the sun perl to be used > CONFIGURE_ENV += PERL="/usr/bin/perl" > > # Some optimization > EXT_CFLAGS += -mt -xstrconst > EXT_CXXFLAGS += -noex -mt > > # By default, the install target put man pages under > # /opt/csw/ssl/man, but we want them under /opt/csw/share/man > INSTALL_ARGS += MANDIR=$(mandir) > > # we include previous release of libraries file for comptability > purpose > OLDLIBS = 0.9.7m This can be done with version modulations. You can take a look at some package already implementing this: grep EXTRA_MODULATORS */trunk/Makefile | grep GARVERSION However, you must do a couple of things in different stages right, so I would really consider this an advanced topic. But feel free to take a look and ask if there are any problems :-) > SKIPTEST = 1 I would highly disregard turning tests on OpenSSL off. There were multiple instances where missing Sun Studio patches and too high optimization levels caused errors which were detected by the testsuite. If you don't want to wait for tests please do something like SKIPTEST=1 gmake package If we switch to automatic builds some time in the future running the testsuite will a good thing. If there are no tests define TEST_SCRIPTS = do indicate that there are no tests but the test-phase should be run. > # support for pkcs11 engine http://blogs.sun.com/chichang1/entry/how_to_integrate_pkcs11_engine > ifdef PKCS11 > PATCHFILES += pkcs11_engine-0.9.8h.patch.2008-07-29 > ifeq ($(GARCH),sparc) > ifeq ($(ISA),sparcv9) > CONFIGURE_ARGS += --pk11-libname=/usr/lib/ > sparcv9/libpkcs11.so > else > CONFIGURE_ARGS += --pk11-libname=/usr/lib/ > libpkcs11.so > endif > else > ifeq ($(ISA),amd64) > CONFIGURE_ARGS += --pk11-libname=/usr/lib/ > sparcv9/libpkcs11.so > else > CONFIGURE_ARGS += --pk11-libname=/usr/lib/ > libpkcs11.so > endif > endif Instead of this nested ifeqs you could simple write CONFIGURE_ARGS += --pk11-libname=$(abspath /usr/lib/$(MM_LIBDIR)) This expands to either '.' for 32 bit or '64' for 64 bit which is guaranteed to be linked to the arch-specific 64 bit dir sparcv9/ or amd64/. > endif > > include gar/category.mk > > > pre-configure-modulated: > echo " ==> Creating configure script" > cd $(WORKSRC) && ln -nf Configure configure > @$(MAKECOOKIE) > > # we remove every debug information except symbol table > # (should rather be done in the gar scripts) > post-install-modulated: > echo " ==> Stripping libraries" > chmod -R u+w $(DESTDIR)$(libdir) > find $(DESTDIR)$(libdir) -name "*.so*" -exec strip -x '{}' ';' > > install-changelog: > ginstall -D $(WORKROOTDIR)/build-$(firstword $(MODULATIONS))/ > changelog.CSW $(SPKG_PKGBASE)/changelog.CSW > @$(MAKECOOKIE) > > install-doc: > cd $(WORKSRC_FIRSTMOD)/ && ginstall $(DOCFILES) $ > (SPKG_PKGBASE)/ > ginstall -D $(WORKROOTDIR)/build-$(firstword $(MODULATIONS))/ > README.CSW $(SPKG_PKGBASE)/README.CSW > @$(MAKECOOKIE) > > install-certs: > [ -f $(PKGROOT)$(prefix)/ssl/openssl.cnf ] && \ > ginstall -D $(PKGROOT)$(prefix)/ssl/openssl.cnf $ > (PKGROOT)$(sysconfdir)/ssl/openssl.cnf.CSW > > install-oldlibs: $(addprefix install-oldlibs-,$(OLDLIBS)) > install-oldlibs-%: > @echo " ==> Installing old libraries $* from archive oldlibs. > $*-$(GARCH).tar.gz" > cd $(PKGROOT) && gunzip -c $(CURDIR)/$(FILEDIR)/oldlibs.$*-$ > (GARCH).tar.gz | tar xvf - > @$(MAKECOOKIE) > > post-merge: install-certs install-oldlibs install-changelog install- > doc Now your question again: > However I would like to use it for openssl to build the 64 libs (and > not the whole package) on build10x, but I am not sure I understand > how to do it. Could you explain me how to do it ? The manual process is build8x: gmake merge (builds 32 bit ISAs) build10x: gmake merge (builds 64 bit ISA) build8x: gmake package (assembles the package) With the new platform support you can just say build8x> gmake package and GAR automatically hops over to the server capable of building the ISA. All ISAs build in work//build-isa- and install to work//install-isa- These directories contain everything from 'make install' from each build. Now during the merge-phase an image of all packages to be built is assembled in work//pkgroot This is done during the merge phase. I talked about this in Oslo, slides linked from here: https://sourceforge.net/apps/trac/gar/wiki/Learning%20the%20details If you only want the libs you restrict the directories to be merged to the libdir: MERGE_DIRS_isa-extra = $(libdir) For examples see fftw or glpk or grep isa-extra */trunk/Makefile Don't hesitate to ask if you have further questions :-) Best regards -- Dago From ihsan at opencsw.org Thu Nov 5 20:51:11 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Thu, 05 Nov 2009 20:51:11 +0100 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: Message-ID: <4AF32CAF.1030805@opencsw.org> Hello Maciej, Am 5.11.2009 18:30 Uhr, Maciej (Matchek) Blizinski schrieb: > I'm working on the MySQL-5.0.x package. I've reached a stage at which > it can be installed and runs, as far as my testing has shown. It > still has some rough edges, but it's usable. Thank you very much for the updated packages. I'm installing them now in the new Database zone for the mail and web server. Is there any reason not to upgrade to 5.1? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Thu Nov 5 22:12:00 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 5 Nov 2009 21:12:00 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <4AF32CAF.1030805@opencsw.org> References: <4AF32CAF.1030805@opencsw.org> Message-ID: On Thu, Nov 5, 2009 at 7:51 PM, Ihsan Dogan wrote: > Hello Maciej, > > Am 5.11.2009 18:30 Uhr, Maciej (Matchek) Blizinski schrieb: > >> I'm working on the MySQL-5.0.x package. ?I've reached a stage at which >> it can be installed and runs, as far as my testing has shown. ?It >> still has some rough edges, but it's usable. > > Thank you very much for the updated packages. I'm installing them now in > the new Database zone for the mail and web server. > > Is there any reason not to upgrade to 5.1? There's no fundamental problem with it; the reason to work with 5.0 for now is that I want to focus on packaging alone at the moment. Once the packaging for 5.0.x is done, we'll move on and build 5.1. Maciej From ihsan at opencsw.org Thu Nov 5 22:25:50 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Thu, 05 Nov 2009 22:25:50 +0100 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: Message-ID: <4AF342DE.2020604@opencsw.org> Hello Maciej, Am 5.11.2009 18:30 Uhr, Maciej (Matchek) Blizinski schrieb: > I still have things on my TODO list before the package is complete, > but I decided to release it at its current state, so that feedback > could be provided. The script /opt/csw/mysql5/share/mysql/quick_start-csw should mention OpenCSW instead Denis' company. Same applies for /opt/csw/mysql5/share/mysql/doc/README.CSW . The init script tries to create the pid file in /opt/csw/mysql5/var. I think this should be either changed to $MYSQLD_DATADIR/mysql.pid. But besides that, it seems to work fine. :-) I'm wondering if it makes sense to build an optimized Solaris 10 binary with the optimisations mentioned on http://developers.sun.com/solaris/articles/mysql_perf_tune.html . Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Thu Nov 5 22:31:07 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Thu, 05 Nov 2009 22:31:07 +0100 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF32CAF.1030805@opencsw.org> Message-ID: <4AF3441B.6030006@opencsw.org> Am 5.11.2009 22:12 Uhr, Maciej (Matchek) Blizinski schrieb: >>> I'm working on the MySQL-5.0.x package. I've reached a stage at which >>> it can be installed and runs, as far as my testing has shown. It >>> still has some rough edges, but it's usable. >> Thank you very much for the updated packages. I'm installing them now in >> the new Database zone for the mail and web server. >> >> Is there any reason not to upgrade to 5.1? > There's no fundamental problem with it; the reason to work with 5.0 > for now is that I want to focus on packaging alone at the moment. Once > the packaging for 5.0.x is done, we'll move on and build 5.1. I see. Makes sense. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From phil at bolthole.com Fri Nov 6 00:55:03 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 5 Nov 2009 15:55:03 -0800 Subject: [csw-maintainers] comment/warning about sun studio 12.1 Message-ID: FYI, I read the following on a sun mailing list,and thought I should share the horror: ---------- What is "Sun Studio 12 update 1" and where did it come from? Sun Studio 12 update 1 is the latest major release of Sun Studio. The previous major release was Sun Studio 12. It is a completely different compiler from Sun Studio 12. SS12u1 has it's own patch stream that is disjoint from the patch stream for SS12. It took two years of effort by a large team of people to produce it. By all logic it should have been called Sun Studio 13, but management and marketing made a different choice. If SS12 was also available in the repo, users would need to be able to install both SS12 and SS12u1 at the same time to migrate their code gracefully. -------------- So... just be aware, and cautious, when the issue comes up. and as a final comment from that author: "The C compiler [itself, as in "cc -V"...] does have a sensible numeric-only version number that is monotonically increasing. (5.9 for SS12, 5.10 for SS12u1, and 5.11 for whatever is in SSnext.)" From phil at bolthole.com Fri Nov 6 00:58:38 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 5 Nov 2009 15:58:38 -0800 Subject: [csw-maintainers] Preview of the new mirror structure available In-Reply-To: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> References: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> Message-ID: On Thu, Nov 5, 2009 at 8:16 AM, Dagobert Michelsen wrote: > Hi, > > I did some work towards the enhanced directory structure for the mirror > we talked about. ... Hmm.. that was a bit difficult to follow. might be nice if you wrote it up somewhere online (yeah, that thing you hate doing, "mr. secretary" ;-) and perhaps described/summarized the directories with a condensed format, such as opencsw/experimental -- blahblah opencsw/testing -- blahaaaahh opencsw/distribution -- blah blah Maybe if you like, have that as the initial summary, then dig down more, lower down in the document? From phil at bolthole.com Fri Nov 6 01:00:35 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 5 Nov 2009 16:00:35 -0800 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <4AF342DE.2020604@opencsw.org> References: <4AF342DE.2020604@opencsw.org> Message-ID: On Thu, Nov 5, 2009 at 1:25 PM, Ihsan Dogan wrote: > > > I'm wondering if it makes sense to build an optimized Solaris 10 binary > with the optimisations mentioned on > http://developers.sun.com/solaris/articles/mysql_perf_tune.html . > > I would accept a multi-OS release set, if this effort were made (grmblegrumble) that is to say, like openssh, if you offered a sol [8/9] compiled package, and in addition, a separate sol10 compiled and optimized package. From trygvis at opencsw.org Fri Nov 6 07:54:38 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Fri, 06 Nov 2009 07:54:38 +0100 Subject: [csw-maintainers] comment/warning about sun studio 12.1 In-Reply-To: References: Message-ID: <4AF3C82E.5040303@opencsw.org> Philip Brown wrote: > FYI, I read the following on a sun mailing list,and thought I should > share the horror: > > > ---------- > > What is "Sun Studio 12 update 1" and where did it come from? > > Sun Studio 12 update 1 is the latest major release of Sun Studio. > The previous major release was Sun Studio 12. It is a completely > different compiler from Sun Studio 12. SS12u1 has it's own patch > stream that is disjoint from the patch stream for SS12. > It took two years of effort by a large team of people to produce it. > By all logic it should have been called Sun Studio 13, but management > and marketing made a different choice. If SS12 was also available > in the repo, users would need to be able to install both SS12 and SS12u1 > at the same time to migrate their code gracefully. > > -------------- Hey, that's just like Java! :D [snip} -- Trygve From dam at opencsw.org Fri Nov 6 09:37:04 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 6 Nov 2009 09:37:04 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <25FB7213-E65F-4115-8DC9-50D57113E275@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> Message-ID: <8853603E-D4FD-4534-8D3C-5781B3FC4286@opencsw.org> Hi Ihsan, Am 04.11.2009 um 22:16 schrieb Dagobert Michelsen: > Am 04.11.2009 um 16:47 schrieb Ihsan Dogan: >>>>> Than I'd love to take a look and allow >>>>> gmake platforms >>>>> to automatically build packages for all 4 platforms without >>>>> intervention. >>>> Something does not work yet. The Solaris 8 x86 package was built, >>>> but >>>> the Solaris 10 package fails: >>>> >>>> gmake: warning: Clock skew detected. Your build may be >>>> incomplete. >>>> gmake: Leaving directory `/home/ihsan/gar/csw/mgar/pkg/unbound/ >>>> trunk' >>>> Connection to build8x closed. >>>> bash: gmake: command not found >>>> Connection to build10s closed. >>>> gmake: *** [platforms] Error 127 >>> Ok, what command have you issued at what host? >> >> "gmake platforms" on build8s. Same happens on build10s. > > I can reproduce it: > >> gmake: Leaving directory `/home/dam/mgar/pkg/unbound/trunk' >> Connection to build8x closed. >> zsh: command not found: gmake >> Connection to build10s closed. > > I'll have a closer look tomorrow. The problem lies in the different configuration files for the shells. You use a bash, I use a zsh. As there is no real global configuration file that works with all shells I now appended /opt/csw/bin to the PATH when hopping over to another server. I just verified and commited as r7139 with your account :-) Best regards -- Dago From maciej at opencsw.org Fri Nov 6 11:43:59 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 6 Nov 2009 10:43:59 +0000 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: Message-ID: On Tue, Sep 15, 2009 at 6:14 PM, Maciej (Matchek) Blizinski wrote: > On Fri, Sep 11, 2009 at 5:04 PM, Philip Brown wrote: >> well,, there are multiple potential "issues" at play here. >> on the one hand, I understand your frustration at not having it >> normally in the path. >> But what would be the side effects of having a symlink >> /opt/csw/bin/mysql -> /opt/csw/mysql5/bin/mysql ? > > I was thinking about this... what if someone has mysql4 also > installed? I would like to rant a bit more about the nonstandard prefix. Yes, one might want to have both mysql4 and mysql5 installed. I don't know about mysql4, but the mysql5 package currently installs following symlinks: /opt/csw/lib/mysql --> ../mysql5/lib/mysql /opt/csw/include/mysql --> ../mysql5/include/mysql If mysql4 does the same, the two packages can't peacefully coexist. If mysql4 does not install the /opt/csw/lib/mysql symlink, why has mysql5 to? My way of thinking would be: There should be one canonical MySQL version for OpenCSW, which is being installed in /opt/csw. If there are other versions, say, legacy versions, they can be installed in different prefixes, but they are not allowed to install anything that conflicts with the canonical package. Having said that, I am going to continue to use /opt/csw/mysql5 for the mysql5 package. > Perhaps some sort of "switch" app, which would change the > symlinks, would be good. I need to think about it some more. Yes, it would be a nice thing to have. We could review existing solutions. I know that some Linux distributions already have implementations for such switches. Perhaps it's a good idea to look at them? Maciej From maciej at opencsw.org Fri Nov 6 11:51:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 6 Nov 2009 10:51:58 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> Message-ID: On Fri, Nov 6, 2009 at 12:00 AM, Philip Brown wrote: > On Thu, Nov 5, 2009 at 1:25 PM, Ihsan Dogan wrote: >> >> >> I'm wondering if it makes sense to build an optimized Solaris 10 binary >> with the optimisations mentioned on >> http://developers.sun.com/solaris/articles/mysql_perf_tune.html . >> >> > > I would accept a multi-OS release set, if this effort were made (grmblegrumble) > > that is to say, like openssh, if you offered a sol [8/9] compiled > package, and in addition, a separate sol10 compiled and optimized > package. Yes, it makes sense. Once the package is satisfactory in the basic form, we can go ahead and try add the optimization flags. Meanwhile, I started looking at the included unit tests. I don't know if the package was passing the tests previously, but I think it's a good idea to have all the unit tests pass. I suspect that the tests will need some porting or adjusting to Solaris. The first problem I'm seeing is: binlog_start_comment [ fail ] mysqltest: At line 13: query 'load data infile '../std_data_ln/words.dat' into table t1 -- load data to t1' failed: 1085: The file '/export/home/blizinski/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/build-isa-i386/mysql-5.0.84/mysql-test/var/std_data_ln/words' must be in the database directory or be readable by all The result from queries just before the failure was: reset master; drop table if exists t1,t2; create table t1 (word varchar(20)) -- create table t1; create table t2 (word varchar(20)) -- create table t2; load data infile '../std_data_ln/words.dat' into table t1 -- load data to t1; More results from queries before failure can be found in /export/home/blizinski/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/build-isa-i386/mysql-5.0.84/mysql-test/var/log/binlog_start_comment.log Aborting: binlog_start_comment failed in default mode. To continue, re-run with '--force'. Stopping All Servers gmake: *** [test-ns] Error 1 gmake: Leaving directory `/export/home/blizinski/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/build-isa-i386/mysql-5.0.84' Do people know if those tests were passing before and what has been done to make them pass? Maciej From maciej at opencsw.org Fri Nov 6 16:43:51 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 6 Nov 2009 15:43:51 +0000 Subject: [csw-maintainers] svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums' Message-ID: I have problems checking out the current svn tree: $ cd pkg $ svn up --ignore-externals (...) U pkg/openssl/trunk/Makefile svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums'; expected: 'd41d8cd98f00b204e9800998ecf8427e', actual: '176e3d3f8ba8154305a5c9628b05db03' Has anyone else encounter this problem? From dam at opencsw.org Fri Nov 6 16:53:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 6 Nov 2009 16:53:02 +0100 Subject: [csw-maintainers] svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums' In-Reply-To: References: Message-ID: Hi Maciej, Am 06.11.2009 um 16:43 schrieb Maciej (Matchek) Blizinski: > I have problems checking out the current svn tree: > > $ cd pkg > $ svn up --ignore-externals > (...) > U pkg/openssl/trunk/Makefile > svn: Checksum mismatch for > 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums'; expected: > 'd41d8cd98f00b204e9800998ecf8427e', actual: > '176e3d3f8ba8154305a5c9628b05db03' > > Has anyone else encounter this problem? Yes: > A bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED > svn: Checksum mismatch for 'bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/ > checksums'; expected: 'd41d8cd98f00b204e9800998ecf8427e', actual: > '176e3d3f8ba8154305a5c9628b05db03' This sucks. I guess it is time to open a ticket at SourceForge. Maciej, would you be so kind? I have to hurry to get my train back home. Best regards -- Dago From phil at bolthole.com Fri Nov 6 19:21:56 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 6 Nov 2009 10:21:56 -0800 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> Message-ID: On Fri, Nov 6, 2009 at 2:51 AM, Maciej (Matchek) Blizinski wrote: > > > Do people know if those tests were passing before and what has been > done to make them pass? when in doubt of facts.. verify them! :-) I think you should be able to run the tests on the old binaries if you install the old packages. and in fact, some of the packages might even include the tests. but not 100% sure. From phil at bolthole.com Fri Nov 6 19:25:58 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 6 Nov 2009 10:25:58 -0800 Subject: [csw-maintainers] X11 linkage problem strategy In-Reply-To: References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> Message-ID: On Thu, Nov 5, 2009 at 2:08 AM, Dagobert Michelsen wrote: > Hi Phil, > *wave* > Am 04.11.2009 um 22:28 schrieb Philip Brown: >>... >> Technically, we dont need to require *everything* of ours that uses >> X11. But pretty close. >> >> Pretty much anything of ours that touches gnome libs... or anything of >> ours that is touched BY something that touches gnome libs... will need >> to be relinked now, I think :-( > > It may be worthwhile to avoid this X11 dependency when we start with > OpenSolaris > or even Solaris 10. > I didnt quite understand what you meant here? From bwalton at opencsw.org Fri Nov 6 19:33:50 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 06 Nov 2009 13:33:50 -0500 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> Message-ID: <1257532118-sup-3145@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Nov 06 05:51:58 -0500 2009: > Meanwhile, I started looking at the included unit tests. I don't know > if the package was passing the tests previously, but I think it's a The set of failing tests is likely different, but I was finding issues with the 5.1 stuff when I looked at it. I do remember that the tests failing on i386 were different than those on sparc. > good idea to have all the unit tests pass. I suspect that the tests > will need some porting or adjusting to Solaris. The first problem I'm > seeing is: ...which is sad since this is a sun product. That is unless one of the opencsw libs it links against is causing the problems, anyway. > Do people know if those tests were passing before and what has been > done to make them pass? I don't know what the previous state of affairs was wrt this...Phil is right that it might be verifiable. Alternately, the old build could be redone without the packaging to see if the test suite was passing or not. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Nov 6 19:52:44 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 6 Nov 2009 10:52:44 -0800 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <1257532118-sup-3145@ntdws12.chass.utoronto.ca> References: <4AF342DE.2020604@opencsw.org> <1257532118-sup-3145@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 6, 2009 at 10:33 AM, Ben Walton wrote: > > I don't know what the previous state of affairs was wrt this...Phil is > right that it might be verifiable. ?Alternately, the old build could > be redone without the packaging to see if the test suite was passing > or not. > I'll also mention that mysql has historically been very picky about compiler optimization choices. When in serious doubt, compile with -xO0, and see if it mysteriously passes the tests. From bwalton at opencsw.org Fri Nov 6 19:58:53 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 06 Nov 2009 13:58:53 -0500 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> <1257532118-sup-3145@ntdws12.chass.utoronto.ca> Message-ID: <1257533883-sup-9466@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Nov 06 13:52:44 -0500 2009: > I'll also mention that mysql has historically been very picky about > compiler optimization choices. That's interesting. Thanks for sharing. If I get a few minutes tonight I'll try that with the 5.1 branch. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Nov 6 20:18:57 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 6 Nov 2009 11:18:57 -0800 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: Message-ID: On Fri, Nov 6, 2009 at 2:43 AM, Maciej (Matchek) Blizinski wrote: > ... > > I would like to rant a bit more about the nonstandard prefix. ?.. > > /opt/csw/lib/mysql --> ../mysql5/lib/mysql > /opt/csw/include/mysql --> ../mysql5/include/mysql > > If mysql4 does the same, the two packages can't peacefully coexist. If > mysql4 does not install the /opt/csw/lib/mysql symlink, why has mysql5 > to? > I think the idea there was that mysql5 was officially the "default mysql". That being said... we should probably discuss further, possibilities of more default mysql "presence" in the top level $PREFIX=/opt/csw style. And how to implement that. For example, while the back end DATABASE ENGINE, probably is best off in separate prefixland, client-side things are relatively binary compatible (or are they?) at the very least, having /opt/csw/bin/mysql (the client) -> /opt/csw/mysql5/bin/mysql is probably pretty safe. There can then be questions about whether symlinks for libraries in /opt/csw/lib would be appropriate. And then the question of whether to implement the links in the mysql5(_client/_rt) packages, or whether to have a "metapackage". > My way of thinking would be: There should be one canonical MySQL > version for OpenCSW, which is being installed in /opt/csw. If there > are other versions, say, legacy versions, they can be installed in > different prefixes, but they are not allowed to install anything that > conflicts with the canonical package. > > Having said that, I am going to continue to use /opt/csw/mysql5 for > the mysql5 package. Good :) Because handling renames/relocations, when things are not properly binary compatible, is a nightmare. From dam at opencsw.org Fri Nov 6 21:22:54 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 6 Nov 2009 21:22:54 +0100 Subject: [csw-maintainers] X11 linkage problem strategy In-Reply-To: References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> Message-ID: <7E0C2B9F-55DF-466D-B02B-ABAD4D340ECD@opencsw.org> Hi Phil, Am 06.11.2009 um 19:25 schrieb Philip Brown: > On Thu, Nov 5, 2009 at 2:08 AM, Dagobert Michelsen > wrote: >> Hi Phil, >> > > *wave* > >> Am 04.11.2009 um 22:28 schrieb Philip Brown: >>> ... >>> Technically, we dont need to require *everything* of ours that uses >>> X11. But pretty close. >>> >>> Pretty much anything of ours that touches gnome libs... or >>> anything of >>> ours that is touched BY something that touches gnome libs... will >>> need >>> to be relinked now, I think :-( >> >> It may be worthwhile to avoid this X11 dependency when we start with >> OpenSolaris >> or even Solaris 10. >> > > I didnt quite understand what you meant here? I mean that we may not need our own X11 when building packages for OpenSolaris in the future. Best regards -- Dago From ihsan at opencsw.org Fri Nov 6 21:34:56 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Fri, 06 Nov 2009 21:34:56 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <8853603E-D4FD-4534-8D3C-5781B3FC4286@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> Message-ID: <4AF48870.2040308@opencsw.org> Hello Dago, Am 6.11.2009 9:37 Uhr, Dagobert Michelsen schrieb: >>> gmake: Leaving directory `/home/dam/mgar/pkg/unbound/trunk' >>> Connection to build8x closed. >>> zsh: command not found: gmake >>> Connection to build10s closed. >> I'll have a closer look tomorrow. > The problem lies in the different configuration files for the shells. > You use > a bash, I use a zsh. As there is no real global configuration file that > works > with all shells I now appended /opt/csw/bin to the PATH when hopping > over to > another server. I just verified and commited as r7139 with your account :-) Thank you very much for fixing it. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Fri Nov 6 21:44:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 6 Nov 2009 20:44:01 +0000 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: Message-ID: On Fri, Nov 6, 2009 at 7:18 PM, Philip Brown wrote: > For example, while the back end DATABASE ENGINE, probably is best off > in separate prefixland, client-side things are relatively binary > compatible (or are they?) > > at the very least, having /opt/csw/bin/mysql (the client) ?-> > /opt/csw/mysql5/bin/mysql is probably pretty safe. That's what my new mysql5 package does. > There can then be questions about whether symlinks for libraries in > /opt/csw/lib would be appropriate. There is such symlink in the current mysql5 package, but I think that the database can do perfectly fine without it. Perhaps it was about compiling other, mysql-dependent software. Do you think it's better to keep the symlink or to remove it? I'm inclined to do the latter. Maciej From bwalton at opencsw.org Fri Nov 6 21:53:18 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 06 Nov 2009 15:53:18 -0500 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: Message-ID: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Nov 06 15:44:01 -0500 2009: > Do you think it's better to keep the symlink or to remove it? I'm > inclined to do the latter. I'd keep it. Somebody, somewhere, has a script that doesn't include /opt/csw/mysql5/bin in the PATH and relies on finding those symlinks. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Nov 6 22:33:24 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 6 Nov 2009 13:33:24 -0800 Subject: [csw-maintainers] X11 linkage problem strategy In-Reply-To: <7E0C2B9F-55DF-466D-B02B-ABAD4D340ECD@opencsw.org> References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> <7E0C2B9F-55DF-466D-B02B-ABAD4D340ECD@opencsw.org> Message-ID: On Fri, Nov 6, 2009 at 12:22 PM, Dagobert Michelsen wrote: >>... >> I didnt quite understand what you meant here? > > I mean that we may not need our own X11 when building packages for > OpenSolaris in the future. > > ah. well that goes back to the old, foundational issue of, "is it sane to attempt to support two codebases, via the same support system?" The answer I always found, was "no". due to supportability issues. and then it gets back to what Dennis was SUPPOSEDLY going to do, and split off a mirror tree dedicated to opensolaris based packages. Which does actually make sense. If people want to put in the split effort. Too bad Dennis decided he wanted to try to take everyone with him to the new one, rather than do a fair split of effort. From maciej at opencsw.org Sat Nov 7 00:43:26 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 6 Nov 2009 23:43:26 +0000 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 6, 2009 at 8:53 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Fri Nov 06 15:44:01 -0500 2009: > >> Do you think it's better to keep the symlink or to remove it? I'm >> inclined to do the latter. > > I'd keep it. ?Somebody, somewhere, has a script that doesn't include > /opt/csw/mysql5/bin in the PATH and relies on finding those symlinks. I think we are talking about different symlinks. The symlinks I'm thinking of removing is: /opt/csw/lib/mysql --> /opt/csw/mysql5/lib/mysql I can hardly see any use for it. It's not a symlink for binaries, only libraries. The symlinks to binaries, such as /opt/csw/bin/mysql --> /opt/csw/mysql5/bin/mysql, don't exist in the current package. I'm planning on including them in the new version of the package. Maciej From jeff at cjsa.com Sat Nov 7 05:51:08 2009 From: jeff at cjsa.com (Jeffery Small) Date: Sat, 7 Nov 2009 04:51:08 GMT Subject: [csw-maintainers] Library problems with gnome apps Message-ID: Hi: I was away for two and a half weeks. When I returned there were many new packages released. I have not installed everything, but I did upgrade some of the stand-alone applications and a few libraries upon which they relied. Now, I am finding that my firefox 3.5.3 and 3.5.5 browsers will not operate properly. These are the releases from the mozilla contrib website and were working fine previously. The browers now hang completely at any number of operations, the brower's pull-down menus will not display and most buttons do not operate. This is running on the native Solaris 10 gnome desktop on a SPARC system. I seem to remember a similar problem developing along these lines in the recent past, so I have some suspicion that it is related to the CSW upgrade. Here is a list of the packages I currently have NOT yet upgraded: ------------------------------------------------------------------------------- berkeleydb 4.7.25,REV=2009.07.01 4.7.25,REV=2009.10.18 berkeleydb3 3.3.11,REV=2009.07.22 3.3.11,REV=2009.10.18_rev=p2 berkeleydb4 4.2.52,REV=2005.04.28_rev=p4 4.2.52,REV=2009.10.18 berkeleydb44 4.4.20,REV=2009.07.28 4.4.20,REV=2009.10.18_rev=p4 curlrt 7.19.6,REV=2009.08.13 7.19.7,REV=2009.11.05 dbus 1.2.12,REV=2009.03.25 1.2.12,REV=2009.08.10 freetype2 2.3.8,REV=2009.02.16 2.3.9,REV=2009.09.11 fribidi 0.10.7 0.19.2,REV=2009.10.07 gdome2 0.8.1 0.8.1,REV=2009.09.11 jbig2dec 0.10,REV=2009.06.28 0.10,REV=2009.09.13 libcairo 1.8.6,REV=2009.06.25 1.8.8,REV=2009.09.15 libcroco 0.6.1 0.6.2,REV=2009.10.09 libdbus 1.2.12,REV=2009.03.25 1.2.12,REV=2009.08.10 libflac 1.2.1,REV=2009.04.09 1.2.1,REV=2009.09.05 libmad 0.15.1,REV=2005.03.26_rev=b 0.15.1b,REV=2009.10.29 libpango 1.24.3,REV=2009.07.09 1.24.5,REV=2009.09.04 libpcap 0.9.4,REV=2006.02.24sparconly 1.0.0,REV=2009.10.01 libpopt 1.14,REV=2009.02.24 1.15,REV=2009.10.29 libtasn1 2.1,REV=2009.04.17 2.2,REV=2009.11.05 libtheora 1.0,REV=2009.04.15 1.1.1,REV=2009.10.29 libtool 2.2.6,REV=2009.03.23_rev=a 2.2.6,REV=2009.09.04_rev=a libtool_rt 2.2.6,REV=2009.03.23_rev=a 2.2.6,REV=2009.09.04_rev=a libungif 4.1.4,REV=2007.02.05 4.1.6,REV=2009.09.24 sqlite3 3.6.10,REV=2009.03.28 3.6.19,REV=2009.10.29 sqlite3_rt 3.6.10,REV=2009.03.28 3.6.19,REV=2009.10.29 ------------------------------------------------------------------------------- Also, I still see the berkeleydb packages here, but there is STILL no updated sendmail package. I broke my sendmail the last time I tried to update the database packages and am still wondering if this compatibility issue has been addressed. I also see the dbus package. There has been an outstanding issue that keeps Solaris from properly shutting down as the dbus service cannot be stopped. Has that issue been addressed with this dbus release? These are both long-standing issues and I am wondering why I have not heard about their successful resolution. Did I miss some important discussions during the past few weeks? Thanks for any light you can shed on these issues. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From rupert at opencsw.org Sat Nov 7 10:36:01 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 7 Nov 2009 10:36:01 +0100 Subject: [csw-maintainers] svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums' In-Reply-To: References: Message-ID: <6af4270911070136j7b49d0c6wa2e50c4b2ae53f56@mail.gmail.com> On Fri, Nov 6, 2009 at 16:53, Dagobert Michelsen wrote: > Hi Maciej, > > Am 06.11.2009 um 16:43 schrieb Maciej (Matchek) Blizinski: > > I have problems checking out the current svn tree: >> >> $ cd pkg >> $ svn up --ignore-externals >> (...) >> U pkg/openssl/trunk/Makefile >> svn: Checksum mismatch for >> 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums'; expected: >> 'd41d8cd98f00b204e9800998ecf8427e', actual: >> '176e3d3f8ba8154305a5c9628b05db03' >> >> Has anyone else encounter this problem? >> > > Yes: > > A bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED >> svn: Checksum mismatch for >> 'bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums'; expected: >> 'd41d8cd98f00b204e9800998ecf8427e', actual: >> '176e3d3f8ba8154305a5c9628b05db03' >> > > This sucks. I guess it is time to open a ticket at SourceForge. Maciej, > would you be so kind? I have to hurry to get my train back home. > > > can we delete the tag in the repository itself by doing something like "svn rm https://.../bdb3/tags/..." ? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at opencsw.org Sat Nov 7 12:45:04 2009 From: james at opencsw.org (James Lee) Date: Sat, 07 Nov 2009 11:45:04 GMT Subject: [csw-maintainers] Preview of the new mirror structure available In-Reply-To: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> References: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> Message-ID: <20091107.11450400.3207873259@gyor.oxdrove.co.uk> On 05/11/09, 16:16:42, Dagobert Michelsen wrote regarding [csw-maintainers] Preview of the new mirror structure available: Is this a preview or a proposal? > opencsw/ > experimental/ > / > pkgs/ (confined to this directory) > mytest.pkg.gz > sparc/ > 5.8/ > mytest.pkg.gz (hardlinked to pkgs/mytest.pkg.gz) > testing/ > pkgs/ > sparc/ > 5.8/ Too complex and risky to be of any use to *users*. > distribution/ > allcatalogs/ > catalog-sparc-5.8-20091002 > allpkgs/ > mypkg.tar.gz This looks as if your proposal is to formalise the retention of all packages and catalogues (a collection's state). At first this seems like a good idea but think deeper and you will see that if all catalogues are kept there is no way of knowing which are erroneous, hence they all become useless. Actually there is a way of knowing because we keep the known good sets as stable releases which is already handled. > stable/ > sparc/ > 5.8/ > current/ > sparc/ > 5.8/ > pkg.tar.gz (also hardlinked from allpkgs) > freeze/ > current-20091002/ > README.20091002 > sparc/ > 5.8/ > catalog > pkg.tar.gz (hardlinked from allpkgs) > 5.9/ > pkg.tar.gz (symlinked to 5.8, same as in current/) This misunderstands the WIP nature of the snapshot process. The freeze is on unstable, it's not an entity it's unstable itself that is frozen. > ** TBD: experimental/ should be filled with the subdirectories from > what is now in testing/. > Subdirectories can be created by each maintainer and for each > folder a subproject > is created in experimental which can be synced to separately. > ** TBD: packages/ can the go from experimental/ to testing/ when no > open issues persist. How will you define "no open issues persist"? > This can be used to drive servers. Only packages proven there can > go to current/. See > http://wiki.opencsw.org/automated-release-process > for details. Here you draw parity to the Debian system. Previous discussion concluded the levels you show are not correct. "How stuff gets in there", conceptually and practically it doesn't because stable is a modified clone of another state done as an atomic operation. I feel we've lost sight of the aims of the proposal. James. From bwalton at opencsw.org Sat Nov 7 14:26:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 07 Nov 2009 08:26:12 -0500 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: <1257600163-sup-9626@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Nov 06 18:43:26 -0500 2009: > I think we are talking about different symlinks. The symlinks I'm > thinking of removing is: > > /opt/csw/lib/mysql --> /opt/csw/mysql5/lib/mysql Yes, sorry. I was talking about the bin/ symlinks. 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 Sat Nov 7 17:47:57 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 7 Nov 2009 16:47:57 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <4AF342DE.2020604@opencsw.org> References: <4AF342DE.2020604@opencsw.org> Message-ID: On Thu, Nov 5, 2009 at 9:25 PM, Ihsan Dogan wrote: > The script /opt/csw/mysql5/share/mysql/quick_start-csw should mention > OpenCSW instead Denis' company. Same applies for > /opt/csw/mysql5/share/mysql/doc/README.CSW . I split this document into a README.CSW and ChangeLog. I didn't want to change the existing text from Alex Moore. I added my own updates. > The init script tries to create the pid file in /opt/csw/mysql5/var. I > think this should be either changed to $MYSQLD_DATADIR/mysql.pid. I think I fixed it. Can you check? Updates packages are in testing/. Maciej From ihsan at opencsw.org Sat Nov 7 18:40:20 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sat, 07 Nov 2009 18:40:20 +0100 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> Message-ID: <4AF5B104.90307@opencsw.org> Hello Maciej, Am 7.11.2009 17:47 Uhr, Maciej (Matchek) Blizinski schrieb: >> The init script tries to create the pid file in /opt/csw/mysql5/var. I >> think this should be either changed to $MYSQLD_DATADIR/mysql.pid. > I think I fixed it. Can you check? Updates packages are in testing/. I just installed it and it works out of the box. mysql5test requires Perl, but it's not a dependency of mysql5test. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Sun Nov 8 11:04:36 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 8 Nov 2009 11:04:36 +0100 Subject: [csw-maintainers] Library problems with gnome apps In-Reply-To: References: Message-ID: Hi Jeffery, Am 07.11.2009 um 05:51 schrieb Jeffery Small: > I was away for two and a half weeks. When I returned there were > many new > packages released. I have not installed everything, but I did > upgrade some > of the stand-alone applications and a few libraries upon which they > relied. > Now, I am finding that my firefox 3.5.3 and 3.5.5 browsers will not > operate > properly. These are the releases from the mozilla contrib website > and were > working fine previously. The browers now hang completely at any > number of > operations, the brower's pull-down menus will not display and most > buttons > do not operate. This is running on the native Solaris 10 gnome > desktop on > a SPARC system. > > I seem to remember a similar problem developing along these lines in > the recent past, so I have some suspicion that it is related to the > CSW > upgrade. I also remember this, but only found this post in my mailbox. It may or may not be related to your problem, but you should check the bound libraries with ldd on the running process that no /opt/csw stuff is bound. > Anfang der weitergeleiteten E-Mail: > >> Von: "wrcarithers" >> Datum: 28. Juli 2009 17:52:53 MESZ >> An: solarisx86 at yahoogroups.com >> Betreff: [solarisx86] Re: Firefox 3.5.1 on Solaris 10? >> Antwort an: solarisx86 at yahoogroups.com >> >> I've been running 3.5.1 for over a week on Solaris 10 11/06, >> installed from the tarball version (not the package). The only >> issue that I ran into was with the Pango RC file (found in >> ~/.mozilla/firefox/etc/pango/pangorc on my system); for the past >> few releases of Firefox 3, the RC file has been clobbered the first >> time I start up a new release. I have to run the new release once, >> which overwrites the RC file; I then copy a backup version into the >> file, and the new release runs fine from then onward. My guess is >> that there's a library version conflict at the root of this >> problem, but I haven't taken the time to track it down. >> >> In some recent releases (3.0.10, 3.0.11, and 3.5), I've also had to >> modify the firefox startup script because of library version >> conflicts. I added moz_libdir (the install directory) to the front >> of LD_LIBRARY_PATH, and that took care of the conflicts. I did not >> have to do this for 3.5.1, however. >> >> - Warren > Also, I still see the berkeleydb packages here, but there is STILL no > updated sendmail package. I broke my sendmail the last time I tried > to > update the database packages and am still wondering if this > compatibility > issue has been addressed. Yes. Basically as the scheme we intended of unifying didn't work out we went the other way round: Splitting bdb as separate as possible by confining each release to a specific subdir and only linking stuff to /opt/csw/lib when required by old apps not yet updated. If you update bdb it should do no harm to your old sendmail. Apart from that Mike and Benny are still working on the updated sendmail to the best of my knowledge. Mike? Benny? > I also see the dbus package. There has been > an outstanding issue that keeps Solaris from properly shutting down > as the > dbus service cannot be stopped. Has that issue been addressed with > this > dbus release? These are both long-standing issues and I am > wondering why > I have not heard about their successful resolution. Did I miss some > important discussions during the past few weeks? Yes, you missed that one, it was fixed by William two month ago: Anfang der weitergeleiteten E-Mail: > Von: William Bonnet > Datum: 3. September 2009 23:01:27 MESZ > An: questions and discussions , internal > list for the CSW maintainers > Betreff: [csw-users] Important ! DBus update and bug fix > Antwort an: Questions and discussions > > Hi, > > A new version of the dbus packages will be pushed to current catalog > in the next hours. This version fixes the fllowing bug > > 0003626: dbus daemon will not stop on reboot/init 6 blocking the > shutdown ( http://opencsw.org/bugtrack/view.php?id=3626 ). > > > This bugs prevents dbus from stop correctly. If dbus is running, it > will be stop during update, thus update may freeze. In order to > avoid this situation, you have to be sure that you don't have dbus > running, or if it is running, you will have to kill it by hand > before the upgrade. You can retrieve the pid to kill with the > following command : > > bash-3.00# cat /opt/csw/var/run/dbus/pid > 1592 > > or > > bash-3.00# ps -elf | grep dbus-daemon > 0 S messageb 1592 1 0 40 20 ? 634 ? > 22:55:25 ? 0:00 /opt/csw/bin/dbus-daemon --system > > Please "kill -9" the dbus process before running package upgrade. > > Kind regards > W. Best regards -- Dago From dam at opencsw.org Sun Nov 8 11:23:56 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 8 Nov 2009 11:23:56 +0100 Subject: [csw-maintainers] Preview of the new mirror structure available In-Reply-To: <20091107.11450400.3207873259@gyor.oxdrove.co.uk> References: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> <20091107.11450400.3207873259@gyor.oxdrove.co.uk> Message-ID: <875DC6B7-42D7-4E97-B5E3-E2850AF371B6@opencsw.org> Hi James, Am 07.11.2009 um 12:45 schrieb James Lee: > On 05/11/09, 16:16:42, Dagobert Michelsen wrote regarding > [csw-maintainers] Preview of the new mirror structure available: > > Is this a preview or a proposal? A preview of the proposal ;-) > opencsw/ >> experimental/ >> / >> pkgs/ (confined to this directory) >> mytest.pkg.gz >> sparc/ >> 5.8/ >> mytest.pkg.gz (hardlinked to pkgs/mytest.pkg.gz) > >> testing/ >> pkgs/ >> sparc/ >> 5.8/ > > Too complex and risky to be of any use to *users*. Why "too complex"? The users just subscribe to a URL. The structure doesn't matter as long as they use pkg-get or pkgutil. Apart from that I think it easier than the current layout as it puts testing/ closed to current/. > distribution/ >> allcatalogs/ >> catalog-sparc-5.8-20091002 >> allpkgs/ >> mypkg.tar.gz > > This looks as if your proposal is to formalise the retention of all > packages and catalogues (a collection's state). At first this seems > like a good idea but think deeper and you will see that if all > catalogues are kept there is no way of knowing which are erroneous, > hence they all become useless. Actually there is a way of knowing > because we keep the known good sets as stable releases which is > already handled. My intentions are different. I want to solve two problems with it: 1. There is no official archive for all released package versions This is currently handled by http://csw.informatik.uni-erlangen.de/oldpkgs/ . While I think that Michael is doing a great job I would prefer that the project itself would keep an archive. allpkgs/ is my proposal to handle this. 2. When you install a package you are forced to upgrade other packages The larger customers of ours have own mirrors from where they install. However, the smaller installation just subscribe to current/. When an inexperienced admin just wants to add a package and by error updates the catalog there is no way other then to update the dependencies of the package to be installed as there is neither an unchanged location for scubscription nor the old archived catalog. The freezes are not meant as replacement for stable, but as substitute to subscribe to in addition to current/. >> stable/ >> sparc/ >> 5.8/ >> current/ >> sparc/ >> 5.8/ >> pkg.tar.gz (also hardlinked from allpkgs) >> freeze/ >> current-20091002/ >> README.20091002 >> sparc/ >> 5.8/ >> catalog >> pkg.tar.gz (hardlinked from allpkgs) >> 5.9/ >> pkg.tar.gz (symlinked to 5.8, same as in current/) > > This misunderstands the WIP nature of the snapshot process. The > freeze > is on unstable, it's not an entity it's unstable itself that is > frozen. Again: This has nothing to do with freezes needed to build stable. This whole rework of the layout is the result of the discussion we had on the founding meeting a year ago. I am just a bit slow... > ** TBD: experimental/ should be filled with the subdirectories from >> what is now in testing/. >> Subdirectories can be created by each maintainer and for each >> folder a subproject >> is created in experimental which can be synced to separately. > >> ** TBD: packages/ can the go from experimental/ to testing/ when no >> open issues persist. > > How will you define "no open issues persist"? That the maintainer of the packages doesn't know of any. Currently testing/ contains packages for which the maintainers _know_ that some things doesn't work but wants to test other things anyway. While it is useful to pkg- get from the testing-catalog it may not be useful for general testing. That's why I want to confine these specific-things-only testing to subdirs of experimental/ the maintainers can create at will and use whatever they think is good but restrict testing/ to packages that are good for testing by anyone who wants to help testing and every encountered issue is an unknown, actual bug. >> This can be used to drive servers. Only packages proven there can >> go to current/. See >> http://wiki.opencsw.org/automated-release-process >> for details. > > Here you draw parity to the Debian system. Previous discussion > concluded > the levels you show are not correct. > > "How stuff gets in there", conceptually and practically it doesn't > because stable is a modified clone of another state done as an atomic > operation. > > I feel we've lost sight of the aims of the proposal. It is a writedown of the discussion of Oslo. If you actually use cswrepo or another tool to moves packages there is up to you. If they are released atomically as a whole this is independent of the tool to move packages between catalogs. The core of the discussion was to formalize the moving of packages between catalogs, being the one from current to stable just an example. The important point is to have an API for tools to deliver to experimental/ and to move from experimental/ to testing/. Best regards -- Dago From james at opencsw.org Sun Nov 8 12:53:36 2009 From: james at opencsw.org (James Lee) Date: Sun, 08 Nov 2009 11:53:36 GMT Subject: [csw-maintainers] Preview of the new mirror structure available In-Reply-To: <875DC6B7-42D7-4E97-B5E3-E2850AF371B6@opencsw.org> References: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> <20091107.11450400.3207873259@gyor.oxdrove.co.uk> <875DC6B7-42D7-4E97-B5E3-E2850AF371B6@opencsw.org> Message-ID: <20091108.11533600.3521195917@gyor.oxdrove.co.uk> On 08/11/09, 10:23:56, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Preview of the new mirror structure available: > > opencsw/ > >> experimental/ > >> / > >> pkgs/ (confined to this directory) > >> mytest.pkg.gz > >> sparc/ > >> 5.8/ > >> mytest.pkg.gz (hardlinked to pkgs/mytest.pkg.gz) > > > >> testing/ > >> pkgs/ > >> sparc/ > >> 5.8/ > > > > Too complex and risky to be of any use to *users*. > Why "too complex"? The users just subscribe to a URL. The structure > doesn't > matter as long as they use pkg-get or pkgutil. Apart from that I think > it easier than the current layout as it puts testing/ closed to > current/. In overview, why would *users* want to and why would we do anything to encourage *users* to subscribe to these? We should *hide* these from *users* not distribute via mirrors. In overview, define the user's profiles and decide what type of package you think they should be using. > > distribution/ > >> allcatalogs/ > >> catalog-sparc-5.8-20091002 > >> allpkgs/ > >> mypkg.tar.gz > > > > This looks as if your proposal is to formalise the retention of all > > packages and catalogues (a collection's state). At first this seems > > like a good idea but think deeper and you will see that if all > > catalogues are kept there is no way of knowing which are erroneous, > > hence they all become useless. Actually there is a way of knowing > > because we keep the known good sets as stable releases which is > > already handled. > My intentions are different. I want to solve two problems with it: > 1. There is no official archive for all released package versions > This is currently handled by http://csw.informatik.uni-erlangen.de/oldpkgs/ > . > While I think that Michael is doing a great job I would prefer that the > project itself would keep an archive. allpkgs/ is my proposal to handle > this. So that intention is the same. > 2. When you install a package you are forced to upgrade other packages It's a feature, much thought about. > The larger customers of ours have own mirrors from where they install. > However, the smaller installation just subscribe to current/. That's their mistake. What are we doing to educate? > When an > inexperienced admin just wants to add a package and by error updates > the catalog there is no way other then to update the dependencies of > the package to be installed as there is neither an unchanged location > for scubscription nor the old archived catalog. The freezes are not > meant as replacement for stable, but as substitute to subscribe to > in addition to current/. So whatever state they first install they can continue to use for additions. It needs a state for every catalog issued. It would be better to designate landmark catalogs and keep just those - oh we do that already. Better to make the installer use a named catalogue then it can use a single bulk archive - or educate inexperienced admins. > > ** TBD: experimental/ should be filled with the subdirectories from > >> what is now in testing/. > >> Subdirectories can be created by each maintainer and for each > >> folder a subproject > >> is created in experimental which can be synced to separately. > > > >> ** TBD: packages/ can the go from experimental/ to testing/ when no > >> open issues persist. > > > > How will you define "no open issues persist"? > That the maintainer of the packages doesn't know of any. Currently > testing/ > contains packages for which the maintainers _know_ that some things > doesn't > work but wants to test other things anyway. While it is useful to pkg- > get > from the testing-catalog it may not be useful for general testing. > That's why I want to confine these specific-things-only testing to > subdirs of experimental/ the maintainers can create at will and use > whatever > they think is good but restrict testing/ to packages that are good for > testing by anyone who wants to help testing and every encountered issue > is an unknown, actual bug. I thought that's what testing was, and repeating myself it shouldn't have a catalogue, or if it does needs a health warning explaining that it's a sure way to shoot yourself in the foot. > >> This can be used to drive servers. Only packages proven there can > >> go to current/. See > >> http://wiki.opencsw.org/automated-release-process > >> for details. > > > > Here you draw parity to the Debian system. Previous discussion > > concluded > > the levels you show are not correct. > > > > "How stuff gets in there", conceptually and practically it doesn't > > because stable is a modified clone of another state done as an atomic > > operation. > > > > I feel we've lost sight of the aims of the proposal. > It is a writedown of the discussion of Oslo. Ah the Oslo Treaty, this must be like the Lisbon Treaty. > If you actually use > cswrepo or > another tool to moves packages there is up to you. If they are > released atomically as a whole this is independent of the tool to move > packages between catalogs. The core of the discussion was to formalize > the moving of packages between catalogs, We've only had one. "A catalog" represents a collection that should be integrated, there should be no concept of isolated additions and movements. OK that's what happens but don't formalise it as a concept. > being the one from current to > stable just an example. The important point is to have an API for tools > to deliver to experimental/ and to move from experimental/ to testing/. Important for what? Sorry I've lost track of how this is an aim of providing a service to users. (How one choses to implement a standard is one's choice, blah, blah, as agreed above.) Step 1: define the problem. James. From trygvis at opencsw.org Sun Nov 8 15:52:18 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 08 Nov 2009 15:52:18 +0100 Subject: [csw-maintainers] tofrodos in newpkgs/ Message-ID: <4AF6DB22.2090008@opencsw.org> Hi I've packages tofrodos which include a sorely missing dos2unix/unix2dos commands. tofrodos-1.7.8\,REV\=2009.11.08-SunOS5.8-* -- Trygve From james at opencsw.org Sun Nov 8 16:07:36 2009 From: james at opencsw.org (James Lee) Date: Sun, 08 Nov 2009 15:07:36 GMT Subject: [csw-maintainers] tofrodos in newpkgs/ In-Reply-To: <4AF6DB22.2090008@opencsw.org> References: <4AF6DB22.2090008@opencsw.org> Message-ID: <20091108.15073600.3743634814@gyor.oxdrove.co.uk> On 08/11/09, 14:52:18, "Trygve Laugst?l" wrote regarding [csw-maintainers] tofrodos in newpkgs/: > I've packages tofrodos which include a sorely missing dos2unix/unix2dos > commands. Just curious, sorely missing from what? $ which unix2dos /usr/bin/unix2dos $ which dos2unix /usr/bin/dos2unix $ man unix2dos Reformatting page. Please Wait... done User Commands unix2dos(1) NAME unix2dos - convert text file from ISO format to DOS format ... James. From trygvis at opencsw.org Sun Nov 8 17:10:00 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 08 Nov 2009 17:10:00 +0100 Subject: [csw-maintainers] tofrodos in newpkgs/ In-Reply-To: <20091108.15073600.3743634814@gyor.oxdrove.co.uk> References: <4AF6DB22.2090008@opencsw.org> <20091108.15073600.3743634814@gyor.oxdrove.co.uk> Message-ID: <4AF6ED58.5030204@opencsw.org> James Lee wrote: > On 08/11/09, 14:52:18, "Trygve Laugst?l" wrote > regarding [csw-maintainers] tofrodos in newpkgs/: > >> I've packages tofrodos which include a sorely missing dos2unix/unix2dos >> commands. > > Just curious, sorely missing from what? I'm always bitten by the shipped dos2unix can't replace the converted file. I guess you can say sorely missed by me :) -- Trygve From trygvis at opencsw.org Sun Nov 8 17:24:04 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 08 Nov 2009 17:24:04 +0100 Subject: [csw-maintainers] Undefined symbol __sync_fetch_and_add_4. Message-ID: <4AF6F0A4.60205@opencsw.org> 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 -- Trygve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: build.log URL: From james at opencsw.org Sun Nov 8 17:30:32 2009 From: james at opencsw.org (James Lee) Date: Sun, 08 Nov 2009 16:30:32 GMT Subject: [csw-maintainers] tofrodos in newpkgs/ In-Reply-To: <4AF6ED58.5030204@opencsw.org> References: <4AF6DB22.2090008@opencsw.org> <20091108.15073600.3743634814@gyor.oxdrove.co.uk> <4AF6ED58.5030204@opencsw.org> Message-ID: <20091108.16303200.2957062777@gyor.oxdrove.co.uk> On 08/11/09, 16:10:00, "Trygve Laugst?l" wrote regarding Re: [csw-maintainers] tofrodos in newpkgs/: > >> I've packages tofrodos which include a sorely missing dos2unix/unix2dos > >> commands. > > > > Just curious, sorely missing from what? > I'm always bitten by the shipped dos2unix can't replace the converted > file. I guess you can say sorely missed by me :) Thanks, so to clarify it's missing functionality and options rather than actually missing dos2unix/unix2dos commands. James. From rupert at opencsw.org Sun Nov 8 18:03:39 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 8 Nov 2009 18:03:39 +0100 Subject: [csw-maintainers] hg-1.4 tests fed back to mercurial Message-ID: <6af4270911080903o7e02d2d4w7141892115120b93@mail.gmail.com> hi, we gave the mercurial test feedback for the next version hg-1.4 to their mailing list, see: http://groups.google.com/group/mercurial_devel/browse_thread/thread/7916314a91431028 . rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Nov 8 19:23:06 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 8 Nov 2009 18:23:06 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <4AF5B104.90307@opencsw.org> References: <4AF342DE.2020604@opencsw.org> <4AF5B104.90307@opencsw.org> Message-ID: On Sat, Nov 7, 2009 at 5:40 PM, Ihsan Dogan wrote: > Hello Maciej, > > Am 7.11.2009 17:47 Uhr, Maciej (Matchek) Blizinski schrieb: > >>> The init script tries to create the pid file in /opt/csw/mysql5/var. I >>> think this should be either changed to $MYSQLD_DATADIR/mysql.pid. >> I think I fixed it. ?Can you check? ?Updates packages are in testing/. > > I just installed it and it works out of the box. > > mysql5test requires Perl, but it's not a dependency of mysql5test. Added: http://sourceforge.net/apps/trac/gar/changeset/7159 I'll wait a day or two before I update the packages in case there are more changes to make. Are there any other comments? Sebastian mentioned someone who was interested in collaborating on the MySQL package. I got us up to the point where we get something which passes the smoke test: we can install the package and it doesn't blow right after installation. That's a nice start, but it might still be a long way to go. I think the main current issue is getting the tests to pass. Do you think that it's worth working on the 5.0.x tests, or should we skip releasing 5.0.x and move on to 5.1 already? Maciej From dam at opencsw.org Sun Nov 8 21:27:59 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 8 Nov 2009 21:27:59 +0100 Subject: [csw-maintainers] hg-1.4 tests fed back to mercurial In-Reply-To: <6af4270911080903o7e02d2d4w7141892115120b93@mail.gmail.com> References: <6af4270911080903o7e02d2d4w7141892115120b93@mail.gmail.com> Message-ID: <1F161E3A-6756-4BFA-BE07-C54D1C536A1B@opencsw.org> Hi Rupert, Am 08.11.2009 um 18:03 schrieb rupert THURNER: > we gave the mercurial test feedback for the next version hg-1.4 to > their mailing list, see: http://groups.google.com/group/mercurial_devel/browse_thread/thread/7916314a91431028 > . Thanks for being a "good" maintainer :-) Please note the we offer upstream maintainer accounts for people who are only enhancing Solaris support upstream and don't intend to packge - just in case there is anyone in the project needing access to a Solaris machine. Best regards -- Dago -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at cjsa.com Sun Nov 8 23:09:01 2009 From: jeff at cjsa.com (Jeffery Small) Date: Sun, 8 Nov 2009 22:09:01 GMT Subject: [csw-maintainers] Library problems with gnome apps References: Message-ID: Dagobert Michelsen writes: >I also remember this [firefox problem], but only found this post in my >mailbox. It may or may not be related to your problem, but you should >check the bound libraries with ldd on the running process that no /opt/csw >stuff is bound. > [...] >Yes. Basically as the scheme we intended of unifying didn't work out >we went the other way round: Splitting bdb as separate as possible by >confining each release to a specific subdir and only linking stuff >to /opt/csw/lib when required by old apps not yet updated. If you update >bdb it should do no harm to your old sendmail. > [...] >Yes, you missed that one, it [dbus] was fixed by William two month ago: > [...] Dago: Thanks you very much for all the great information. I will take a closer look at the firefox problem and see if I can come up with any more specific answers regarding the libraries. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From ihsan at opencsw.org Sun Nov 8 23:47:11 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 08 Nov 2009 23:47:11 +0100 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> <4AF5B104.90307@opencsw.org> Message-ID: <4AF74A6F.6010004@opencsw.org> Am 8.11.2009 19:23 Uhr, Maciej (Matchek) Blizinski schrieb: >>>> The init script tries to create the pid file in /opt/csw/mysql5/var. I >>>> think this should be either changed to $MYSQLD_DATADIR/mysql.pid. >>> I think I fixed it. Can you check? Updates packages are in testing/. >> I just installed it and it works out of the box. >> >> mysql5test requires Perl, but it's not a dependency of mysql5test. > > Added: http://sourceforge.net/apps/trac/gar/changeset/7159 Thanks. > I'll wait a day or two before I update the packages in case there are > more changes to make. > > Are there any other comments? So far not. The package seems to work very well. > Sebastian mentioned someone who was interested in collaborating on the > MySQL package. I got us up to the point where we get something which > passes the smoke test: we can install the package and it doesn't blow > right after installation. That's a nice start, but it might still be > a long way to go. I think the main current issue is getting the tests > to pass. What do you mean with "it doesn't blow right after installation"? > Do you think that it's worth working on the 5.0.x tests, or should we > skip releasing 5.0.x and move on to 5.1 already? This package is an updated version of that, what we have already in our repository. I would release it and then concentrate on 5.1. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Sun Nov 8 23:58:56 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 8 Nov 2009 22:58:56 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <4AF74A6F.6010004@opencsw.org> References: <4AF342DE.2020604@opencsw.org> <4AF5B104.90307@opencsw.org> <4AF74A6F.6010004@opencsw.org> Message-ID: On Sun, Nov 8, 2009 at 10:47 PM, Ihsan Dogan wrote: > Am 8.11.2009 19:23 Uhr, Maciej (Matchek) Blizinski schrieb: >> Sebastian mentioned someone who was interested in collaborating on the >> MySQL package. ?I got us up to the point where we get something which >> passes the smoke test: we can install the package and it doesn't blow >> right after installation. ?That's a nice start, but it might still be >> a long way to go. ?I think the main current issue is getting the tests >> to pass. > > What do you mean with "it doesn't blow right after installation"? Um, I meant "blow up". I meant that the package works after you install it and start up the database. >> Do you think that it's worth working on the 5.0.x tests, or should we >> skip releasing 5.0.x and move on to 5.1 already? > > This package is an updated version of that, what we have already in our > repository. I would release it and then concentrate on 5.1. We didn't make the tests pass with the 5.0.x. We don't know if the 5.0.51,REV=2008.01.20 was passing the tests. If it wasn't, releasing my 5.0.84 would not mean any degradation in the QA of the package. If it was, it would be nice to know what was done to make the tests pass. I don't know if it makes sense to invest time in 5.0.x. tests if we're going to move on to 5.1 soon. Maciej From maciej at opencsw.org Mon Nov 9 10:18:35 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 09:18:35 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: <1255994929-sup-3@ntdws12.chass.utoronto.ca> References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: I worked on submitpkg some more, to give more comprehensive information. It started with Phil asking for notifying which packages were new. I implemented that, and then thought that if there are whole groups of packages updated together, they should also be grouped in the e-mail. It also tells about the kinds of upgrades: is it major version upgrade (e.g. 1.2 to 2.0) or minor version upgrade (1.2 to 1.3), or only a revision change. Here's current example output: ------------8<----------------- * WARNING: no version change + bender:/home/newpkgs/autoproject-0.20,REV=2009.11.05-SunOS5.8-all-CSW.pkg.gz * minor version upgrade - from: 1.3.9,REV=2008.11.08 - to: 1.4.1,REV=2009.11.02 + bender:/home/newpkgs/cupsdev-1.4.1,REV=2009.11.02-SunOS5.8-all-CSW.pkg.gz + bender:/home/newpkgs/cupsdoc-1.4.1,REV=2009.11.02-SunOS5.8-all-CSW.pkg.gz * new package: /dev/null -> 2.4.0,REV=2009.11.09 + bender:/home/newpkgs/py_cheetah-2.4.0,REV=2009.11.09-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/py_cheetah-2.4.0,REV=2009.11.09-SunOS5.8-sparc-CSW.pkg.gz ------------8<----------------- I also added unit tests. To test submitpkg from login.opencsw.org: svn co https://opencsw.svn.sourceforge.net/svnroot/opencsw/utilities cd utilities ./submit_to_newpkgs.py -h ./submit_to_newpkgs.py -p catalogname1,catalogname2,... Maciej From maciej at opencsw.org Mon Nov 9 10:46:07 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 09:46:07 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: <1255994929-sup-3@ntdws12.chass.utoronto.ca> References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: I worked on submitpkg some more, to give more comprehensive information. It started with Phil asking for notifying which packages were new. I implemented that, and then thought that if there are whole groups of packages updated together, they should also be grouped in the e-mail. It also tells about the kinds of upgrades: is it major version upgrade (e.g. 1.2 to 2.0) or minor version upgrade (1.2 to 1.3), or only a revision change. Here's current example output: ------------8<----------------- * WARNING: no version change + bender:/home/newpkgs/autoproject-0.20,REV=2009.11.05-SunOS5.8-all-CSW.pkg.gz * minor version upgrade - from: 1.3.9,REV=2008.11.08 - to: 1.4.1,REV=2009.11.02 + bender:/home/newpkgs/cupsdev-1.4.1,REV=2009.11.02-SunOS5.8-all-CSW.pkg.gz + bender:/home/newpkgs/cupsdoc-1.4.1,REV=2009.11.02-SunOS5.8-all-CSW.pkg.gz * new package: /dev/null -> 2.4.0,REV=2009.11.09 + bender:/home/newpkgs/py_cheetah-2.4.0,REV=2009.11.09-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/py_cheetah-2.4.0,REV=2009.11.09-SunOS5.8-sparc-CSW.pkg.gz ------------8<----------------- I also added unit tests. To test submitpkg: svn co https://opencsw.svn.sourceforge.net/svnroot/opencsw/utilities cd utilities ./submit_to_newpkgs.py -h ./submit_to_newpkgs.py -p catalogname1,catalogname2,... Maciej From maciej at opencsw.org Mon Nov 9 14:52:43 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 13:52:43 +0000 Subject: [csw-maintainers] py_cheetah: Python template engine in testing/ Message-ID: Cheetah is an Python templates engine. It allows to embed minimal flow control, so that things such as generating a list can be handled inside templates. http://mirror.opencsw.org/testing/py_cheetah-2.4.0,REV=2009.11.09-SunOS5.8-i386-CSW.pkg.gz http://mirror.opencsw.org/testing/py_cheetah-2.4.0,REV=2009.11.09-SunOS5.8-sparc-CSW.pkg.gz Maciej From dam at opencsw.org Mon Nov 9 17:09:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Nov 2009 17:09:19 +0100 Subject: [csw-maintainers] RFD: X11 linkage problem strategy In-Reply-To: References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> Message-ID: <6BA24589-C2D1-48E7-9B97-98C5FC8FFD65@opencsw.org> Hi, Am 04.11.2009 um 22:28 schrieb Philip Brown: > On Tue, Nov 3, 2009 at 7:35 AM, Dagobert Michelsen > wrote: >> Maybe someone has a good solution on how to cope this in the >> general case. >> Of course the trivial one would be to recompile everything needing >> x11 >> against the CSW libs, which would pull in loads of stuff even if the >> Solaris library would be sufficient. > > This was the core of my original reluctance to have these new libs in. > I described explicitly that this sort of thing would be inevitable :-( > > Recompiling certain things for the newer, csw-bundled X11 libs will > then become required.. not because those things themselves need the > newer stuff... but because yet other packages, depend on the first set > of packages, and also require the newer X11 libs :-( > > Technically, we dont need to require *everything* of ours that uses > X11. But pretty close. > > Pretty much anything of ours that touches gnome libs... or anything of > ours that is touched BY something that touches gnome libs... will need > to be relinked now, I think :-( How about distribution two sets of libraries for intermediate-libraries that may be linked against either x11 library like giflib? One like CSWcsw11_libgif bound against CSW X11 and located in /opt/csw/X11/lib, and CSWlibgif bound against Sun X11 as before. This would allow a clean separation between the two forms of libs. Best regards -- Dago From maciej at opencsw.org Mon Nov 9 17:11:06 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 16:11:06 +0000 Subject: [csw-maintainers] svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums' In-Reply-To: <6af4270911070136j7b49d0c6wa2e50c4b2ae53f56@mail.gmail.com> References: <6af4270911070136j7b49d0c6wa2e50c4b2ae53f56@mail.gmail.com> Message-ID: On Sat, Nov 7, 2009 at 9:36 AM, rupert THURNER wrote: > can we delete the tag in the repository itself by doing something like "svn > rm https://.../bdb3/tags/..." ? I tried something different: I cd'd into the bdb3-stub-to-bdb33-UNRELEASED directory, ran "svn up" -- it completed without errors. I went one level up, ran "svn up" again, it worked. Back to the 'pkg' level, svn up --ignore-externals -- it worked. I'm wondering it it would also work for other people. From maciej at opencsw.org Mon Nov 9 18:14:44 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 17:14:44 +0000 Subject: [csw-maintainers] Problems building CSWgar Message-ID: When building CSWgar, I'm getting this error message: Transferring package instance mkp: exec( gzip -9 -f /tmp/gar-7184,REV=2009.11.09-SunOS5.8-all-CSW.pkg ) mkp: exec( mv /tmp/gar-7184,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz /home/maciej/staging/build-2009-11-09 ) mkp: exec( rm -rf /home/maciej/spool.5.8-i386/CSWgar ) Examining /home/maciej/staging/build-2009-11-09/gar-7184,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz Looking for bad strings... for badpath in /export/medusa /opt/build ; do for badpath in /export/medusa /opt/build ; do ERROR: build-machine paths found in file /home/maciej/staging/build-2009-11-09/gar-7184,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz ($badpath) gmake: *** [pkgcheck] Error 2 Dago, I'm guessing you'll have an idea what's happening here. Maciej From bwalton at opencsw.org Mon Nov 9 18:20:11 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 09 Nov 2009 12:20:11 -0500 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: References: Message-ID: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Nov 09 12:14:44 -0500 2009: > When building CSWgar, I'm getting this error message: > Looking for bad strings... > for badpath in /export/medusa /opt/build ; do > for badpath in /export/medusa /opt/build ; do > > ERROR: build-machine paths found in file GAR contains checkpkg which contains those strings. Self fulfilling prophecy. Special case exemption would be in order, me thinks. -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 Mon Nov 9 18:30:00 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 9 Nov 2009 09:30:00 -0800 Subject: [csw-maintainers] RFD: X11 linkage problem strategy In-Reply-To: <6BA24589-C2D1-48E7-9B97-98C5FC8FFD65@opencsw.org> References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> <6BA24589-C2D1-48E7-9B97-98C5FC8FFD65@opencsw.org> Message-ID: On Mon, Nov 9, 2009 at 8:09 AM, Dagobert Michelsen wrote: > >> Pretty much anything of ours that touches gnome libs... or anything of >> ours that is touched BY something that touches gnome libs... will need >> to be relinked now, I think :-( > > How about distribution two sets of libraries for intermediate-libraries > that may be linked against either x11 library like giflib? One like > ?CSWcsw11_libgif > bound against CSW X11 and located in /opt/csw/X11/lib, and > ?CSWlibgif > bound against Sun X11 as before. This would allow a clean separation > between the two forms of libs. > oh yikes. you're talking about distributing two libgifs, two libjpegs, etc? Sounds like it ma be a headache, and possibly more headache than it is worth. I think it would be best if you did some research, and laid out just how many "intermediate libraries" we are talking about, and just how many packages would USE these retro-compiled packages. Depending on the number of affected packages, other options for affected packages might be: a) use solaris-shipped libs entirely (arent they available for sol8?) b) use static compiled versions of small libs, if number of affected packages is only a handful. OR, possibly still have the old way. but there is an issue of which version of libgif "belongs" in /opt/csw/lib. Probably the normal one I suppose, if we mandate that anything using /opt/csw/X11/lib must have that FIRST in its RPATH. From maciej at opencsw.org Mon Nov 9 18:49:16 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 17:49:16 +0000 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> References: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Nov 9, 2009 at 5:20 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Mon Nov 09 12:14:44 -0500 2009: >> When building CSWgar, I'm getting this error message: >> Looking for bad strings... >> ? ? ? ? for badpath in /export/medusa /opt/build ; do >> ? ? ? ? for badpath in /export/medusa /opt/build ; do >> >> ERROR: build-machine paths found in file > > GAR contains checkpkg which contains those strings. ?Self fulfilling > prophecy. ?Special case exemption would be in order, me thinks. Perhaps a little obfuscation, say, rot13 could help? for badpath in $(echo /rkcbeg/zrqhfn /bcg/ohvyq | gtr a-mn-z n-za-m); do ... Maciej From phil at bolthole.com Mon Nov 9 19:43:18 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 9 Nov 2009 10:43:18 -0800 Subject: [csw-maintainers] Preview of the new mirror structure available In-Reply-To: <875DC6B7-42D7-4E97-B5E3-E2850AF371B6@opencsw.org> References: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> <20091107.11450400.3207873259@gyor.oxdrove.co.uk> <875DC6B7-42D7-4E97-B5E3-E2850AF371B6@opencsw.org> Message-ID: On Sun, Nov 8, 2009 at 2:23 AM, Dagobert Michelsen wrote: > > The larger customers of ours have own mirrors from where they install. > However, the smaller installation just subscribe to current/. When an > inexperienced admin just wants to add a package and by error updates > the catalog there is no way other then to update the dependencies of > the package to be installed as there is neither an unchanged location > for scubscription nor the old archived catalog. and for the vast majority of customers, this is a GOOD THING! This is a "feature", not a bug! It is detrimental to have out of date, older versions of things. It is only at sites where they have to be really really careful about upgrades and changes, that this behaviour is a problem. We should make sure that we optimize for the common best case. We should also give mechanisms for the "picky sites" to accomplish what they need to do from our packages. However, if we just had regular "stable" releases again, we would accomplish this pretty well. > The freezes are not > meant as replacement for stable, but as substitute to subscribe to > in addition to current/. Perhaps you meant "as an alternative choice to current". From phil at bolthole.com Mon Nov 9 19:57:21 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 9 Nov 2009 10:57:21 -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> Message-ID: On Sun, Nov 8, 2009 at 2:58 PM, Maciej (Matchek) Blizinski wrote: > > We didn't make the tests pass with the 5.0.x. ?We don't know if the > 5.0.51,REV=2008.01.20 was passing the tests. ?If it wasn't, releasing > my 5.0.84 would not mean any degradation in the QA of the package. ?If > it was, it would be nice to know what was done to make the tests pass. > ?I don't know if it makes sense to invest time in 5.0.x. tests if > we're going to move on to 5.1 soon. i agree that so long as your 5.0.x version passes *at least the same tests as our existing package*, it is fine to release,and then focus efforts on 5.1 the only remaining question is, which tests does our existing pass? From maciej at opencsw.org Mon Nov 9 20:43:43 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 19:43:43 +0000 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: References: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Nov 9, 2009 at 5:49 PM, Maciej (Matchek) Blizinski wrote: > On Mon, Nov 9, 2009 at 5:20 PM, Ben Walton wrote: >> Excerpts from Maciej (Matchek) Blizinski's message of Mon Nov 09 12:14:44 -0500 2009: >>> When building CSWgar, I'm getting this error message: >>> Looking for bad strings... >>> ? ? ? ? for badpath in /export/medusa /opt/build ; do >>> ? ? ? ? for badpath in /export/medusa /opt/build ; do >>> >>> ERROR: build-machine paths found in file >> >> GAR contains checkpkg which contains those strings. ?Self fulfilling >> prophecy. ?Special case exemption would be in order, me thinks. > > Perhaps a little obfuscation, say, rot13 could help? > > for badpath in $(echo /rkcbeg/zrqhfn /bcg/ohvyq | gtr a-mn-z n-za-m); do ... I've found out that there are two checkpkg instances, one in CSWcswutils, and one in gar/v2/bin. Is it intended? Anyway, I updated both of them and bumped the version of CSWcswutils. I think I'll have to wait until the updated package (>=cswutils-1.14.6) is installed on the buildfarm. Maciej From dam at opencsw.org Mon Nov 9 21:47:40 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Nov 2009 21:47:40 +0100 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: References: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> Message-ID: Hi Maciej, Am 09.11.2009 um 20:43 schrieb Maciej (Matchek) Blizinski: > On Mon, Nov 9, 2009 at 5:49 PM, Maciej (Matchek) Blizinski > wrote: >> On Mon, Nov 9, 2009 at 5:20 PM, Ben Walton >> wrote: >>> Excerpts from Maciej (Matchek) Blizinski's message of Mon Nov 09 >>> 12:14:44 -0500 2009: >>>> When building CSWgar, I'm getting this error message: >>>> Looking for bad strings... >>>> for badpath in /export/medusa /opt/build ; do >>>> for badpath in /export/medusa /opt/build ; do >>>> >>>> ERROR: build-machine paths found in file >>> >>> GAR contains checkpkg which contains those strings. Self fulfilling >>> prophecy. Special case exemption would be in order, me thinks. >> >> Perhaps a little obfuscation, say, rot13 could help? >> >> for badpath in $(echo /rkcbeg/zrqhfn /bcg/ohvyq | gtr a-mn-z n-za- >> m); do ... > > I've found out that there are two checkpkg instances, one in > CSWcswutils, and one in gar/v2/bin. Is it intended? Let me put it this way: I am aware of it :-) It was already this way when I took over GAR. It may be better to rely on CSWcswutils and let GAR depend on the package. > Anyway, I updated both of them and bumped the version of CSWcswutils. > I think I'll have to wait until the updated package > (>=cswutils-1.14.6) is installed on the buildfarm. Um, no, as GAR depends on the checkpkg inside the repository. Thanks! -- Dago From dam at opencsw.org Mon Nov 9 21:51:44 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Nov 2009 21:51:44 +0100 Subject: [csw-maintainers] svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums' In-Reply-To: References: <6af4270911070136j7b49d0c6wa2e50c4b2ae53f56@mail.gmail.com> Message-ID: Hi Maciej, Am 09.11.2009 um 17:11 schrieb Maciej (Matchek) Blizinski: > On Sat, Nov 7, 2009 at 9:36 AM, rupert THURNER > wrote: >> can we delete the tag in the repository itself by doing something >> like "svn >> rm https://.../bdb3/tags/..." ? > > I tried something different: I cd'd into the > bdb3-stub-to-bdb33-UNRELEASED directory, ran "svn up" -- it completed > without errors. I went one level up, ran "svn up" again, it worked. > Back to the 'pkg' level, svn up --ignore-externals -- it worked. > > I'm wondering it it would also work for other people. Yes, it does. SVN does feel strange from time to time. I do keep a backup of the tree around, have to check some time... Best regards -- Dago From maciej at opencsw.org Mon Nov 9 21:52:02 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 20:52:02 +0000 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: References: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Nov 9, 2009 at 8:47 PM, Dagobert Michelsen wrote: >> Anyway, I updated both of them and bumped the version of CSWcswutils. >> I think I'll have to wait until the updated package >> (>=cswutils-1.14.6) is installed on the buildfarm. > > Um, no, as GAR depends on the checkpkg inside the repository. After updating the checkpkg inside GAR, I tried to build the package and it failed, I think it was running the one in /opt/csw/bin. This time there were no two lines with "for badpath in /export/medusa /opt/build ; do", but only one: Examining /home/maciej/staging/build-2009-11-09/gar-7186,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz Looking for bad strings... for badpath in /export/medusa /opt/build ; do ERROR: build-machine paths found in file /home/maciej/staging/build-2009-11-09/gar-7186,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz ($badpath) gmake: *** [pkgcheck] Error 2 Maciej From dam at opencsw.org Mon Nov 9 21:57:21 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Nov 2009 21:57:21 +0100 Subject: [csw-maintainers] Preview of the new mirror structure available In-Reply-To: References: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> <20091107.11450400.3207873259@gyor.oxdrove.co.uk> <875DC6B7-42D7-4E97-B5E3-E2850AF371B6@opencsw.org> Message-ID: <9D9463F3-59F8-4B58-BDAE-8CA5299CCDA3@opencsw.org> Hi Phil, Am 09.11.2009 um 19:43 schrieb Philip Brown: > On Sun, Nov 8, 2009 at 2:23 AM, Dagobert Michelsen > wrote: >> >> The larger customers of ours have own mirrors from where they >> install. >> However, the smaller installation just subscribe to current/. When an >> inexperienced admin just wants to add a package and by error updates >> the catalog there is no way other then to update the dependencies of >> the package to be installed as there is neither an unchanged location >> for scubscription nor the old archived catalog. > > and for the vast majority of customers, this is a GOOD THING! This is > a "feature", not a bug! > It is detrimental to have out of date, older versions of things. > > It is only at sites where they have to be really really careful about > upgrades and changes, that this behaviour is a problem. > > We should make sure that we optimize for the common best case. > > We should also give mechanisms for the "picky sites" to accomplish > what they need to do from our packages. However, if we just had > regular "stable" releases again, we would accomplish this pretty well. Now that we talk about it I remember that I wanted to do this initially for stable: Keep released versions so that shops can upgrade at the pace they want instead of the release cycle. Apart from that: There are troubled waters ahead. Most server packages need updating, we have no build recipes for the existing ones, the directory layout will change away from /opt/csw to /etc and /var, version upgrades may be incompatible. There are at least SASL, OpenLDAP, Kerberos and Postgres that will likely break on upgrade. But this only slightly related to the freezes. I'll open another thread when I'm ready for this. >> The freezes are not >> meant as replacement for stable, but as substitute to subscribe to >> in addition to current/. > > Perhaps you meant "as an alternative choice to current". ?h, yes. Didn't I say that? Anyway, that's what I meant. Best regards -- Dago From dam at opencsw.org Mon Nov 9 22:09:39 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Nov 2009 22:09:39 +0100 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: References: Message-ID: Hi Maciej, Am 09.11.2009 um 18:14 schrieb Maciej (Matchek) Blizinski: > When building CSWgar, I'm getting this error message: > > Transferring package instance > mkp: exec( gzip -9 -f /tmp/gar-7184,REV=2009.11.09-SunOS5.8-all- > CSW.pkg ) > mkp: exec( mv /tmp/gar-7184,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz > /home/maciej/staging/build-2009-11-09 ) > mkp: exec( rm -rf /home/maciej/spool.5.8-i386/CSWgar ) > Examining /home/maciej/staging/build-2009-11-09/ > gar-7184,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz > Looking for bad strings... > for badpath in /export/medusa /opt/build ; do > for badpath in /export/medusa /opt/build ; do > > ERROR: build-machine paths found in file > /home/maciej/staging/build-2009-11-09/gar-7184,REV=2009.11.09- > SunOS5.8-all-CSW.pkg.gz > ($badpath) > gmake: *** [pkgcheck] Error 2 > > Dago, I'm guessing you'll have an idea what's happening here. Yes. I. Why the built broke When I changed to a single invocation of checkpkg I needed to change the logic and evaluation of the ENABLE_CHECK variable. In the past there was a check if it was "0" or not. I changed this to "TRUE" (meaning not-empty) to conform to the other variables which I forgot to change hear. It shouldn't harm to check anyway. This means that everywere where ENABLE_CHECK=0 was written there should be now ENABLE_CHECK= II. The Makefile of the GAR package As I was aware of the problem I chose to disable checking. This is already done in the Makefile as it contains the lines > # Because the bad pathes are in the bad pathes check we cannot check > ourselves > ENABLE_CHECK = 0 This stopped working with the change I. and I took this out now with your fix. III. The check The check for bad pathes must be reworked completely as the pathes were made to fit the previous project. As OpenCSW has other pathes the existing ones must be replaced. Best regards -- Dago From dam at opencsw.org Mon Nov 9 22:10:20 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Nov 2009 22:10:20 +0100 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: References: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> Message-ID: Hi Maciej, Am 09.11.2009 um 21:52 schrieb Maciej (Matchek) Blizinski: > On Mon, Nov 9, 2009 at 8:47 PM, Dagobert Michelsen > wrote: >>> Anyway, I updated both of them and bumped the version of >>> CSWcswutils. >>> I think I'll have to wait until the updated package >>> (>=cswutils-1.14.6) is installed on the buildfarm. >> >> Um, no, as GAR depends on the checkpkg inside the repository. > > After updating the checkpkg inside GAR, I tried to build the package > and it failed, I think it was running the one in /opt/csw/bin. This > time there were no two lines with "for badpath in /export/medusa > /opt/build ; do", but only one: > > Examining /home/maciej/staging/build-2009-11-09/ > gar-7186,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz > Looking for bad strings... > for badpath in /export/medusa /opt/build ; do > > ERROR: build-machine paths found in file > /home/maciej/staging/build-2009-11-09/gar-7186,REV=2009.11.09- > SunOS5.8-all-CSW.pkg.gz > ($badpath) > gmake: *** [pkgcheck] Error 2 He he: build8s% find . | xargs grep medusa ./src/gar/v1/bin/checkpkg: for badpath in /export/medusa /opt/ build ; do I merged r7186 over to v1 as r7189. The gar package build works now and checks itself :-) Best regards -- Dago From maciej at opencsw.org Tue Nov 10 01:49:05 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 10 Nov 2009 00:49:05 +0000 Subject: [csw-maintainers] Double depends problem Message-ID: It happens quite often that packages I build with GAR end up having double depends. Can we have automation around that? We could have checkpkg verify that there are no double depends. We could also have some mechanism in GAR that would force the depends list to be unique. Ideally, we would have both those things. Maciej From maciej at opencsw.org Tue Nov 10 01:58:21 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 10 Nov 2009 00:58:21 +0000 Subject: [csw-maintainers] Double depends problem In-Reply-To: References: Message-ID: On Tue, Nov 10, 2009 at 12:49 AM, Maciej (Matchek) Blizinski wrote: > It happens quite often that packages I build with GAR end up having > double depends. ?Can we have automation around that? ?We could have > checkpkg verify that there are no double depends. ?We could also have > some mechanism in GAR that would force the depends list to be unique. > Ideally, we would have both those things. Adding a check to checkpkg was easy, done with one incomprehensible shell pipeline: http://sourceforge.net/apps/trac/gar/changeset/7191 Maciej From bwalton at opencsw.org Tue Nov 10 03:51:16 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 09 Nov 2009 21:51:16 -0500 Subject: [csw-maintainers] proposed small gar modification In-Reply-To: <3036B5F2-81F0-40F1-9F58-279DFB7AE052@opencsw.org> References: <1254936461-sup-6146@ntdws12.chass.utoronto.ca> <3036B5F2-81F0-40F1-9F58-279DFB7AE052@opencsw.org> Message-ID: <1257821157-sup-3986@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Oct 07 15:17:52 -0400 2009: Hi Dago, I just checked in the change we discussed that allows a maintainer to optionally disable CSWcommon as a dependency (primary use: pkgutil). Any maintainer that doesn't want a package to depend on CSWcommon should set: COMMON_PKG_DEPENDS = Gar build descriptions that generate multiple packages where only some packages should use CSWcommon would do: COMMON_PKG_DEPENDS = REQUIRED_PKGS_CSWsomepkg = CSWcommon ... 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 Tue Nov 10 04:04:30 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 09 Nov 2009 22:04:30 -0500 Subject: [csw-maintainers] git.opencsw.org Message-ID: <1257822095-sup-9151@ntdws12.chass.utoronto.ca> Hi All, We've had a gitosis server on git.opencsw.org (mirror) for a while now, but I updated it tonight to the latest version of the package that provides inetd support. This means that projects marked as public can be reached via urls like: git://git.opencsw.org/someproject.git Trygve is working on cgit, which is a nice web front end for repositories too. Dago, if you're ok with it, we can open ssh on that box to allow for gitosis at git.opencsw.org:someproject.git write access, which is currently limited to connections from inside the farm only (gitosis at mirror:someproject.git). Currently, Dago, Trygve and myself have access to the gitosis configuration to add projects, so please ping one of us if you'd like a project added[1]. The idea is that we can use this for projects that don't belong on sourceforge.net. Thanks -Ben [1] This list can certainly be amended if required/desired. -- 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 Nov 10 09:52:26 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 10 Nov 2009 08:52:26 +0000 Subject: [csw-maintainers] git.opencsw.org In-Reply-To: <1257822095-sup-9151@ntdws12.chass.utoronto.ca> References: <1257822095-sup-9151@ntdws12.chass.utoronto.ca> Message-ID: On Tue, Nov 10, 2009 at 3:04 AM, Ben Walton wrote: > Currently, Dago, Trygve and myself have access to the gitosis > configuration to add projects, so please ping one of us if you'd like > a project added[1]. ?The idea is that we can use this for projects > that don't belong on sourceforge.net. What would be an example of a project that doesn't belong on sourceforge.net? Maciej From ihsan at opencsw.org Tue Nov 10 10:46:38 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Tue, 10 Nov 2009 10:46:38 +0100 Subject: [csw-maintainers] EU objects Oracle's Sun takeover Message-ID: <4AF9367E.7010607@opencsw.org> Just saw that news this morning: http://www.vpbank.com/download/htm/1940/de/Daily-Morning-Coffee-News.pdf PS: Sorry, only in German. -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Tue Nov 10 11:14:00 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 10 Nov 2009 11:14:00 +0100 Subject: [csw-maintainers] RFD: X11 linkage problem strategy In-Reply-To: References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> <6BA24589-C2D1-48E7-9B97-98C5FC8FFD65@opencsw.org> Message-ID: <81CA8DC0-DF56-4BCB-81FB-3585FA6C5834@opencsw.org> Hi Phil, Am 09.11.2009 um 18:30 schrieb Philip Brown: > I think it would be best if you did some research, and laid out just > how many "intermediate libraries" we are talking about, and just how > many packages would USE these retro-compiled packages. > > Depending on the number of affected packages, other options for > affected packages might be: > > a) use solaris-shipped libs entirely (arent they available for sol8?) > b) use static compiled versions of small libs, if number of affected > packages is only a handful. > > OR, possibly still have the old way. but there is an issue of which > version of libgif "belongs" in /opt/csw/lib. > > Probably the normal one I suppose, if we mandate that anything using > /opt/csw/X11/lib must have that FIRST in its RPATH. That may be the ultimate solution: Just make sure that /opt/csw/X11/lib is in front of RPATH. That way the CSW x11 libs get always linked first, thus solving the mixed openwin/libX11 + csw/libXext issue. Doing more testing now... If it works I can easily add a permanent switch in GAR. Best regards -- Dago From maciej at opencsw.org Tue Nov 10 11:14:20 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 10 Nov 2009 10:14:20 +0000 Subject: [csw-maintainers] EU objects Oracle's Sun takeover In-Reply-To: <4AF9367E.7010607@opencsw.org> References: <4AF9367E.7010607@opencsw.org> Message-ID: On Tue, Nov 10, 2009 at 9:46 AM, Ihsan Dogan wrote: > Just saw that news this morning: > http://www.vpbank.com/download/htm/1940/de/Daily-Morning-Coffee-News.pdf http://www.denverpost.com/business/ci_13750606 They say the objection is over MySQL and database competition. "Oracle's acquisition of Sun's MySQL database software causes competition concerns." From dam at opencsw.org Tue Nov 10 11:21:42 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 10 Nov 2009 11:21:42 +0100 Subject: [csw-maintainers] proposed small gar modification In-Reply-To: <1257821157-sup-3986@ntdws12.chass.utoronto.ca> References: <1254936461-sup-6146@ntdws12.chass.utoronto.ca> <3036B5F2-81F0-40F1-9F58-279DFB7AE052@opencsw.org> <1257821157-sup-3986@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 10.11.2009 um 03:51 schrieb Ben Walton: > I just checked in the change we discussed that allows a maintainer to > optionally disable CSWcommon as a dependency (primary use: pkgutil). > Any maintainer that doesn't want a package to depend on CSWcommon > should set: > > COMMON_PKG_DEPENDS = > > Gar build descriptions that generate multiple packages where only some > packages should use CSWcommon would do: > > COMMON_PKG_DEPENDS = > > REQUIRED_PKGS_CSWsomepkg = CSWcommon ... Great! However: Am 10.11.2009 um 03:42 schrieb bdwalton at users.sourceforge.net: > Removed Paths: > ------------- > csw/mgar/gar/v2/pkglib/csw/depend lcsw% grep csw/depend * csw_cpan.gspec:%depend:merge url file://%{PKGLIB}/csw/depend.perl csw_dyndepend.gspec:%depend:merge url file://%{PKGLIB}/csw/depend csw_standard.gspec:%depend:merge url file://%{PKGLIB}/csw/depend Packages which still use static gspec will break when csw/depend is not there anymore. I re-added it in r7200. Apart from that it looks good and is definitely a step in the right direction :-) Best regards -- Dago From skayser at opencsw.org Tue Nov 10 14:49:33 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 10 Nov 2009 14:49:33 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: <20091110134933.GC30301@sebastiankayser.de> * Maciej (Matchek) Blizinski wrote: > On Tue, Oct 20, 2009 at 8:07 PM, Philip Brown wrote: > > On Tue, Oct 20, 2009 at 9:23 AM, Maciej (Matchek) Blizinski > > wrote: > >> > >> An idea for the change... from the perspective of the operating > >> system, it won't be really a rename, there is still going to be a > >> CSWpysvn package, only with a different content. > > > > > > you say "only", but that is what makes it WORSE! :-/ > > Not necessarily. We ship library packages with multiple libraries in > them. We potentially could ship both subversion-core and pysvn > libraries in the same package. No renaming, but merging > python-subversion libraries. It's a problem equivalent to the shared > library problem, which is solved already. > > > I have said the order and timeline of what I think is the best path to take. > > That still stands. > > Your timeline means that submitpkg won't be able to generate > changelists for $time_to_build_new_subversion_packages + one month. > I'd like to operate quicker than that. Any problems with this > approach? Any progress on the "new subversion/trac packages" front? I have had internal requests for 1.6.6 (quite a bit of bugfixes [1] from our current/ 1.6.2) and saw that a 1.6.5 build recipe with the adjusted python bindings package name is already in GAR. Sebastian [1] http://svn.collab.net/repos/svn/trunk/CHANGES From bwalton at opencsw.org Tue Nov 10 15:03:55 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 10 Nov 2009 09:03:55 -0500 Subject: [csw-maintainers] git.opencsw.org In-Reply-To: References: <1257822095-sup-9151@ntdws12.chass.utoronto.ca> Message-ID: <1257861780-sup-9707@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Tue Nov 10 03:52:26 -0500 2009: > What would be an example of a project that doesn't belong on sourceforge.net? Things that have no public value outside of opencsw? I don't think there are very many things that absolutely shouldn't be on sourceforge.net, but anything where 'security' is a concern might fit the bill. 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 bwalton at opencsw.org Tue Nov 10 15:06:07 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 10 Nov 2009 09:06:07 -0500 Subject: [csw-maintainers] proposed small gar modification In-Reply-To: References: <1254936461-sup-6146@ntdws12.chass.utoronto.ca> <3036B5F2-81F0-40F1-9F58-279DFB7AE052@opencsw.org> <1257821157-sup-3986@ntdws12.chass.utoronto.ca> Message-ID: <1257861936-sup-7751@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Nov 10 05:21:42 -0500 2009: Hi Dago, > Packages which still use static gspec will break when csw/depend is > not there anymore. I re-added it in r7200. Apart from that it looks > good and is definitely a step in the right direction :-) Doh! Thanks for catching that. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Tue Nov 10 17:39:54 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 10 Nov 2009 08:39:54 -0800 Subject: [csw-maintainers] RFD: X11 linkage problem strategy In-Reply-To: <81CA8DC0-DF56-4BCB-81FB-3585FA6C5834@opencsw.org> References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> <6BA24589-C2D1-48E7-9B97-98C5FC8FFD65@opencsw.org> <81CA8DC0-DF56-4BCB-81FB-3585FA6C5834@opencsw.org> Message-ID: On Tue, Nov 10, 2009 at 2:14 AM, Dagobert Michelsen wrote: >> Probably the normal one I suppose, if we mandate that anything using >> /opt/csw/X11/lib must have that FIRST in its RPATH. > > That may be the ultimate solution: Just make sure that > ?/opt/csw/X11/lib > is in front of RPATH. That way the CSW x11 libs get always linked first, > thus solving the mixed openwin/libX11 + csw/libXext issue. Doing more > testing now... If it works I can easily add a permanent switch in GAR. > Errr.. but it needs to only be for things that definately need "our" x11 libs. it cant be the "always default" ! From dam at opencsw.org Tue Nov 10 17:42:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 10 Nov 2009 17:42:13 +0100 Subject: [csw-maintainers] RFD: X11 linkage problem strategy In-Reply-To: References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> <6BA24589-C2D1-48E7-9B97-98C5FC8FFD65@opencsw.org> <81CA8DC0-DF56-4BCB-81FB-3585FA6C5834@opencsw.org> Message-ID: Hi Phil, Am 10.11.2009 um 17:39 schrieb Philip Brown: > On Tue, Nov 10, 2009 at 2:14 AM, Dagobert Michelsen > wrote: > >>> Probably the normal one I suppose, if we mandate that anything using >>> /opt/csw/X11/lib must have that FIRST in its RPATH. >> >> That may be the ultimate solution: Just make sure that >> /opt/csw/X11/lib >> is in front of RPATH. That way the CSW x11 libs get always linked >> first, >> thus solving the mixed openwin/libX11 + csw/libXext issue. Doing more >> testing now... If it works I can easily add a permanent switch in >> GAR. >> > > Errr.. but it needs to only be for things that definately need "our" > x11 libs. it cant be the "always default" ! I meant specifically for application that now bail out with linkage problems described before as mixed X11 usage from intermediate libs. Best regards -- Dago From bwalton at opencsw.org Tue Nov 10 21:14:14 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 10 Nov 2009 15:14:14 -0500 Subject: [csw-maintainers] hooks in pkg-get Message-ID: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> Hi Phil, Are you planning to implement hook support in pkg-get? There is already growing use of and demand for hooks, so not having it in pkg-get will present us with some problems... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Tue Nov 10 22:00:50 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 10 Nov 2009 13:00:50 -0800 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> Message-ID: On Tue, Nov 10, 2009 at 12:14 PM, Ben Walton wrote: > > Hi Phil, > > Are you planning to implement hook support in pkg-get? yes, I am "planning to". however, my time is limited, so it may not get done "soon". There is some small chance it may get done this weekend :-} However, there are other code changes that pkg-get is needing too, that have higher priority. > There is > already growing use of and demand for hooks, so not having it in > pkg-get will present us with some problems... problems? hooks are supposed to be *optional* things. If people are using hooks for package-mandatory things, there is a problem in packaging. I will remind you, that our packages should be installable by ANY SVR4 valid method. including "wget blah.pkg ; pkgadd -d blah.pkg". If the package does not function when added like that, then the package is improperly put together. From bwalton at opencsw.org Wed Nov 11 02:33:46 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 10 Nov 2009 20:33:46 -0500 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> Message-ID: <1257903067-sup-8643@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Nov 10 16:00:50 -0500 2009: > yes, I am "planning to". Ok. > however, my time is limited, so it may not get done "soon". There > is some small chance it may get done this weekend :-} However, there > are other code changes that pkg-get is needing too, that have higher > priority. Understandable. I'd offer to submit patches, but in this case, I think having the standard implemented by two separate people would provide some value. Anyone else interested? > > There is already growing use of and demand for hooks, so not > > having it in pkg-get will present us with some problems... > > problems? Call them like annoyances, I guess. If William's popularity contest hooks generate interest, their value will be crippled by only getting triggered at sites using pkgutil. It would be of more value to us to limit our participants like that. > hooks are supposed to be *optional* things. If people are using > hooks for package-mandatory things, there is a problem in packaging. Yes, they are. 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 Wed Nov 11 09:12:29 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 11 Nov 2009 09:12:29 +0100 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> Message-ID: <1E24A070-7F38-4B29-A9D4-39753F8C84FF@opencsw.org> Hi Phil, Am 10.11.2009 um 22:00 schrieb Philip Brown: >> There is >> already growing use of and demand for hooks, so not having it in >> pkg-get will present us with some problems... > > problems? > > hooks are supposed to be *optional* things. If people are using hooks > for package-mandatory things, there is a problem in packaging. > > I will remind you, that our packages should be installable by ANY SVR4 > valid method. > including "wget blah.pkg ; pkgadd -d blah.pkg". We have massive inconsistencies in the catalog for package names which could easily be cleaned up with an upgrade-script detecting old names and mapping them to new names. Additionally, these hooks would have solved easily - the XML migration where Ben put out that script - the esound-removal problem where I provided the snippet for you > If the package does not function when added like that, then the > package is improperly put together. Yes. And if the package has already been released like the old esound? Than what? Without hooks your doomed. Best regards -- Dago From bwalton at opencsw.org Wed Nov 11 13:30:46 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 11 Nov 2009 07:30:46 -0500 Subject: [csw-maintainers] Fwd: git.opencsw.org In-Reply-To: <871F5833-A77C-47EA-8637-A39010F652FB@baltic-online.de> References: <357F703B-8DC8-4CD8-9726-B19B8B6B299E@baltic-online.de> <871F5833-A77C-47EA-8637-A39010F652FB@baltic-online.de> Message-ID: <1257942609-sup-1516@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Nov 11 04:45:43 -0500 2009: Hi Dago, > Should be working now. It works like a charm. For anyone interested, in order to use this (with write access), we'll need ssh public keys from the locations you'd want to connect from. These could be submitted by your or pulled from your authorized keys files on the buildfarm. Multiple keys are fine. We'll create a group that represents the collection of all of your keys and then assign rights based on that group instead of individual keys. 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 Wed Nov 11 15:58:24 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 11 Nov 2009 15:58:24 +0100 Subject: [csw-maintainers] New cswclassutils: cswcron, cswtexinfo, cswmigrateconf and GAR integration Message-ID: <0691F15A-1BF5-4817-968F-449FC848E2D7@opencsw.org> Hi, as of r7226 and cswclassutils 1.28 there is support for three new classes: - cswcron allows modifying of the crontab - cswtexinfo allows automatic addition of .info files to the texinfo dir - cswmigrateconf allows easy migration of config files from /opt/csw/etc to /etc/opt/csw The usage has been documented at Best regards -- Dago From phil at bolthole.com Thu Nov 12 19:06:09 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 12 Nov 2009 10:06:09 -0800 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: <1E24A070-7F38-4B29-A9D4-39753F8C84FF@opencsw.org> References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> <1E24A070-7F38-4B29-A9D4-39753F8C84FF@opencsw.org> Message-ID: On Wed, Nov 11, 2009 at 12:12 AM, Dagobert Michelsen wrote: > Am 10.11.2009 um 22:00 schrieb Philip Brown: >> If the package does not function when [pkgadd'd directly], then the >> package is improperly put together. > > Yes. And if the package has already been released like the old esound? > Than what? Without hooks your doomed. > doomed, is a strong word :) If one chooses to not use automated package management tools, then by definition, one will be stuck doing more things manually. However that does point out, that if a maintainer is tempted to try to do "clever" things in a hook for mistake cleanup purposes, said maintainer should instead implement this "cleverness" in normal preinstall type scripts, so that it will work with straight pkgadd. So.. if this applies to you, Mr. Michelsen, please RE-fix your esound package ;-) From dam at opencsw.org Thu Nov 12 20:11:39 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 12 Nov 2009 20:11:39 +0100 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> <1E24A070-7F38-4B29-A9D4-39753F8C84FF@opencsw.org> Message-ID: <6A933C5E-433C-4130-B704-6DE96079AA7B@opencsw.org> Hi Phil, Am 12.11.2009 um 19:06 schrieb Philip Brown: > On Wed, Nov 11, 2009 at 12:12 AM, Dagobert Michelsen > wrote: >> Am 10.11.2009 um 22:00 schrieb Philip Brown: >>> If the package does not function when [pkgadd'd directly], then the >>> package is improperly put together. >> >> Yes. And if the package has already been released like the old >> esound? >> Than what? Without hooks your doomed. > > doomed, is a strong word :) > If one chooses to not use automated package management tools, then by > definition, one will be stuck doing more things manually. > > However that does point out, that if a maintainer is tempted to try to > do "clever" things in a hook for mistake cleanup purposes, said > maintainer should instead implement this "cleverness" in normal > preinstall type scripts, so that it will work with straight pkgadd. > > So.. if this applies to you, Mr. Michelsen, please RE-fix your esound > package ;-) If a package erranously removes a modified config-file on removal I obviously cannot fix that in the new package and the old package is already out. But I could put a copy aside in a postremove-hook and copy it back-in before the new package is installed :) Best regards -- Dago From phil at bolthole.com Thu Nov 12 20:17:35 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 12 Nov 2009 11:17:35 -0800 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: <6A933C5E-433C-4130-B704-6DE96079AA7B@opencsw.org> References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> <1E24A070-7F38-4B29-A9D4-39753F8C84FF@opencsw.org> <6A933C5E-433C-4130-B704-6DE96079AA7B@opencsw.org> Message-ID: On Thu, Nov 12, 2009 at 11:11 AM, Dagobert Michelsen wrote: > > If a package erranously removes a modified config-file on removal > I obviously cannot fix that in the new package and the old package > is already out. But I could put a copy aside in a postremove-hook > and copy it back-in before the new package is installed :) wait, what? you can modify behaviour of the former package, by newer packages, with this stuff? yikes. and what about the potential of old package hooks conflicting with new package hooks? This sounds like a very hairy capability. From dam at opencsw.org Thu Nov 12 20:28:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 12 Nov 2009 20:28:17 +0100 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> <1E24A070-7F38-4B29-A9D4-39753F8C84FF@opencsw.org> <6A933C5E-433C-4130-B704-6DE96079AA7B@opencsw.org> Message-ID: <05819A4E-2511-4516-A1B1-7BA8295CEBA3@opencsw.org> Hi Phil, Am 12.11.2009 um 20:17 schrieb Philip Brown: > On Thu, Nov 12, 2009 at 11:11 AM, Dagobert Michelsen > wrote: >> >> If a package erranously removes a modified config-file on removal >> I obviously cannot fix that in the new package and the old package >> is already out. But I could put a copy aside in a postremove-hook >> and copy it back-in before the new package is installed :) > > wait, what? > you can modify behaviour of the former package, by newer packages, > with this stuff? The hook can be called if one package is upgraded with another, before a package is removed and before a package is installed, etc. > yikes. > and what about the potential of old package hooks conflicting with new > package hooks? > This sounds like a very hairy capability. I guess the hooks will be distributed in a package CSWpkghooks or something. It should be updated before any other package on each update invocation and allows fixing these ugly things by calling scripts before malicous actions can take place. As I wrote before this would have allowed for the complicated XML-transition from Ben, the esound-problem, package renames and all other weird stuff. It is *the* chance to clean up once and for all. Best regards -- Dago From maciej at opencsw.org Fri Nov 13 19:09:11 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 13 Nov 2009 18:09:11 +0000 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> Message-ID: On Wed, Oct 14, 2009 at 5:27 PM, Maciej (Matchek) Blizinski wrote: > One more problem: It doesn't compile it on build8s, while it does on > my local machine at work. Here's what happens on build8s: > > checking for GTK+ - version >= 2.0.0... no > (...) Dago fixed this -- thanks! There's one more problem with this library. The existing Solaris 8 wxwidgets is compiled with unicode support. If it was compiled with Unicode on Solaris, there has to be a way of doing that, I just don't know what it is. I haven't been able to compile unicode-enabled version on Solaris 8 due to missing wide characters function. I don't know how it was compiled on Solaris 8, but it sure required some patching of the code, or copying files from Solaris 9, or something similar. The current build file disables unicode on Solaris 8: # Unicode-enabled build on Solaris 8 fails with: # "./src/common/wxchar.cpp", line 1693: Error: The function "vswscanf" must have # a prototype. # Building Unicode support for Solaris 9 and 10 only. CONFIGURE_ARGS_5.8 = --disable-unicode CONFIGURE_ARGS_5.9 = --enable-unicode CONFIGURE_ARGS_5.10 = --enable-unicode To refresh the state on this, there is gnulib, which provides this function, but on their website they're saying: http://www.gnu.org/software/gnulib/manual/html_node/vswscanf.html """Portability problems not fixed by Gnulib: * This function is missing on some platforms: NetBSD 3.0, OpenBSD 3.8, AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 8, Cygwin 1.5.x, Interix 3.5, BeOS. """ However, Dago thinks that GNUlib can fix the problem. I don't have a lot of spare cycles right now, so if anyone wants to pick up the work, everything is in the repository. Maciej From phil at bolthole.com Fri Nov 13 19:33:58 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 13 Nov 2009 10:33:58 -0800 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> Message-ID: On Fri, Nov 13, 2009 at 10:09 AM, Maciej (Matchek) Blizinski wrote: > > To refresh the state on this, there is gnulib, which provides this > function, but on their website they're saying: > http://www.gnu.org/software/gnulib/manual/html_node/vswscanf.html > > """Portability problems not fixed by Gnulib: > > ? ?* This function is missing on some platforms: NetBSD 3.0, OpenBSD > 3.8, AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 8, Cygwin 1.5.x, > Interix 3.5, BeOS. """ > > However, Dago thinks that GNUlib can fix the problem. I do seem to recall that the original maintainer fixed it with some gnulib code hacking/inclusion. From maciej at opencsw.org Fri Nov 13 20:06:07 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 13 Nov 2009 19:06:07 +0000 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <4ABD1B60.5060700@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> Message-ID: 2009/9/25 Trygve Laugst?l : > Ben Walton wrote: >> Excerpts from Sebastian Kayser's message of Thu Sep 24 17:38:12 -0400 2009: >>> So how about >>> 1) If it's a pure module, py_. >>> 2) If it's main use is as application, . >>> 3) In case of doubt, cross-check with other distributions?. >> >> Logical and concise. ?+1. > > Ditto. +1. There's also the question of pkgnames, is it CSWpyfoo or CSWpy-foo? If one follows the rule that "each _ becomes a -", we sometimes end up with CSWpy-foo and sometimes CSWpyfoo. I wrote down what I thought is the outcome of this policy (except for the point 3). Here's the table: http://wiki.opencsw.org/python-packages-naming Maciej From dam at opencsw.org Fri Nov 13 20:49:47 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 13 Nov 2009 20:49:47 +0100 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> Message-ID: <9BC48749-BD2C-442A-AB38-ECFC78D04EF5@opencsw.org> Hi, Am 13.11.2009 um 19:09 schrieb Maciej (Matchek) Blizinski: > There's one more problem with this library. The existing Solaris 8 > wxwidgets is compiled with unicode support. If it was compiled with > Unicode on Solaris, there has to be a way of doing that, I just don't > know what it is. I haven't been able to compile unicode-enabled > version on Solaris 8 due to missing wide characters function. I don't > know how it was compiled on Solaris 8, but it sure required some > patching of the code, or copying files from Solaris 9, or something > similar. This focus on Solaris 8 leads in the wrong direction as we officially deprecated it. If it is hard to do on Solaris 8 than we shouldn't spend effort in it and start releasing with Solaris 9 full features. In addition to this there are only 4 packages depending on wxwidgets: - xchm (Windows CHM Help Browser) - rapidsvn (SVN GUI Frontend) - kicad (Electronic Layout Software) - boincmanager (successor of SETI at home) The only application I would consider important here is kicad, which is actively maintained by Dominique. xchm was maintained by Alessio and I have successfully rebuilt it in GAR. rapidsvn is also from Alessio and may be as easy to redo. boinc is actively maintained by Eric. What I am saying is that we should concentrate on updating the dependent packages starting with Solaris 9 full featured, maybe without legacy libs, and leave Solaris 8 as is. > However, Dago thinks that GNUlib can fix the problem. I don't have a > lot of spare cycles right now, so if anyone wants to pick up the work, > everything is in the repository. I don't think this anymore, it will certainly take a day to do this right which would better be spend with other things moving forward. Best regards -- Dago From dam at opencsw.org Fri Nov 13 20:52:24 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 13 Nov 2009 20:52:24 +0100 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> Message-ID: <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> Hi Maciej, Am 13.11.2009 um 20:06 schrieb Maciej (Matchek) Blizinski: > 2009/9/25 Trygve Laugst?l : >> Ben Walton wrote: >>> Excerpts from Sebastian Kayser's message of Thu Sep 24 17:38:12 >>> -0400 2009: >>>> So how about >>>> 1) If it's a pure module, py_. >>>> 2) If it's main use is as application, . >>>> 3) In case of doubt, cross-check with other distributions?. >>> >>> Logical and concise. +1. >> >> Ditto. +1. > > There's also the question of pkgnames, is it CSWpyfoo or CSWpy-foo? If > one follows the rule that "each _ becomes a -", we sometimes end up > with CSWpy-foo and sometimes CSWpyfoo. > > I wrote down what I thought is the outcome of this policy (except for > the point 3). Here's the table: > http://wiki.opencsw.org/python-packages-naming This is a good writeup! I would have wished we had this for other packages a long time ago. The current standard however discourages the use of '-' in package names for *devel, *rt, etc. Don't get me wrong: I don't like the way it is, but there is at least some consistency in not having hyphens at all and converting the packages would require hooks to clean up. Having a consistent mapping between catalogname and packagenames is a Very Good Thing(tm), but I don't see how we can achieve it with the technology we have right now. Best regards -- Dago From rupert at opencsw.org Sat Nov 14 20:03:59 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 14 Nov 2009 20:03:59 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <20091110134933.GC30301@sebastiankayser.de> References: <4ADA85FA.7090506@opencsw.org> <20091110134933.GC30301@sebastiankayser.de> Message-ID: <6af4270911141103p550e49ebr208a62ae9cdf3836@mail.gmail.com> On Tue, Nov 10, 2009 at 14:49, Sebastian Kayser wrote: > * Maciej (Matchek) Blizinski wrote: > > On Tue, Oct 20, 2009 at 8:07 PM, Philip Brown wrote: > > > On Tue, Oct 20, 2009 at 9:23 AM, Maciej (Matchek) Blizinski > > > wrote: > > >> > > >> An idea for the change... from the perspective of the operating > > >> system, it won't be really a rename, there is still going to be a > > >> CSWpysvn package, only with a different content. > > > > > > > > > you say "only", but that is what makes it WORSE! :-/ > > > > Not necessarily. We ship library packages with multiple libraries in > > them. We potentially could ship both subversion-core and pysvn > > libraries in the same package. No renaming, but merging > > python-subversion libraries. It's a problem equivalent to the shared > > library problem, which is solved already. > > > > > I have said the order and timeline of what I think is the best path to > take. > > > That still stands. > > > > Your timeline means that submitpkg won't be able to generate > > changelists for $time_to_build_new_subversion_packages + one month. > > I'd like to operate quicker than that. Any problems with this > > approach? > > Any progress on the "new subversion/trac packages" front? I have had > internal requests for 1.6.6 (quite a bit of bugfixes [1] from our > current/ 1.6.2) and saw that a 1.6.5 build recipe with the adjusted > python bindings package name is already in GAR. > > Sebastian > > [1] http://svn.collab.net/repos/svn/trunk/CHANGES > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > i compiled it and put it in testing - as we want to do that upgrade as well soon. i made it world writeable so anybody can overwrite it in case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Nov 15 14:03:02 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 15 Nov 2009 13:03:02 +0000 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> Message-ID: On Mon, Nov 9, 2009 at 6:57 PM, Philip Brown wrote: > On Sun, Nov 8, 2009 at 2:58 PM, Maciej (Matchek) Blizinski > wrote: >> >> We didn't make the tests pass with the 5.0.x. ?We don't know if the >> 5.0.51,REV=2008.01.20 was passing the tests. ?If it wasn't, releasing >> my 5.0.84 would not mean any degradation in the QA of the package. ?If >> it was, it would be nice to know what was done to make the tests pass. >> ?I don't know if it makes sense to invest time in 5.0.x. tests if >> we're going to move on to 5.1 soon. > > i agree that so long as your 5.0.x version passes *at least the same > tests as our existing package*, it is fine to release,and then focus > efforts on 5.1 > > the only remaining question is, which tests does our existing pass? I know that Phil ran the tests and most of them passed. I've built 5.0.87 on Friday, I think this package is at least as good as the existing one. The concern might be the migration from the older package which uses /opt/csw/var and /opt/csw/etc. Perhaps it's a good thing to first release a package which doesn't do much changes to MySQL version (only a patchlevel upgrade), migrate the configuration files, and after some time, when the updated 5.0.x will have been in current/ for ~1 month, release the version 5.1. Maciej From maciej at opencsw.org Sun Nov 15 14:15:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 15 Nov 2009 13:15:01 +0000 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> Message-ID: On Fri, Nov 13, 2009 at 7:52 PM, Dagobert Michelsen wrote: > This is a good writeup! I would have wished we had this for > other packages a long time ago. The current standard however > discourages the use of '-' in package names for *devel, *rt, > etc. Is this guideline documented? > Don't get me wrong: I don't like the way it is, but there > is at least some consistency in not having hyphens at all > and converting the packages would require hooks to clean up. > Having a consistent mapping between catalogname and > packagenames is a Very Good Thing(tm), but I don't see > how we can achieve it with the technology we have right now. Suppose we use hyphens for new packages, and leave the existing ones without hyphens. It will make the new package names suck less^W^W be more readable, and won't cause any technical problems. Perhaps some day we'll have technology which allows us to migrate the package names, if we care enough. If you think we should create new packages without hyphens, let's make sure it's documented and findable. Maciej From trygvis at opencsw.org Sun Nov 15 18:35:41 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 15 Nov 2009 18:35:41 +0100 Subject: [csw-maintainers] Issues with generated prototype+spaces in paths Message-ID: <4B003BED.5080302@opencsw.org> Howdy Is there any magic in GAR to handle paths with spaces? [1]. I have a package (pcb) that I'm trying to complete that include a library of components that have spaces in them. pkgmk actually core dumped on these lines: f none /opt/csw/share/pcb/pcblib-newlib/connector/single-ended SCSI.fp=/home/trygvis/dev/org.opencsw/mgar/pkg/pcb/trunk/work/pkgroot/opt/csw/share/pcb/pcblib-newlib/connector/single-ended root bin trygvis other f none /opt/csw/share/pcb/pcblib-newlib/connector/single-ended SCSI.png=/home/trygvis/dev/org.opencsw/mgar/pkg/pcb/trunk/work/pkgroot/opt/csw/share/pcb/pcblib-newlib/connector/single-ended root bin trygvis other When I excluded those paths with EXTRA_MERGE_EXCLUDE_FILES, it choked on these: f none /opt/csw/share/pcb/pcblib-newlib/generic/1 MHz root bin OSC.fp 0644 trygvis other So, I wonder. Why does the prototype generator include a real path to some of the files, and is it a bug that it doesn't escape the paths with spaces? I'll try to build it with with an exclusion on all paths with spaces to see if that'll fix it. [1]: Is this at all possible with the pkg* tools? -- Trygve From dam at opencsw.org Sun Nov 15 21:54:25 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 15 Nov 2009 21:54:25 +0100 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> Message-ID: <432EECCE-5EA4-4464-8254-F9E6CB38D840@opencsw.org> Hi Maciej, Am 15.11.2009 um 14:15 schrieb Maciej (Matchek) Blizinski: > On Fri, Nov 13, 2009 at 7:52 PM, Dagobert Michelsen > wrote: >> This is a good writeup! I would have wished we had this for >> other packages a long time ago. The current standard however >> discourages the use of '-' in package names for *devel, *rt, >> etc. > > Is this guideline documented? Yes, here: http://www.opencsw.org/standards/pkgcreation >> Don't get me wrong: I don't like the way it is, but there >> is at least some consistency in not having hyphens at all >> and converting the packages would require hooks to clean up. >> Having a consistent mapping between catalogname and >> packagenames is a Very Good Thing(tm), but I don't see >> how we can achieve it with the technology we have right now. > > Suppose we use hyphens for new packages, and leave the existing ones > without hyphens. It will make the new package names suck less^W^W be > more readable, and won't cause any technical problems. Perhaps some > day we'll have technology which allows us to migrate the package > names, if we care enough. > > If you think we should create new packages without hyphens, let's make > sure it's documented and findable. It is documented. Please review http://www-mockup.opencsw.org/ that it is at a decent location. Best regards -- Dago From dam at opencsw.org Sun Nov 15 21:59:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 15 Nov 2009 21:59:32 +0100 Subject: [csw-maintainers] Issues with generated prototype+spaces in paths In-Reply-To: <4B003BED.5080302@opencsw.org> References: <4B003BED.5080302@opencsw.org> Message-ID: <6E0ECA76-3A40-4341-854A-BBC780BCB753@opencsw.org> Hi Trygve, Am 15.11.2009 um 18:35 schrieb Trygve Laugst?l: > Is there any magic in GAR to handle paths with spaces? [1]. I have a > package (pcb) that I'm trying to complete that include a library of > components that have spaces in them. Exactly this thing has been discussed in March, where Roger also tried to package up pcb: Best regards -- Dago From maciej at opencsw.org Mon Nov 16 09:13:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 16 Nov 2009 08:13:54 +0000 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) Message-ID: On Fri, Nov 13, 2009 at 7:49 PM, Dagobert Michelsen wrote: > Hi, > > Am 13.11.2009 um 19:09 schrieb Maciej (Matchek) Blizinski: > >> However, Dago thinks that GNUlib can fix the problem. ?I don't have a >> lot of spare cycles right now, so if anyone wants to pick up the work, >> everything is in the repository. > > I don't think this anymore, it will certainly take a day to do > this right which would better be spend with other things > moving forward. Not that I disagree, but I've decided to give it another go. I'm a bit criss-cross, I know. I just thought that if it has been built before, there must be a way and I wanted to know what was it. Here are my findings: gnulib in fact does not have any code that implements vswscanf, its documentation tells the truth. After adding -D__EXTENSIONS__ another function started being a problem: vsscanf. A grep through /opt/csw/include revealed that ncursesw provides an implementation of this function, so I added a patch including the ncursesw include and it started compiling. There was one more problem with linking where the monolithic version Makefile was missing an object file and was missing symbols. As a side note, patching old versions of libraries is a bit frustrating, as the patches won't get accepted upstream, yet must be written. The next hoop was a missing symbol (on x86 only): __sincos. Fixed by throwing in -lsunmath. It finally built fine: we now have unicode-enabled wxwidgets for Solaris 8, both sparc and x86. Yey! For the curious, here's the overview of the update. Most importantly, /opt/csw/lib/libwx_gtk2u-2.8.so.0.2.0 stays in to preserve backward compatibility. Since the newly built wxwidgets have the contrib module turned on, there's a bunch of 0.2.0 files that aren't in the current/ (wxwidgets_gtk2-2.8.5) package. The new package has been built as a modular library, because it's the upstream default. wxwidgets_common gained some new files. They make the package architecture dependent, wxwidgets_common-2.8.5-SunOS5.8-all-CSW becomes wxwidgets_common-2.8.10,REV=2009.11.16-SunOS5.8-sparc-CSW. The devel package gained some new files too. Notably, there's /opt/csw/include/wx-2.8/wx/stc/stc.h which is required for the once requested pgadmin3. The comparepkg diffs: wxwidgets_gtk2 http://dpaste.com/120986/ wxwidgets_common http://dpaste.com/120990/ wxwidgets_devel: http://dpaste.com/120992/ New packages are now available for testing. Maciej From james at opencsw.org Mon Nov 16 10:57:37 2009 From: james at opencsw.org (James Lee) Date: Mon, 16 Nov 2009 09:57:37 GMT Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> Message-ID: <20091116.9573700.2235360213@gyor.oxdrove.co.uk> On 13/11/09, 19:52:24, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)?: > Having a consistent mapping between catalogname and > packagenames is a Very Good Thing(tm), but I don't see > how we can achieve it with the technology we have right now. It's completely achievable and always has been. People have simply chosen not to. Don't put restricted characters in the names, e.g. no '-' and '_'. James. From maciej at opencsw.org Mon Nov 16 12:34:36 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 16 Nov 2009 11:34:36 +0000 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: Message-ID: I tried to run rapidsvn in a vnc server. No joy: maciej at vsol01 pkg $ rapidsvn Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". Segmentation Fault (core dumped) Perhaps it was because of the vnc server? Is rapidsvn running with wxwidgets 2.8.10 for you? Maciej From maciej at opencsw.org Mon Nov 16 12:40:34 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 16 Nov 2009 11:40:34 +0000 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: Message-ID: On Mon, Nov 16, 2009 at 11:34 AM, Maciej (Matchek) Blizinski wrote: > I tried to run rapidsvn in a vnc server. ?No joy: > > maciej at vsol01 pkg $ rapidsvn > Xlib: ?extension "Generic Event Extension" missing on display ":1.0". > Xlib: ?extension "Generic Event Extension" missing on display ":1.0". > Xlib: ?extension "Generic Event Extension" missing on display ":1.0". > Segmentation Fault (core dumped) > > Perhaps it was because of the vnc server? ?Is rapidsvn running with > wxwidgets 2.8.10 for you? I downgraded the wxwidgets_gtk2 package from 2.8.10 to 2.8.5. rapidsvn worked, only threw some warnings: maciej at vsol01 pkg $ rapidsvn Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". (rapidsvn:9295): Gtk-WARNING **: Unable to locate theme engine in module_path: "xfce", (rapidsvn:9295): Gtk-WARNING **: Unable to locate theme engine in module_path: "xfce", (rapidsvn:9295): Gtk-WARNING **: Unable to locate theme engine in module_path: "xfce", a (rapidsvn:9295): Gdk-CRITICAL **: file gdkproperty-x11.c: line 192: assertion `atom != GDK_NONE' failed It means that it doesn't like the new package and segfaults on it. Any ideas why a recompiled library of the same version might segfault? Perhaps we should just include the old binaries in the new package. From skayser at opencsw.org Mon Nov 16 15:42:38 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 16 Nov 2009 15:42:38 +0100 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: Message-ID: <20091116144238.GA1788@sebastiankayser.de> * Maciej (Matchek) Blizinski wrote: > I tried to run rapidsvn in a vnc server. No joy: > > maciej at vsol01 pkg $ rapidsvn > Xlib: extension "Generic Event Extension" missing on display ":1.0". > Xlib: extension "Generic Event Extension" missing on display ":1.0". > Xlib: extension "Generic Event Extension" missing on display ":1.0". > Segmentation Fault (core dumped) Benny had some weird problems when re-packaging pureftpd and IIRC traced it down to the application being compiled against a variant of crypt() (or similar) and run-time-linked against another one which expected its arguments to be a tad different (symbol was present in two libs, both linked into the application). Could be seen with some debugging. Could our mixed X11 libs environment cause similar problems? Sebastian From skayser at opencsw.org Mon Nov 16 15:46:47 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 16 Nov 2009 15:46:47 +0100 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: <20091116144238.GA1788@sebastiankayser.de> References: <20091116144238.GA1788@sebastiankayser.de> Message-ID: <20091116144647.GB1788@sebastiankayser.de> * Sebastian Kayser wrote: > * Maciej (Matchek) Blizinski wrote: > > I tried to run rapidsvn in a vnc server. No joy: > > > > maciej at vsol01 pkg $ rapidsvn > > Xlib: extension "Generic Event Extension" missing on display ":1.0". > > Xlib: extension "Generic Event Extension" missing on display ":1.0". > > Xlib: extension "Generic Event Extension" missing on display ":1.0". > > Segmentation Fault (core dumped) > > Benny had some weird problems when re-packaging pureftpd and IIRC traced > it down to the application being compiled against a variant of crypt() > (or similar) and run-time-linked against another one which expected its > arguments to be a tad different (symbol was present in two libs, both > linked into the application). Could be seen with some debugging. To be more specific: weird problems ^= segfaults > Could our mixed X11 libs environment cause similar problems? Sebastian From korpela at opencsw.org Mon Nov 16 22:19:24 2009 From: korpela at opencsw.org (Eric J Korpela) Date: Mon, 16 Nov 2009 13:19:24 -0800 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: Message-ID: I'll try to build boincmanager against the new libraries some time this week From bonivart at opencsw.org Mon Nov 16 22:31:24 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 16 Nov 2009 22:31:24 +0100 Subject: [csw-maintainers] Could someone please update CSWpygtk? Message-ID: <625385e30911161331l54ef66b9o9180de81b37ba9c9@mail.gmail.com> A colleague of mine was trying to install CSWmeld and it obviously needed CSWpygtk so we installed that, more things were missing to get meld running but the main problem seemed to be this already reported bug: http://www.opencsw.org/mantis/view.php?id=3832 -- /peter From skayser at opencsw.org Tue Nov 17 09:46:09 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 17 Nov 2009 09:46:09 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <6af4270911141103p550e49ebr208a62ae9cdf3836@mail.gmail.com> References: <4ADA85FA.7090506@opencsw.org> <20091110134933.GC30301@sebastiankayser.de> <6af4270911141103p550e49ebr208a62ae9cdf3836@mail.gmail.com> Message-ID: <20091117084609.GD1788@sebastiankayser.de> * rupert THURNER wrote: >> On Tue, Nov 10, 2009 at 14:49, Sebastian Kayser <[1]skayser at opencsw.org> >> wrote: >> Any progress on the "new subversion/trac packages" front? I have had >> internal requests for 1.6.6 (quite a bit of bugfixes [1] from our >> current/ 1.6.2) and saw that a 1.6.5 build recipe with the adjusted >> python bindings package name is already in GAR. > > i compiled it and put it in testing - as we want to do that upgrade as > well soon. i made it world writeable so anybody can overwrite it in case. Thanks, Rupert. The GAR build recipe for subversion skips the tests, did you run these for the updated version? Sebastian From maciej at opencsw.org Tue Nov 17 11:20:56 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 10:20:56 +0000 Subject: [csw-maintainers] Could someone please update CSWpygtk? In-Reply-To: <625385e30911161331l54ef66b9o9180de81b37ba9c9@mail.gmail.com> References: <625385e30911161331l54ef66b9o9180de81b37ba9c9@mail.gmail.com> Message-ID: On Mon, Nov 16, 2009 at 9:31 PM, Peter Bonivart wrote: > A colleague of mine was trying to install CSWmeld and it obviously > needed CSWpygtk so we installed that, more things were missing to get > meld running but the main problem seemed to be this already reported > bug: > > http://www.opencsw.org/mantis/view.php?id=3832 This breakage sucks. Which pygtk version are we aiming for? 1.14, 1.15 or 1.16? The pygtk website says that 1.14 is stable. Which pygtk version does meld require? Maciej From maciej at opencsw.org Tue Nov 17 11:57:38 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 10:57:38 +0000 Subject: [csw-maintainers] Could someone please update CSWpygtk? In-Reply-To: References: <625385e30911161331l54ef66b9o9180de81b37ba9c9@mail.gmail.com> Message-ID: On Tue, Nov 17, 2009 at 10:20 AM, Maciej (Matchek) Blizinski wrote: > On Mon, Nov 16, 2009 at 9:31 PM, Peter Bonivart wrote: >> A colleague of mine was trying to install CSWmeld and it obviously >> needed CSWpygtk so we installed that, more things were missing to get >> meld running but the main problem seemed to be this already reported >> bug: >> >> http://www.opencsw.org/mantis/view.php?id=3832 > > This breakage sucks. ?Which pygtk version are we aiming for? ?1.14, > 1.15 or 1.16? ?The pygtk website says that 1.14 is stable. ?Which > pygtk version does meld require? I looked at the newest pygtk. It requires newer pygobject than the one in catalog. I looked at pygobject, got it to compile on Solaris 10 x86, then went and tried building it on the buildfarm. I got an error: maciej at build8x [build8x]:~/src/opencsw/pkg/pygobject/trunk > (cd /home/maciej/src/opencsw/pkg/pygobject/trunk/work/solaris8-i386/build-isa-i386/pygobject-2.20.0/gobject; /bin/bash ../libtool --tag=CC --mode=link /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT -D_PTHREADS -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/python2.6 -I/opt/csw/include/python2.6 -lglib-2.0 -xO3 -xarch=386 -I/opt/csw/include -xarch=386 -L/opt/csw/lib -o generate-constants generate_constants-generate-constants.o) libtool: link: /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT -D_PTHREADS -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/python2.6 -I/opt/csw/include/python2.6 -xO3 -xarch=386 -I/opt/csw/include -xarch=386 -o generate-constants generate_constants-generate-constants.o -lglib-2.0 -L/opt/csw/lib ld: fatal: library -lglib-2.0: not found ld: fatal: File processing errors. No output written to generate-constants I don't quite get it. The library is there on the disk: maciej at build8x [build8x]:~/src/opencsw/pkg/pygobject/trunk > ls -l /opt/csw/lib/libglib-2.0.so* lrwxrwxrwx 1 root other 23 Apr 28 2009 /opt/csw/lib/libglib-2.0.so -> libglib-2.0.so.0.2000.0 lrwxrwxrwx 1 root other 23 Apr 28 2009 /opt/csw/lib/libglib-2.0.so.0 -> libglib-2.0.so.0.2000.0 -rwxr-xr-x 1 root bin 1190120 Apr 9 2009 /opt/csw/lib/libglib-2.0.so.0.2000.0 There's also the -L/opt/csw/lib flag. What else does it need to find the library? Has anyone seen such a problem before? Maciej From james at opencsw.org Tue Nov 17 12:23:04 2009 From: james at opencsw.org (James Lee) Date: Tue, 17 Nov 2009 11:23:04 GMT Subject: [csw-maintainers] Could someone please update CSWpygtk? In-Reply-To: References: Message-ID: <20091117.11230400.3792129617@gyor.oxdrove.co.uk> On 17/11/09, 10:57:38, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] Could someone please update CSWpygtk?: > libtool: link: /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT > -D_PTHREADS -I/opt/csw/include/glib-2.0 > -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/python2.6 > -I/opt/csw/include/python2.6 -xO3 -xarch=386 -I/opt/csw/include > -xarch=386 -o generate-constants > generate_constants-generate-constants.o -lglib-2.0 -L/opt/csw/lib > ld: fatal: library -lglib-2.0: not found > ld: fatal: File processing errors. No output written to > generate-constants > I don't quite get it. The library is there on the disk: ... > There's also the -L/opt/csw/lib flag. What else does it need to find > the library? Our dear friend libtool. It's added the L path but after the lib. James. From maciej at opencsw.org Tue Nov 17 15:58:34 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 14:58:34 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 Message-ID: I'm looking at building postgresql-8.4.1. I used this db engine before a lot and I'd like to have its recent version. The main problem with compilation is this: http://archives.postgresql.org/pgsql-general/2009-11/msg00687.php In short, the old includes from /opt/csw/postgresql/include are breaking the build. How would you fix it? I guess that uninstalling the devel postgresql package would help, but it's not the proper solution. It looks like a general problem: suppose there are old, incompatible header files in the include/ directory. The application needs include its foo.h, which is present in both /opt/csw/include/ and its source directory. The code using the header file just says: #include "foo.h" The foo.h file is also in, say ../../../src/include. The compiler invocation looks like this: /opt/studio/SOS11/SUNWspro/bin/cc -Xa -xO3 -xarch=v8 -I/opt/csw/include -I../../../src/include -I/opt/csw/include -c -o nodeGroup.o nodeGroup.c What should it look like to compile correctly, assuming that the /opt/csw/include/foo.h files is incompatible with the software being built? Maciej From maciej at opencsw.org Tue Nov 17 16:15:44 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 15:15:44 +0000 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: On Fri, Oct 23, 2009 at 4:48 PM, Philip Brown wrote: > On Fri, Oct 23, 2009 at 8:27 AM, Maciej (Matchek) Blizinski > wrote: >> >> There's no default; you're supposed to create your own ~/.garrc, and >> the sample file contains: >> >> ${HOME}/staging/build-$(date '+%d.%b.%Y') >>[...] >> I prefer ISO standards for dates[(it builds better)] > > definately :-) > > Hmmm. the non-deterministic nature of that, would make it slightly > difficult to have any kind of automated, > "Go autobuild 10 packages and add them" > script at a customer site. > > How many people are using something else there, and if so, what? I think it there is a need to provide an API for specifying the pkg destination directory. I can think of a couple of ways: - an environment variable (PKG_DEST_DIR?) - an entry in a configuration file (where would the file be? in what format?) - an argument to the build script (./build --pkg-dest-dir=/home/joe/staging?) Alternatively, the destination directory might be the one in which the build script is. But then it might be hard to separate the newly built packages from any other files that might be in the same directory. Which people think is best? Maciej From dam at opencsw.org Tue Nov 17 17:45:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 17:45:22 +0100 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: Message-ID: <83CED7D4-8FCB-4D9D-965F-4D8975BEEF6D@opencsw.org> Hi Erik, Am 16.11.2009 um 22:19 schrieb Eric J Korpela: > I'll try to build boincmanager against the new libraries some time > this week Cool. Let me know if you need additional machines or installs on build*t as the updated wxwidgets library will only be installed on build*s/x after release and there is still an unresolved issue. Best regards -- Dago From phil at bolthole.com Tue Nov 17 17:47:04 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Nov 2009 08:47:04 -0800 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: On Tue, Nov 17, 2009 at 7:15 AM, Maciej (Matchek) Blizinski wrote: > >> How many people are using something else there, and if so, what? > > I think it there is a need to provide an API for specifying the pkg > destination directory. ?I can think of a couple of ways: > > - an environment variable (PKG_DEST_DIR?) > - an entry in a configuration file (where would the file be? in what format?) > - an argument to the build script (./build --pkg-dest-dir=/home/joe/staging?) simplest thing is an environment variable, particularly since most other things (CFLAGS, etc) will be environment variables. I will propose that any csw specific vars, have csw prefix. So, CSW_PKG_DIR perhaps? We also need a good default. I think Mike's example, of $(HOME)/newpkgs is a good default. Can I get a second on that? From phil at bolthole.com Tue Nov 17 17:49:45 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Nov 2009 08:49:45 -0800 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: Message-ID: On Tue, Nov 17, 2009 at 6:58 AM, Maciej (Matchek) Blizinski wrote: > I'm looking at building postgresql-8.4.1. ?I used this db engine > before a lot and I'd like to have its recent version. > > The main problem with compilation is this: > http://archives.postgresql.org/pgsql-general/2009-11/msg00687.php > > In short, the old includes from /opt/csw/postgresql/include are > breaking the build. ?How would you fix it? ?I guess that uninstalling > the devel postgresql package would help, but it's not the proper > solution. actually, its a perfectly reasonable, albeit a little inconvenient, solution. Other packages also require this. To better fix the problem, requires that you convince your "upstream" to make its build environment better, which can sometimes be very difficult. > The foo.h file is also in, say ../../../src/include. The compiler > invocation looks like this: > > /opt/studio/SOS11/SUNWspro/bin/cc -Xa -xO3 -xarch=v8 > -I/opt/csw/include -I../../../src/include -I/opt/csw/include ? -c -o > nodeGroup.o nodeGroup.c If you had the -I../.. first, it should actually work the way you want it. kind of like if you had -L/opt/csw/lib -L/usr/local/lib long as ours are "first", things will work out ok, usually. From bwalton at opencsw.org Tue Nov 17 17:50:57 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 17 Nov 2009 11:50:57 -0500 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: <1258476632-sup-1910@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Nov 17 11:47:04 -0500 2009: > $(HOME)/newpkgs > > is a good default. > Can I get a second on that? I'd switch my .garrc to that. +1. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Tue Nov 17 17:52:27 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 17:52:27 +0100 Subject: [csw-maintainers] Could someone please update CSWpygtk? In-Reply-To: <20091117.11230400.3792129617@gyor.oxdrove.co.uk> References: <20091117.11230400.3792129617@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 17.11.2009 um 12:23 schrieb James Lee: > On 17/11/09, 10:57:38, Maciej "(Matchek)" Blizinski > > wrote regarding Re: [csw-maintainers] Could someone please update > CSWpygtk?: > >> libtool: link: /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT >> -D_PTHREADS -I/opt/csw/include/glib-2.0 >> -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/python2.6 >> -I/opt/csw/include/python2.6 -xO3 -xarch=386 -I/opt/csw/include >> -xarch=386 -o generate-constants >> generate_constants-generate-constants.o -lglib-2.0 -L/opt/csw/lib >> ld: fatal: library -lglib-2.0: not found >> ld: fatal: File processing errors. No output written to >> generate-constants > >> I don't quite get it. The library is there on the disk: > ... >> There's also the -L/opt/csw/lib flag. What else does it need to find >> the library? > > Our dear friend libtool. It's added the L path but after the lib. Nope, look again: > maciej at build8x [build8x]:~/src/opencsw/pkg/pygobject/trunk > (cd > /home/maciej/src/opencsw/pkg/pygobject/trunk/work/solaris8-i386/ > build-isa-i386/pygobject-2.20.0/gobject; > /bin/bash ../libtool --tag=CC --mode=link > /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT -D_PTHREADS > -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include > -I/opt/csw/include/python2.6 -I/opt/csw/include/python2.6 -lglib-2.0 > -xO3 -xarch=386 -I/opt/csw/include -xarch=386 -L/opt/csw/lib -o > generate-constants generate_constants-generate-constants.o) The above is what is passed to libtool. Here the order is already wrong. And I am not only saying this as the libtool-maintainer ;-) Libtool than just passes the order: > libtool: link: /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT > -D_PTHREADS -I/opt/csw/include/glib-2.0 > -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/python2.6 > -I/opt/csw/include/python2.6 -xO3 -xarch=386 -I/opt/csw/include > -xarch=386 -o generate-constants > generate_constants-generate-constants.o -lglib-2.0 -L/opt/csw/lib > ld: fatal: library -lglib-2.0: not found > ld: fatal: File processing errors. No output written to generate- > constants Best regards -- Dago From dam at opencsw.org Tue Nov 17 17:58:14 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 17:58:14 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: Message-ID: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Hi Maciej, Am 17.11.2009 um 15:58 schrieb Maciej (Matchek) Blizinski: > I'm looking at building postgresql-8.4.1. I used this db engine > before a lot and I'd like to have its recent version. > > The main problem with compilation is this: > http://archives.postgresql.org/pgsql-general/2009-11/msg00687.php > > In short, the old includes from /opt/csw/postgresql/include are > breaking the build. How would you fix it? I guess that uninstalling > the devel postgresql package would help, but it's not the proper > solution. It looks like a general problem: suppose there are old, > incompatible header files in the include/ directory. The application > needs include its foo.h, which is present in both /opt/csw/include/ > and its source directory. The code using the header file just says: > > #include "foo.h" > > The foo.h file is also in, say ../../../src/include. The compiler > invocation looks like this: > > /opt/studio/SOS11/SUNWspro/bin/cc -Xa -xO3 -xarch=v8 > -I/opt/csw/include -I../../../src/include -I/opt/csw/include -c -o > nodeGroup.o nodeGroup.c > > What should it look like to compile correctly, assuming that the > /opt/csw/include/foo.h files is incompatible with the software being > built? The problem is that GAR adds the include to CPPFLAGS and CFLAGS. An upstream maintainer (can't remember who) already pointed out that it is not good to pass -I in CPPFLAGS and CFLAGS and that CPPFLAGS would be sufficient. The Makefile from Postgres makes the assumption that it takes CFLAGS, then adds his includes and then the CPPFLAGS. Putting the include in CFLAGS erranously prepends it before his own flags. I had this problem myself some times but didn't recognize the cause properly: grep filter-out */trunk/Makefile | grep CFLAGS I even used argument-reordering on compile invocation for flac to work around it which may have better be solved in the above way. Now that I have understood it I would propose to remove the "-I" from CFLAGS in GAR, but I am afraid that this may break existing Makefiles as they may rely on it. This is especially true for manual builds which pass CFLAGS explicitly without passing CPPFLAGS explicitly. What do the C-gurus say? James? Anybody? Best regards -- Dago From dam at opencsw.org Tue Nov 17 17:59:03 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 17:59:03 +0100 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: Hi Maciej, Am 17.11.2009 um 16:15 schrieb Maciej (Matchek) Blizinski: > On Fri, Oct 23, 2009 at 4:48 PM, Philip Brown > wrote: >> On Fri, Oct 23, 2009 at 8:27 AM, Maciej (Matchek) Blizinski >> wrote: >>> >>> There's no default; you're supposed to create your own ~/.garrc, and >>> the sample file contains: >>> >>> ${HOME}/staging/build-$(date '+%d.%b.%Y') >>> [...] >>> I prefer ISO standards for dates[(it builds better)] >> >> definately :-) >> >> Hmmm. the non-deterministic nature of that, would make it slightly >> difficult to have any kind of automated, >> "Go autobuild 10 packages and add them" >> script at a customer site. >> >> How many people are using something else there, and if so, what? > > I think it there is a need to provide an API for specifying the pkg > destination directory. I can think of a couple of ways: > > - an environment variable (PKG_DEST_DIR?) > - an entry in a configuration file (where would the file be? in what > format?) > - an argument to the build script (./build --pkg-dest-dir=/home/joe/ > staging?) > > Alternatively, the destination directory might be the one in which the > build script is. But then it might be hard to separate the newly > built packages from any other files that might be in the same > directory. > > Which people think is best? I would prefer the environment variable as it is both easy to use and to add to the build tree. Best regards -- Dago From dam at opencsw.org Tue Nov 17 18:06:00 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 18:06:00 +0100 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: <1258476632-sup-1910@ntdws12.chass.utoronto.ca> References: <1258476632-sup-1910@ntdws12.chass.utoronto.ca> Message-ID: <8FCB89D1-8D85-48BB-909A-FD758462DB7A@opencsw.org> Hi, Am 17.11.2009 um 17:50 schrieb Ben Walton: > Excerpts from Philip Brown's message of Tue Nov 17 11:47:04 -0500 > 2009: >> $(HOME)/newpkgs >> >> is a good default. >> Can I get a second on that? > > I'd switch my .garrc to that. +1. Why do we need a default? The API make setting this mandatory. It may be good to have a default in the enclosing build system, but the maintainer should set a use-specific default. So I don't see a need that the inner build-systems need to handle defaults. Best regards -- Dago From phil at bolthole.com Tue Nov 17 18:09:07 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Nov 2009 09:09:07 -0800 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: <8FCB89D1-8D85-48BB-909A-FD758462DB7A@opencsw.org> References: <1258476632-sup-1910@ntdws12.chass.utoronto.ca> <8FCB89D1-8D85-48BB-909A-FD758462DB7A@opencsw.org> Message-ID: On Tue, Nov 17, 2009 at 9:06 AM, Dagobert Michelsen wrote: > Hi, > > Am 17.11.2009 um 17:50 schrieb Ben Walton: >> >> Excerpts from Philip Brown's message of Tue Nov 17 11:47:04 -0500 2009: >>> >>> $(HOME)/newpkgs >>> >>> is a good default. >>> Can I get a second on that? >> >> I'd switch my .garrc to that. ?+1. > > Why do we need a default? The API make setting this mandatory. It may > be good to have a default in the enclosing build system, but the maintainer > should set a use-specific default. So I don't see a need that the inner > build-systems need to handle defaults. > err, are you speaking of "[the gar] build system"? or the "raw API" one? I think you are referring to gar. the "raw API" one does not have setting anything mandatory. In order to keep discussion for this "raw api" thread simple (just like the proposed API ;-), lets please keep discussions of GAR, to a completely different thread From bonivart at opencsw.org Tue Nov 17 18:11:35 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 17 Nov 2009 18:11:35 +0100 Subject: [csw-maintainers] /testing cfengine, cvsproxy, diffuse, oinkmaster, perl, snort Message-ID: <625385e30911170911o7e76ae6bme982ec90ccd7fdc8@mail.gmail.com> I would like some help testing a few packages. If you use any of the below packages in their current versions and have time to test these I would really appreciate it. Note that if you want to test cvsproxy you need to be aware of this bug in the current package: http://www.opencsw.org/mantis/view.php?id=1839. cfengine-2.2.10,REV=2009.11.11-SunOS5.8-i386-CSW.pkg.gz cfengine-2.2.10,REV=2009.11.11-SunOS5.8-sparc-CSW.pkg.gz cfengine_doc-2.2.10,REV=2009.11.11-SunOS5.8-all-CSW.pkg.gz cvsproxy-1.0.1,REV=2009.11.01-SunOS5.8-i386-CSW.pkg.gz cvsproxy-1.0.1,REV=2009.11.01-SunOS5.8-sparc-CSW.pkg.gz diffuse-0.4.1,REV=2009.10.21-SunOS5.8-all-CSW.pkg.gz oinkmaster-2.0,REV=2009.10.19-SunOS5.8-all-CSW.pkg.gz perl-5.8.8,REV=2009.11.12-SunOS5.8-i386-CSW.pkg.gz perl-5.8.8,REV=2009.11.12-SunOS5.8-sparc-CSW.pkg.gz perldoc-5.8.8,REV=2009.11.12-SunOS5.8-all-CSW.pkg.gz snort-2.8.5,REV=2009.10.19-SunOS5.8-i386-CSW.pkg.gz snort-2.8.5,REV=2009.10.19-SunOS5.8-sparc-CSW.pkg.gz http://mirror.opencsw.org/testing.html -- /peter From phil at bolthole.com Tue Nov 17 18:12:19 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Nov 2009 09:12:19 -0800 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Message-ID: >(Dagobert writes) > I had this problem myself some times but didn't recognize the cause > properly: > ?grep filter-out */trunk/Makefile | grep CFLAGS > I even used argument-reordering on compile invocation for flac to > work around it which may have better be solved in the above way. > Now that I have understood it I would propose to remove > the "-I" from CFLAGS in GAR, but I am afraid that this may break > existing Makefiles as they may rely on it. This is especially true > for manual builds which pass CFLAGS explicitly without passing > CPPFLAGS explicitly. > > What do the C-gurus say? James? Anybody? > In my opinion, it belongs in CPPFLAGS, if you are going to force defaults. (and you should make sure to force our default as "first" :-) package builds that break, will break. Although most shouldnt. Ones that do, will have to be fixed when needed. From dam at opencsw.org Tue Nov 17 18:17:30 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 18:17:30 +0100 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <20091116.9573700.2235360213@gyor.oxdrove.co.uk> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> Message-ID: <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> Hi, Am 16.11.2009 um 10:57 schrieb James Lee: > On 13/11/09, 19:52:24, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] Change python modules catalog names to have a > py_ > prefix (instead of just py)?: > >> Having a consistent mapping between catalogname and >> packagenames is a Very Good Thing(tm), but I don't see >> how we can achieve it with the technology we have right now. > > It's completely achievable and always has been. People have > simply chosen not to. Don't put restricted characters in the > names, e.g. no '-' and '_'. Well, some packages do use "-" in the package name. All Maciej is aiming at is consistency. If we the mapping is "use _ on catalog names under condition x" and "package names are catalog name with '_' removed" that would ok also. Best regards -- Dago From maciej at opencsw.org Tue Nov 17 18:36:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 17:36:54 +0000 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: <1258476632-sup-1910@ntdws12.chass.utoronto.ca> <8FCB89D1-8D85-48BB-909A-FD758462DB7A@opencsw.org> Message-ID: On Tue, Nov 17, 2009 at 5:09 PM, Philip Brown wrote: >> Why do we need a default? The API make setting this mandatory. It may >> be good to have a default in the enclosing build system, but the maintainer >> should set a use-specific default. So I don't see a need that the inner >> build-systems need to handle defaults. >> > > err, are you speaking of "[the gar] build system"? or the "raw API" one? > I think you are referring to gar. the "raw API" one does not have > setting anything mandatory. > In order to keep discussion for this "raw api" thread simple (just > like the proposed API ;-), lets please keep discussions of GAR, to a > completely different thread GAR? What's GAR? ;-) I don't see anything inherently wrong with having a default. Just one thought. Imagine a newcomer who downloads the source, runs the build script and has no clue what files have been created and where. It could be a guideline (?) to print out a useful message at the end of the scripts work: your new shiny files have been created here and here. The default will make it possible for the script to work without any configuration, and the message will make it possible for a newcomer to find their way around the build system. Maciej From maciej at opencsw.org Tue Nov 17 18:50:55 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 17:50:55 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Message-ID: On Tue, Nov 17, 2009 at 5:12 PM, Philip Brown wrote: >>(Dagobert writes) >> I had this problem myself some times but didn't recognize the cause >> properly: >> ?grep filter-out */trunk/Makefile | grep CFLAGS >> I even used argument-reordering on compile invocation for flac to >> work around it which may have better be solved in the above way. >> Now that I have understood it I would propose to remove >> the "-I" from CFLAGS in GAR, but I am afraid that this may break >> existing Makefiles as they may rely on it. This is especially true >> for manual builds which pass CFLAGS explicitly without passing >> CPPFLAGS explicitly. >> >> What do the C-gurus say? James? Anybody? >> > > > In my opinion, it belongs in CPPFLAGS, if you are going to force defaults. Yes, CPPFLAGS are for the C PreProcessor, and it's the preprocessor that takes care of including files. References: http://stackoverflow.com/questions/495598/difference-between-cppflags-and-cxxflags-in-gnu-make http://en.wikipedia.org/wiki/CPPFLAGS > (and you should make sure to force our default as "first" :-) > > package builds that break, will break. Although most shouldnt. > Ones that do, will have to be fixed when needed. I second that. It's worth the trouble. If there's a build that needs includes to be passed via CFLAGS, it's not hard to add them by hand in the Makefile. Maciej From phil at bolthole.com Tue Nov 17 19:00:49 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Nov 2009 10:00:49 -0800 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Message-ID: On Tue, Nov 17, 2009 at 9:50 AM, Maciej (Matchek) Blizinski wrote: > > References: > ... > http://en.wikipedia.org/wiki/CPPFLAGS ooo, i learned something today. CFLAGS is officially for compiling *and linking* C code. I thought it was only for compiling. so adding -L/-R and other arcane stuff to CFLAGS is not technically improper. (Reason I mention this is that I usually add those to LDFLAGS.. but there was ONE program, that would not compile nicely unless I added something to CFLAGS when I thought I could only put it in LDFLAGS. The program was still wrong for not respecting LDFLAGS :-} but at least i feel better about the workaround now ;-) Although in retrospect, if CFLAGS is for linking also, I wonder why GNUheads decided to start using CCLDFLAGS recently? Grrr... From dam at opencsw.org Tue Nov 17 20:03:07 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 20:03:07 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Message-ID: Hi, Am 17.11.2009 um 18:50 schrieb Maciej (Matchek) Blizinski: > Yes, CPPFLAGS are for the C PreProcessor, and it's the preprocessor > that takes care of including files. > > References: > http://stackoverflow.com/questions/495598/difference-between-cppflags-and-cxxflags-in-gnu-make > http://en.wikipedia.org/wiki/CPPFLAGS > >> (and you should make sure to force our default as "first" :-) >> >> package builds that break, will break. Although most shouldnt. >> Ones that do, will have to be fixed when needed. > > I second that. It's worth the trouble. If there's a build that needs > includes to be passed via CFLAGS, it's not hard to add them by hand in > the Makefile. Ok then, I will prepare that for GAR and make a special page in the wiki with major changes to GAR and the revision they occured. That way a maintainer can simply look at all changes since the last build. Best regards -- Dago From james at opencsw.org Tue Nov 17 20:12:53 2009 From: james at opencsw.org (James Lee) Date: Tue, 17 Nov 2009 19:12:53 GMT Subject: [csw-maintainers] Could someone please update CSWpygtk? In-Reply-To: References: <20091117.11230400.3792129617@gyor.oxdrove.co.uk> Message-ID: <20091117.19125300.3743629234@gyor.oxdrove.co.uk> On 17/11/09, 16:52:27, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Could someone please update CSWpygtk?: > >> libtool: link: /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT > >> -D_PTHREADS -I/opt/csw/include/glib-2.0 > >> -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/python2.6 > >> -I/opt/csw/include/python2.6 -xO3 -xarch=386 -I/opt/csw/include > >> -xarch=386 -o generate-constants > >> generate_constants-generate-constants.o -lglib-2.0 -L/opt/csw/lib > >> ld: fatal: library -lglib-2.0: not found > >> ld: fatal: File processing errors. No output written to > >> generate-constants > > > >> I don't quite get it. The library is there on the disk: > > ... > >> There's also the -L/opt/csw/lib flag. What else does it need to find > >> the library? > > > > Our dear friend libtool. It's added the L path but after the lib. > Nope, look again: > > maciej at build8x [build8x]:~/src/opencsw/pkg/pygobject/trunk > (cd > > /home/maciej/src/opencsw/pkg/pygobject/trunk/work/solaris8-i386/ > > build-isa-i386/pygobject-2.20.0/gobject; > > /bin/bash ../libtool --tag=CC --mode=link > > /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT -D_PTHREADS > > -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include > > -I/opt/csw/include/python2.6 -I/opt/csw/include/python2.6 -lglib-2.0 > > -xO3 -xarch=386 -I/opt/csw/include -xarch=386 -L/opt/csw/lib -o > > generate-constants generate_constants-generate-constants.o) > The above is what is passed to libtool. Here the order is already wrong. > And I am not only saying this as the libtool-maintainer ;-) Libtool > than just passes the order: It's using ../libtool so we don't know if you can take credit. Did I say libtool had changed the order? True it's not the script libtool's choice but probably some other part in the "GNU build system" that has the args in the wrong order. The problem remains the same, args not in correct order. If anyone has any doubts about libtool's arg changing powers try: $ libtool --tag=CC --mode=link /bin/echo -o out -zone -lone -ztwo -ltwo James. From james at opencsw.org Tue Nov 17 20:14:43 2009 From: james at opencsw.org (James Lee) Date: Tue, 17 Nov 2009 19:14:43 GMT Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> Message-ID: <20091117.19144300.1872225613@gyor.oxdrove.co.uk> On 17/11/09, 17:17:30, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)?: > >> Having a consistent mapping between catalogname and > >> packagenames is a Very Good Thing(tm), but I don't see > >> how we can achieve it with the technology we have right now. > > > > It's completely achievable and always has been. People have > > simply chosen not to. Don't put restricted characters in the > > names, e.g. no '-' and '_'. > Well, some packages do use "-" in the package name. Only through choice, it's not the technology. > All Maciej > is aiming at is consistency. If we the mapping is "use _ on > catalog names under condition x" and "package names are > catalog name with '_' removed" that would ok also. A one way transform so I'd say not "between". You could exchange the '_' for '-' but it wouldn't help me to cut and paste the names. James. From maciej at opencsw.org Tue Nov 17 20:45:24 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 19:45:24 +0000 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <20091117.19144300.1872225613@gyor.oxdrove.co.uk> References: <4A91CB5A.4080109@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> Message-ID: On Tue, Nov 17, 2009 at 7:14 PM, James Lee wrote: > On 17/11/09, 17:17:30, Dagobert Michelsen wrote regarding > Re: [csw-maintainers] Change python modules catalog names to have a py_ > prefix (instead of just py)?: > >> >> Having a consistent mapping between catalogname and >> >> packagenames is a Very Good Thing(tm), but I don't see >> >> how we can achieve it with the technology we have right now. >> > >> > It's completely achievable and always has been. ?People have >> > simply chosen not to. ?Don't put restricted characters in the >> > names, e.g. no '-' and '_'. > >> Well, some packages do use "-" in the package name. > > Only through choice, it's not the technology. > > >> All Maciej >> is aiming at is consistency. If we the mapping is "use _ on >> catalog names under condition x" and "package names are >> catalog name with '_' removed" that would ok also. > > A one way transform so I'd say not "between". ?You could exchange > the '_' for '-' but it wouldn't help me to cut and paste the names. I like the idea of s/_/-/g when going from catalog names to pkgnames. Thissentenceismymainargumentforusingdashesitsjusthardtoread. I would really like to have a blessed word separator for the pkgnames. Sun packages uses cases, the have something like SUNWonewordSECONDWORD. I perceive it as ugly. Speaking of consistency... we can make the choice of being consistent with the existing packages[1] and not introduce dashes. Or we can use dashes for new packages, leaving the current ones alone, to be possibly changed later, if we decide it's important. The consistency I'm definitely for is that we achieve consensus, it gets documented, and we follow it. [1] Currently, there are 48 pkgnames using dashes, out of the total 2171. Maciej From bchill at opencsw.org Tue Nov 17 21:54:53 2009 From: bchill at opencsw.org (Brian Hill) Date: Tue, 17 Nov 2009 20:54:53 +0000 Subject: [csw-maintainers] /testing cfengine, cvsproxy, diffuse, oinkmaster, perl, snort In-Reply-To: <625385e30911170911o7e76ae6bme982ec90ccd7fdc8@mail.gmail.com> References: <625385e30911170911o7e76ae6bme982ec90ccd7fdc8@mail.gmail.com> Message-ID: <20091117205453.GA9219@vm-1.bch.net> I grabbed cfengine-2.2.10 and perl-5.8.8, both of which I use heavily, and they seem to be working well, except that CFE complained about about these two DB files being in an unrecognized format (because you have to get the newer bdb as well): cf_LastSeen.db performance.db Since I don't make use of these, simply deleting them wasn't a problem for me. Brian ====================================================================== On Tue, Nov 17, 2009 at 06:11:35PM +0100, Peter Bonivart wrote: > I would like some help testing a few packages. If you use any of the > below packages in their current versions and have time to test these I > would really appreciate it. > > Note that if you want to test cvsproxy you need to be aware of this > bug in the current package: > http://www.opencsw.org/mantis/view.php?id=1839. > > cfengine-2.2.10,REV=2009.11.11-SunOS5.8-i386-CSW.pkg.gz > cfengine-2.2.10,REV=2009.11.11-SunOS5.8-sparc-CSW.pkg.gz > cfengine_doc-2.2.10,REV=2009.11.11-SunOS5.8-all-CSW.pkg.gz > cvsproxy-1.0.1,REV=2009.11.01-SunOS5.8-i386-CSW.pkg.gz > cvsproxy-1.0.1,REV=2009.11.01-SunOS5.8-sparc-CSW.pkg.gz > diffuse-0.4.1,REV=2009.10.21-SunOS5.8-all-CSW.pkg.gz > oinkmaster-2.0,REV=2009.10.19-SunOS5.8-all-CSW.pkg.gz > perl-5.8.8,REV=2009.11.12-SunOS5.8-i386-CSW.pkg.gz > perl-5.8.8,REV=2009.11.12-SunOS5.8-sparc-CSW.pkg.gz > perldoc-5.8.8,REV=2009.11.12-SunOS5.8-all-CSW.pkg.gz > snort-2.8.5,REV=2009.10.19-SunOS5.8-i386-CSW.pkg.gz > snort-2.8.5,REV=2009.10.19-SunOS5.8-sparc-CSW.pkg.gz > > http://mirror.opencsw.org/testing.html > > -- > /peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers -- _____________________________________________________________________ / Brian C. Hill bchill at bch.net http://brian.bch.net \ | UNIX Specialist BCH Technical Services http://www.bch.net | From phil at bolthole.com Tue Nov 17 21:56:02 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Nov 2009 12:56:02 -0800 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> Message-ID: On Tue, Nov 17, 2009 at 11:45 AM, Maciej (Matchek) Blizinski wrote: > > I like the idea of s/_/-/g when going from catalog names to pkgnames. > Thissentenceismymainargumentforusingdashesitsjusthardtoread. ?I would > really like to have a blessed word separator for the pkgnames. ?Sun > packages uses cases, the have something like SUNWonewordSECONDWORD. ?I > perceive it as ugly. > > > The consistency I'm definitely for is that we achieve consensus, it > gets documented, and we follow it. > well, in some cases, the CSWxxx name doesnt realliyhave to be "readable", that's what our "software name" is for. the PKG name is there almost just as a placeholder. and an argument AGAINST having - in the names: CSWxxx-yyy does not double-click-select in xterm. you ahve to click and drag to select it. in contrast, some_software_name selects as a single word. So, another vote for "no - in PKG names at all", if we are insisting on One True Standard. From dam at opencsw.org Tue Nov 17 22:29:12 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 22:29:12 +0100 Subject: [csw-maintainers] FFI for libshout: Ruby, OCaml, Python, Java Message-ID: <4DBBF4DA-EDB3-46A9-B8FD-B96AD697E556@opencsw.org> Hi folks, I just packaged up libshout with full dependencies and 32/64 bit and the Perl language binding. In addition to that there are a lot of other language bindings which the respective maintainers may want to pick up. This is especially: - Ruby - Objective CAML - Python - Java All bindings are available from http://www.icecast.org/download.php libshout is already installed on the farm :-) Best regards -- Dago From bwalton at opencsw.org Wed Nov 18 01:19:14 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 17 Nov 2009 19:19:14 -0500 Subject: [csw-maintainers] FFI for libshout: Ruby, OCaml, Python, Java In-Reply-To: <4DBBF4DA-EDB3-46A9-B8FD-B96AD697E556@opencsw.org> References: <4DBBF4DA-EDB3-46A9-B8FD-B96AD697E556@opencsw.org> Message-ID: <1258503478-sup-4476@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Nov 17 16:29:12 -0500 2009: > bindings which the respective maintainers may want to pick up. This is > especially: > > - Ruby Is there user demand for this? I'll package it on request, but since I myself don't need it, I won't rush to do it right away. I actually don't like to package things I don't use personally, since I'm not as intimate with them and may not spot obvious packaging/functionality issues. 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 Nov 18 09:56:22 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 08:56:22 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Message-ID: Continuing the postgresql topic, I've written a first sketch of the new file layout proposal. It's now submitted into the repository. I think that GAR hasn't seen this file layout before and is slightly confused about handling 32 and 64-bit binaries. For instance, the 32-bit and 64-bit install directories look like this: > ls work/solaris8-sparc/install-isa-sparcv*/opt/csw/bin/postgresql/8.4/initdb work/solaris8-sparc/install-isa-sparcv8/opt/csw/bin/postgresql/8.4/initdb work/solaris8-sparc/install-isa-sparcv9/opt/csw/bin/postgresql/8.4/initdb Both v8 and v9 binaries are there, but: > ggrep initdb work/solaris8-sparc/build-global/CSWpostgresql.prototype-sparc l none /opt/csw/bin/postgresql/8.4/initdb=/opt/csw/bin/isaexec 0755 root bin f none /opt/csw/bin/postgresql/8.4/sparcv8/initdb=/opt/csw/bin/postgresql/8.4/initdb 0755 root bin f none /opt/csw/bin/sparcv9/initdb 0755 root bin ...the v9 binary not where I'd expect it to be. It sounds like a GAR issue. I can already see Dago swearing at this yet another special case... ;-) Maciej From maciej at opencsw.org Wed Nov 18 10:06:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 09:06:01 +0000 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin Message-ID: Maintainers, There's a user request to create symlinks from /usr/bin to /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. http://www.opencsw.org/mantis/view.php?id=2924 I think there might be a use case for it, but at the same time, why not just set the PATH? I don't mind creating such package, but we're not putting anything into /usr/bin by the rule. What are your thoughts? Create a package with symlinks or not? Maciej From dam at opencsw.org Wed Nov 18 10:16:33 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 10:16:33 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Message-ID: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Hi Maciej, Am 18.11.2009 um 09:56 schrieb Maciej (Matchek) Blizinski: > Continuing the postgresql topic, I've written a first sketch of the > new file layout proposal. It's now submitted into the repository. I > think that GAR hasn't seen this file layout before and is slightly > confused about handling 32 and 64-bit binaries. For instance, the > 32-bit and 64-bit install directories look like this: > >> ls work/solaris8-sparc/install-isa-sparcv*/opt/csw/bin/postgresql/ >> 8.4/initdb > work/solaris8-sparc/install-isa-sparcv8/opt/csw/bin/postgresql/8.4/ > initdb > work/solaris8-sparc/install-isa-sparcv9/opt/csw/bin/postgresql/8.4/ > initdb > > Both v8 and v9 binaries are there, but: > >> ggrep initdb work/solaris8-sparc/build-global/ >> CSWpostgresql.prototype-sparc > l none /opt/csw/bin/postgresql/8.4/initdb=/opt/csw/bin/isaexec 0755 > root bin > f none /opt/csw/bin/postgresql/8.4/sparcv8/initdb=/opt/csw/bin/ > postgresql/8.4/initdb > 0755 root bin > f none /opt/csw/bin/sparcv9/initdb 0755 root bin > > ...the v9 binary not where I'd expect it to be. It sounds like a GAR > issue. I can already see Dago swearing at this yet another special > case... ;-) I don't think it is a special case. Most likely there is a wrong basedirectory applied in GAR during merge. I'll take a look... Best regards -- Dago From dam at opencsw.org Wed Nov 18 10:23:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 10:23:19 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: <14D4A7F6-9DB1-4C5E-BC1C-2F27E6FE5155@opencsw.org> Hi Maciej, Am 18.11.2009 um 10:06 schrieb Maciej (Matchek) Blizinski: > There's a user request to create symlinks from /usr/bin to > /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. > > http://www.opencsw.org/mantis/view.php?id=2924 > > I think there might be a use case for it, but at the same time, why > not just set the PATH? I don't mind creating such package, but we're > not putting anything into /usr/bin by the rule. What are your > thoughts? Create a package with symlinks or not? Well, I have at least one customer who needs it that way :-) Best regards -- Dago From dam at opencsw.org Wed Nov 18 10:43:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 10:43:18 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: Hi Maciej, Am 18.11.2009 um 10:16 schrieb Dagobert Michelsen: >> Both v8 and v9 binaries are there, but: >> >>> ggrep initdb work/solaris8-sparc/build-global/ >>> CSWpostgresql.prototype-sparc >> l none /opt/csw/bin/postgresql/8.4/initdb=/opt/csw/bin/isaexec 0755 >> root bin >> f none /opt/csw/bin/postgresql/8.4/sparcv8/initdb=/opt/csw/bin/ >> postgresql/8.4/initdb >> 0755 root bin >> f none /opt/csw/bin/sparcv9/initdb 0755 root bin >> >> ...the v9 binary not where I'd expect it to be. It sounds like a GAR >> issue. I can already see Dago swearing at this yet another special >> case... ;-) > > I don't think it is a special case. Most likely there is a wrong > basedirectory applied in GAR during merge. I'll take a look... Umh... I can't reproduce it: > build8s% ggrep initdb work/solaris8-sparc/build-global/ > CSWpostgresql.prototype-sparc > l none /opt/csw/postgresql/bin/initdb=/opt/csw/bin/isaexec 0755 root > bin > f none /opt/csw/postgresql/bin/sparcv8/initdb=/opt/csw/postgresql/ > bin/initdb 0755 root bin > f none /opt/csw/postgresql/bin/sparcv9/initdb 0755 root bin > f none /opt/csw/postgresql/share/man/man1/initdb.1 0644 root bin Would you mind doing a "gmake repackage" and see if the error persists? I haven't changed anything. Best regards -- Dago From maciej at opencsw.org Wed Nov 18 10:49:16 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 09:49:16 +0000 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: <14D4A7F6-9DB1-4C5E-BC1C-2F27E6FE5155@opencsw.org> References: <14D4A7F6-9DB1-4C5E-BC1C-2F27E6FE5155@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 9:23 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 18.11.2009 um 10:06 schrieb Maciej (Matchek) Blizinski: >> >> There's a user request to create symlinks from /usr/bin to >> /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. >> >> http://www.opencsw.org/mantis/view.php?id=2924 >> >> I think there might be a use case for it, but at the same time, why >> not just set the PATH? ?I don't mind creating such package, but we're >> not putting anything into /usr/bin by the rule. ?What are your >> thoughts? ?Create a package with symlinks or not? > > Well, I have at least one customer who needs it that way :-) All right, I'm rolling a it now then! Will be in testing later day. Maciej From dam at opencsw.org Wed Nov 18 10:51:07 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 10:51:07 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> Hi Maciej, Am 18.11.2009 um 10:43 schrieb Dagobert Michelsen: > Am 18.11.2009 um 10:16 schrieb Dagobert Michelsen: >>> Both v8 and v9 binaries are there, but: >>> >>>> ggrep initdb work/solaris8-sparc/build-global/ >>>> CSWpostgresql.prototype-sparc >>> l none /opt/csw/bin/postgresql/8.4/initdb=/opt/csw/bin/isaexec >>> 0755 root bin >>> f none /opt/csw/bin/postgresql/8.4/sparcv8/initdb=/opt/csw/bin/ >>> postgresql/8.4/initdb >>> 0755 root bin >>> f none /opt/csw/bin/sparcv9/initdb 0755 root bin >>> >>> ...the v9 binary not where I'd expect it to be. It sounds like a >>> GAR >>> issue. I can already see Dago swearing at this yet another special >>> case... ;-) BTW: Make sure to read files/README-CSW.txt. It is stated in there that the databases for 32 and 64 bit are not compatible, so I am pretty sure you don't want isaexec anywhere in the package, but want to select 32/64 explicitly as also stated in the README. Best regards, and thanks for doing postgres! -- Dago From maciej at opencsw.org Wed Nov 18 10:55:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 09:55:58 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 9:43 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 18.11.2009 um 10:16 schrieb Dagobert Michelsen: >>> >>> Both v8 and v9 binaries are there, but: >>> >>>> ggrep initdb >>>> work/solaris8-sparc/build-global/CSWpostgresql.prototype-sparc >>> >>> l none /opt/csw/bin/postgresql/8.4/initdb=/opt/csw/bin/isaexec 0755 root >>> bin >>> f none >>> /opt/csw/bin/postgresql/8.4/sparcv8/initdb=/opt/csw/bin/postgresql/8.4/initdb >>> 0755 root bin >>> f none /opt/csw/bin/sparcv9/initdb 0755 root bin >>> >>> ...the v9 binary not where I'd expect it to be. ?It sounds like a GAR >>> issue. ?I can already see Dago swearing at this yet another special >>> case... ;-) >> >> I don't think it is a special case. Most likely there is a wrong >> basedirectory applied in GAR during merge. I'll take a look... > > Umh... I can't reproduce it: > >> build8s% ggrep initdb >> work/solaris8-sparc/build-global/CSWpostgresql.prototype-sparc >> l none /opt/csw/postgresql/bin/initdb=/opt/csw/bin/isaexec 0755 root bin >> f none >> /opt/csw/postgresql/bin/sparcv8/initdb=/opt/csw/postgresql/bin/initdb 0755 >> root bin >> f none /opt/csw/postgresql/bin/sparcv9/initdb 0755 root bin >> f none /opt/csw/postgresql/share/man/man1/initdb.1 0644 root bin > > Would you mind doing a "gmake repackage" and see if the error persists? > I haven't changed anything. It persists. Your example looks different from mine: You have /opt/csw/postgresql/bin/initdb, I have /opt/csw/bin/postgresql/8.4/initdb. Maciej From dam at opencsw.org Wed Nov 18 11:04:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 11:04:22 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: Hi Maciej, Am 18.11.2009 um 10:55 schrieb Maciej (Matchek) Blizinski: > It persists. Your example looks different from mine: You have > /opt/csw/postgresql/bin/initdb, I have > /opt/csw/bin/postgresql/8.4/initdb. I build freshly. Did you change configure options or directories without making "gmake clean"? This completely confuses GAR. Please retry the complete build and I am pretty sure that the error will then be gone as this is what I did ;-) Best regards -- Dago From maciej at opencsw.org Wed Nov 18 11:17:27 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 10:17:27 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 9:51 AM, Dagobert Michelsen wrote: > BTW: Make sure to read files/README-CSW.txt. It is stated in there > that the databases for 32 and 64 bit are not compatible, so I am pretty > sure you don't want isaexec anywhere in the package, but want to > select 32/64 explicitly as also stated in the README. I understand the incompatibility. I don't understand why would it matter. Machine's architecture doesn't change after installation. If it's 64-bit, it's always been and always will be, until the machine is retired. There might be a problem when someone has been running 32-bit binaries on a 64-bit machine and now switches to the 64-bit enabled PostgreSQL. In such a they should downgrade their package back to the 32-bit and do the dump/restore dance. However, if they upgrade from 8.3 to 8.4 (which is the case here), they will have to do this anyway. I also think that the PGCTL explicit setting is a non-solution. It makes people run 32-bit binaries on 64-bit machines by default, which wastes the migration effort: they could've migrated from 32-bit 8.3 to 64-bit 8.4, but they only migrated from 32-bit 8.3 to 32-bit 8.4. I assert that using isaexec in 8.4 is no worse than using explicit architecture setting in 8.4. Thoughts? Maciej From maciej at opencsw.org Wed Nov 18 12:04:52 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 11:04:52 +0000 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> Message-ID: On Tue, Nov 17, 2009 at 8:56 PM, Philip Brown wrote: > On Tue, Nov 17, 2009 at 11:45 AM, Maciej (Matchek) Blizinski > wrote: >> >> I like the idea of s/_/-/g when going from catalog names to pkgnames. >> Thissentenceismymainargumentforusingdashesitsjusthardtoread. ?I would >> really like to have a blessed word separator for the pkgnames. ?Sun >> packages uses cases, the have something like SUNWonewordSECONDWORD. ?I >> perceive it as ugly. >> >> >> The consistency I'm definitely for is that we achieve consensus, it >> gets documented, and we follow it. >> > > well, in some cases, the CSWxxx name doesnt realliyhave to be > "readable", that's what our "software name" is for. ?the PKG name is > there almost just as a placeholder. > > and an argument AGAINST having - in the names: > > CSWxxx-yyy ?does not double-click-select in xterm. you ahve to click > and drag to select it. > in contrast, some_software_name selects as a single word. Looks like your terminal emulator is broken. Pick a non-broken one or fix yours! ;-) > So, another vote for "no - in PKG names at all", if we are insisting > on One True Standard. Should we write up the pros and cons so we can have a nice overview picture of the pros and cons? I'd also like to point out that what I would like to have is not the dash character explicitly, what I'd like to have is a word separator. It can be dashes, underscores, CamelCase, or anything else, I don't care what specifically. I would just like to be able to have visually separate words in the pkgnames. Maciej From maciej at opencsw.org Wed Nov 18 12:07:41 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 11:07:41 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 10:04 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 18.11.2009 um 10:55 schrieb Maciej (Matchek) Blizinski: >> >> It persists. ?Your example looks different from mine: You have >> /opt/csw/postgresql/bin/initdb, I have >> /opt/csw/bin/postgresql/8.4/initdb. > > I build freshly. Did you change configure options or directories > without making "gmake clean"? This completely confuses GAR. > Please retry the complete build and I am pretty sure that the > error will then be gone as this is what I did ;-) I did a clean build. Which revision are you building? Mine is: maciej at build8s [build8s]:~/src/opencsw/pkg/postgresql/trunk > svn info Makefile Path: Makefile Name: Makefile URL: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/postgresql/trunk/Makefile Repository Root: https://gar.svn.sourceforge.net/svnroot/gar Repository UUID: d3b55034-1cff-0310-a425-aefe953e1e90 Revision: 7334 Node Kind: file Schedule: normal Last Changed Author: wahwah Last Changed Rev: 7334 Last Changed Date: 2009-11-17 23:16:07 +0100 (Tue, 17 Nov 2009) Text Last Updated: 2009-11-17 23:15:04 +0100 (Tue, 17 Nov 2009) Checksum: edc1ba9fb66f6c7e3ecce9497ef71d08 Maciej From james at opencsw.org Wed Nov 18 12:20:21 2009 From: james at opencsw.org (James Lee) Date: Wed, 18 Nov 2009 11:20:21 GMT Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: <20091118.11202100.2985158056@gyor.oxdrove.co.uk> On 18/11/09, 09:06:01, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin: > There's a user request to create symlinks from /usr/bin to > /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. I think it's not good. It will fail in a zone with global /usr. Same question applies to /usr/lib/sendmail. Too many bad programs hard code sendmail in - that's tautology hard coding sendmail defines a program as bad! James. From james at opencsw.org Wed Nov 18 12:21:25 2009 From: james at opencsw.org (James Lee) Date: Wed, 18 Nov 2009 11:21:25 GMT Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> Message-ID: <20091118.11212500.3339303609@gyor.oxdrove.co.uk> On 18/11/09, 10:17:27, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] Building postgresql-8.4.1: > It makes > people run 32-bit binaries on 64-bit machines by default, which wastes > the migration effort: they could've migrated from 32-bit 8.3 to 64-bit > 8.4, but they only migrated from 32-bit 8.3 to 32-bit 8.4. I understand it's a waste running 64 bit when it's not needed, only those that really need it do so, hence the default is 32 and the choice is there. James. From james at opencsw.org Wed Nov 18 13:09:59 2009 From: james at opencsw.org (James Lee) Date: Wed, 18 Nov 2009 12:09:59 GMT Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> Message-ID: <20091118.12095900.1758710002@gyor.oxdrove.co.uk> On 17/11/09, 20:56:02, Philip Brown wrote regarding Re: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)?: > well, in some cases, the CSWxxx name doesnt realliyhave to be > "readable", that's what our "software name" is for. the PKG name is > there almost just as a placeholder. It doesn't have to match but it makes life so much easier. Any reason not to make it meaningful? Good: pkg-get -i foobar -> installs CSWfoobar Bad: pkg-get -i foobar -> installs CSWfb Daft: pkg-get -i foobar -> installs CSWx9 The system uses package name. After install the software name is not needed and since pkg-get was revised we can even install with package name. James. From james at opencsw.org Wed Nov 18 13:14:31 2009 From: james at opencsw.org (James Lee) Date: Wed, 18 Nov 2009 12:14:31 GMT Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> Message-ID: <20091118.12143100.3993068214@gyor.oxdrove.co.uk> On 18/11/09, 11:04:52, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)?: > > and an argument AGAINST having - in the names: > > > > CSWxxx-yyy ??does not double-click-select in xterm. you ahve to click > > and drag to select it. > > in contrast, some_software_name selects as a single word. > Looks like your terminal emulator is broken. Pick a non-broken one or > fix yours! ;-) It's not broken, it's quite normal. e.g. perl regexp \w includes alphanumeric and '_' but not '-'. My comment about pasting is: cut the software name, type "CSW", paste. I wish it to result in package name. I'd also like a machine capable transform. I'm happy doing: pacakgeHome.findBySoftwareName("foobar").getPackageName(); just to get "CSWfoobar" when hitting the problem with a J2EE sledgehammer but in simple scripts it would be useful to... #!/bin/ksh softwareName="foobar" echo "software name: ${softwareName}" packageName="CSW${softwareName}" echo "package name from software name: ${packageName}" echo "software name from package name: ${packageName#CSW}" ...this passed by long ago. 's/_/-/g' and the reverse can used in scripts but then the quick script becomes more complicated than using my J2EE. James. From maciej at opencsw.org Wed Nov 18 13:46:07 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 12:46:07 +0000 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <20091118.12143100.3993068214@gyor.oxdrove.co.uk> References: <4A91CB5A.4080109@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> <20091118.12143100.3993068214@gyor.oxdrove.co.uk> Message-ID: On Wed, Nov 18, 2009 at 12:14 PM, James Lee wrote: > On 18/11/09, 11:04:52, Maciej "(Matchek)" Blizinski > wrote regarding Re: [csw-maintainers] Change python modules catalog names > to have a py_ prefix (instead of just py)?: > >> > and an argument AGAINST having - in the names: >> > >> > CSWxxx-yyy ??does not double-click-select in xterm. you ahve to click >> > and drag to select it. >> > in contrast, some_software_name selects as a single word. > >> Looks like your terminal emulator is broken. ?Pick a non-broken one or >> fix yours! ;-) > > It's not broken, it's quite normal. ?e.g. perl regexp \w includes > alphanumeric and '_' but not '-'. I was mocking the misuse of the absolute term 'broken' when all it means it a subjective "your software doesn't work the way I think it should". > My comment about pasting is: cut the software name, type "CSW", paste. > I wish it to result in package name. > > > I'd also like a machine capable transform. ?I'm happy doing: > ? ? ? ?pacakgeHome.findBySoftwareName("foobar").getPackageName(); > just to get "CSWfoobar" when hitting the problem with a J2EE sledgehammer > but in simple scripts it would be useful to... > > #!/bin/ksh > > softwareName="foobar" > echo "software name: ${softwareName}" > packageName="CSW${softwareName}" > echo "package name from software name: ${packageName}" > echo "software name from package name: ${packageName#CSW}" > > ...this passed by long ago. > > 's/_/-/g' and the reverse can used in scripts but then the quick script > becomes more complicated than using my J2EE. Any other ideas for a word separator? From dam at opencsw.org Wed Nov 18 14:10:58 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 14:10:58 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> Message-ID: <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> Hi Maciej, Am 18.11.2009 um 11:17 schrieb Maciej (Matchek) Blizinski: > On Wed, Nov 18, 2009 at 9:51 AM, Dagobert Michelsen > wrote: >> BTW: Make sure to read files/README-CSW.txt. It is stated in there >> that the databases for 32 and 64 bit are not compatible, so I am >> pretty >> sure you don't want isaexec anywhere in the package, but want to >> select 32/64 explicitly as also stated in the README. > > I understand the incompatibility. I don't understand why would it > matter. Machine's architecture doesn't change after installation. If > it's 64-bit, it's always been and always will be, until the machine is > retired. > > There might be a problem when someone has been running 32-bit binaries > on a 64-bit machine and now switches to the 64-bit enabled PostgreSQL. > In such a they should downgrade their package back to the 32-bit and > do the dump/restore dance. However, if they upgrade from 8.3 to 8.4 > (which is the case here), they will have to do this anyway. I also > think that the PGCTL explicit setting is a non-solution. It makes > people run 32-bit binaries on 64-bit machines by default, which wastes > the migration effort: they could've migrated from 32-bit 8.3 to 64-bit > 8.4, but they only migrated from 32-bit 8.3 to 32-bit 8.4. I assert > that using isaexec in 8.4 is no worse than using explicit architecture > setting in 8.4. > > Thoughts? You assume that using 64 bit is always better than using 32 bit. This is not the case. If you need more than 2 GB of RAM or have large databases you are right. But if the database is not that big you are better off using 32 bit. IMHO it is good to automatically make the 32/64 bit decision under the following circumstances: (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 see that any of the above applies in the case of postgres. Best regards -- Dago From bonivart at opencsw.org Wed Nov 18 14:29:06 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 18 Nov 2009 14:29:06 +0100 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> <20091118.12143100.3993068214@gyor.oxdrove.co.uk> Message-ID: <625385e30911180529p1f0debfaj837d03934072ead6@mail.gmail.com> On Wed, Nov 18, 2009 at 1:46 PM, Maciej (Matchek) Blizinski wrote: > Any other ideas for a word separator? Why do we need a word separator? The names are short and readability isn't enhanced that much by a separator. CSWperldoc -> CSWperl-doc perldoc -> perl_doc My vote goes to using neither dashes nor underscores for new packages. -- /peter From dam at opencsw.org Wed Nov 18 14:34:00 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 14:34:00 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: <20091118.11202100.2985158056@gyor.oxdrove.co.uk> References: <20091118.11202100.2985158056@gyor.oxdrove.co.uk> Message-ID: <728DE690-8397-4803-9B81-F029B5167CF6@opencsw.org> Hi, Am 18.11.2009 um 12:20 schrieb James Lee: > On 18/11/09, 09:06:01, Maciej "(Matchek)" Blizinski > > wrote regarding [csw-maintainers] User requests symlinking from /usr/ > bin > to > /opt/csw/bin: > >> There's a user request to create symlinks from /usr/bin to >> /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. > > I think it's not good. > > It will fail in a zone with global /usr. It is a purely optional package that depends on cups and its whole purpose is to replace the SysV-lp system. Nothing more. If you don't want the system replaced you don't install this package. We may choose a slightly modifed prefix like CSWScups (CSW Solaris cups) or something to mark that it doesn't install in /opt/csw but replaced Solaris core functionality. Best regards -- Dago From bonivart at opencsw.org Wed Nov 18 16:00:35 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 18 Nov 2009 16:00:35 +0100 Subject: [csw-maintainers] /testing cfengine, cvsproxy, diffuse, oinkmaster, perl, snort In-Reply-To: <20091117205453.GA9219@vm-1.bch.net> References: <625385e30911170911o7e76ae6bme982ec90ccd7fdc8@mail.gmail.com> <20091117205453.GA9219@vm-1.bch.net> Message-ID: <625385e30911180700l21c7472y67b655c7ff195249@mail.gmail.com> On Tue, Nov 17, 2009 at 9:54 PM, Brian Hill wrote: > ? ? ? ?I grabbed cfengine-2.2.10 and perl-5.8.8, both of which I use > heavily, and they seem to be working well, except that CFE complained > about about these two DB files being in an unrecognized format (because > you have to get the newer bdb as well): > > ? ? ? ?cf_LastSeen.db > ? ? ? ?performance.db > > ? ? ? ?Since I don't make use of these, simply deleting them wasn't a > problem for me. Thanks a lot for that report, I've been running that perl package for a while myself but I can't test cfengine right now. -- /peter From phil at bolthole.com Wed Nov 18 18:09:23 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Nov 2009 09:09:23 -0800 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: On Wed, Nov 18, 2009 at 1:06 AM, Maciej (Matchek) Blizinski wrote: > Maintainers, > > There's a user request to create symlinks from /usr/bin to > /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. > > http://www.opencsw.org/mantis/view.php?id=2924 > > I think there might be a use case for it, but at the same time, why > not just set the PATH? ?I don't mind creating such package, but we're > not putting anything into /usr/bin by the rule. ?What are your > thoughts? ?Create a package with symlinks or not? > Hmm... there then becomes a question of, what to put in the package? for example, we have a gnu links package, that links ALL (or at least most) of the g-prefixed GNU utilities in /opt/csw/bin, to /opt/csw/gnu. That is a cross-package set of links. Should we do the same for this sort of request? If so, which packages/programs should we include symlinks for? or should we make a whole bunch of separate CSWxxx"links" packages? OR... should we make a metapackage, with some sort of config file, and let the user decide? eg: CSWusrlinks, which will reference one or both of /opt/csw/etc/cswusrlinks.conf /etc/opt/csw/cswusrlinks.conf and then if CSWxyz is mentioned there, it will make symlinks into /usr for that package. (in a postinstall script) ORRRRR... do we create another cswclassutils class, where either individual files can be set as in the "usrlinks" class, or it provides a config file, "if the user wants symlinks into usr for my package, make symlinks for the following files automatically..." I think this last one is perhaps the best long term option. for one reason, because it uses class action scripts instead of postinstall scripts, so it is the most future-proof. From phil at bolthole.com Wed Nov 18 18:11:28 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Nov 2009 09:11:28 -0800 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 5:10 AM, Dagobert Michelsen wrote: >.... > You assume that using 64 bit is always better than using 32 bit. This > is not the case. If you need more than 2 GB of RAM or have large > databases you are right. But if the database is not that big you are > better off using 32 bit.[....] > I don't see that any of the above applies in the case of postgres. > yup. it is exactly for these reasons, that our (old, yes) mysql package, provides BOTH 32bit and 64bit database binaries, and lets the user decide which one they wish to run. NO use of isaexec. From phil at bolthole.com Wed Nov 18 18:19:32 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Nov 2009 09:19:32 -0800 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <625385e30911180529p1f0debfaj837d03934072ead6@mail.gmail.com> References: <4A91CB5A.4080109@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> <20091118.12143100.3993068214@gyor.oxdrove.co.uk> <625385e30911180529p1f0debfaj837d03934072ead6@mail.gmail.com> Message-ID: On Wed, Nov 18, 2009 at 5:29 AM, Peter Bonivart wrote: > > > Why do we need a word separator? The names are short and readability > isn't enhanced that much by a separator. > > CSWperldoc -> CSWperl-doc > perldoc -> perl_doc > > My vote goes to using neither dashes nor underscores for new packages. > well, that certainly would make for consistency From dam at opencsw.org Wed Nov 18 18:21:00 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 18:21:00 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: Hi Phil, Am 18.11.2009 um 18:09 schrieb Philip Brown: > Hmm... there then becomes a question of, what to put in the package? > > for example, we have a gnu links package, that links ALL (or at least > most) of the g-prefixed GNU utilities in /opt/csw/bin, to > /opt/csw/gnu. > > That is a cross-package set of links. > Should we do the same for this sort of request? > If so, which packages/programs should we include symlinks for? > > or should we make a whole bunch of separate CSWxxx"links" packages? > > > OR... should we make a metapackage, with some sort of config file, and > let the user decide? > > eg: CSWusrlinks, which will reference one or both of > > /opt/csw/etc/cswusrlinks.conf > /etc/opt/csw/cswusrlinks.conf > > and then if CSWxyz is mentioned there, it will make symlinks into /usr > for that package. > (in a postinstall script) > > ORRRRR... do we create another cswclassutils class, where either > individual files can be set as in the "usrlinks" class, or it provides > a config file, "if the user wants symlinks into usr for my package, > make symlinks for the following files automatically..." > > I think this last one is perhaps the best long term option. for one > reason, because it uses class action scripts instead of postinstall > scripts, so it is the most future-proof. I prefer the way Maciej has done it: with a separete package per software (Cups in this case), marked incompatible to the Solaris packages it replaces. You can't have that with classutils. And it is cleanly separated from the CSW-only packages. If the "-ln" suffix is consistent may be discussed, in the current naming scheme "CSWcupslinks" would IMHO be better, but that is another thing. Best regards -- Dago From maciej at opencsw.org Wed Nov 18 18:57:45 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 17:57:45 +0000 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: On Wed, Nov 18, 2009 at 5:21 PM, Dagobert Michelsen wrote: > is cleanly separated from the CSW-only packages. If the "-ln" > suffix is consistent may be discussed, in the current naming > scheme "CSWcupslinks" would IMHO be better, but that is another > thing. I couldn't decide which was better. I had the following ideas: CSWcupsln CSWcupslinks CSWcupslpdcompat CSWcupsusrbin CSWcups-ln CSWcups-links CSWcups-lpdcompat CSWcups-usrbin CSWcupsclientln CSWcupsclientlinks CSWcupsclientlpdcompat CSWcupsclientusrbin CSWcupsclient-ln CSWcupsclient-links CSWcupsclient-lpdcompat CSWcupsclient-usrbin Which one do you like best? Maciej From phil at bolthole.com Wed Nov 18 19:11:52 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Nov 2009 10:11:52 -0800 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: On Wed, Nov 18, 2009 at 9:21 AM, Dagobert Michelsen wrote: > > I prefer the way Maciej has done it: with a separete package per > software (Cups in this case), marked incompatible to the Solaris > packages it replaces. eu, ick. I didnt notice that "feature". I dont think we have any business conflicting with packages that arent "ours". From phil at bolthole.com Wed Nov 18 19:16:40 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Nov 2009 10:16:40 -0800 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: On Wed, Nov 18, 2009 at 10:11 AM, Philip Brown wrote: > >... > I dont think we have any business conflicting with packages that arent "ours". > Let me give just one explicit example of why: "pkg-get install all" From skayser at opencsw.org Wed Nov 18 23:02:55 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 18 Nov 2009 23:02:55 +0100 Subject: [csw-maintainers] New cswclassutils: cswcron, cswtexinfo, cswmigrateconf and GAR integration In-Reply-To: <0691F15A-1BF5-4817-968F-449FC848E2D7@opencsw.org> References: <0691F15A-1BF5-4817-968F-449FC848E2D7@opencsw.org> Message-ID: <4B046F0F.6060509@opencsw.org> Hi Dago, Dagobert Michelsen wrote on 11.11.2009 15:58: > as of r7226 and cswclassutils 1.28 there is support for three new > classes: > > - cswcron allows modifying of the crontab > - cswtexinfo allows automatic addition of .info files to the texinfo dir > - cswmigrateconf allows easy migration of config files from /opt/csw/etc > to /etc/opt/csw > > The usage has been documented at > i have been trying to leverage MIGRATE_FILES for axel, the cswmigrateconf stays empty though. ... sysconfdir = /etc/opt/csw SAMPLECONF = $(sysconfdir)/axelrc MIGRATE_FILES = axelrc ... skayser @ build8x ~/mgar/pkg/axel/trunk$ cat work/solaris8-i386/pkgroot/etc/opt/csw/pkg/CSWaxel/cswmigrateconf MIGRATE_FILES="" Build files are checked in, would you mind having a look? Sebastian From glaw at opencsw.org Thu Nov 19 00:26:09 2009 From: glaw at opencsw.org (Gary Law) Date: Wed, 18 Nov 2009 23:26:09 +0000 Subject: [csw-maintainers] [csw-buildfarm] gmake: warning: Clock skew detected. Your build may be incomplete. In-Reply-To: <4B047CB6.5050007@opencsw.org> References: <4B047CB6.5050007@opencsw.org> Message-ID: and the time on build9x is out by 1 hour (or the timezone is wrong, depending on your point of view) 2009/11/18 Sebastian Kayser : > I am working on build8x and build8s mostly and lately there seems to > be a time keeping issue. At least i am seeing lots of messages > like the following > > ... > gmake: Warning: File `work/solaris8-i386/cookies/global' has modification time 3.3 s in the future > ... > gmake: warning: ?Clock skew detected. ?Your build may be incomplete. > ... > > Looking at the systems, it seems as if the build.s are in sync, whereas > the build.x boxes have different notions of "the current time". Could > someone please have a look at it? > > Sebastian > _______________________________________________ > buildfarm mailing list > buildfarm at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/buildfarm > -- Gary Law Email: garylaw at garylaw.net Chat googletalk/messenger: gary.law at gmail.com iChat/jabber/AIM: gary.law at mac.com From schwindt at dfki.uni-kl.de Thu Nov 19 08:23:42 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Thu, 19 Nov 2009 08:23:42 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: Your message of "Wed, 18 Nov 2009 14:34:00 +0100." <728DE690-8397-4803-9B81-F029B5167CF6@opencsw.org> Message-ID: <200911190723.nAJ7NgYL012355@dfki.uni-kl.de> [...] > >> There's a user request to create symlinks from /usr/bin to > >> /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. > > > > I think it's not good. > > > > It will fail in a zone with global /usr. > > It is a purely optional package that depends on cups and its whole > purpose > is to replace the SysV-lp system. Nothing more. If you don't want the > system replaced you don't install this package. We may choose a slightly > modifed prefix like > CSWScups (CSW Solaris cups) > or something to mark that it doesn't install in /opt/csw but replaced > Solaris core functionality. Which I can do by adjusting the order of my PATH elements. Nothing belongs in /usr besides what SUN puts there. The zones are are an example where this fails, and also the fact that I've seen several customer mount /usr read only. Besides that, it is law - at least to me - that's why there is /opt. This is not linux ! Also I do not see cupsclient as purely optional. CSWcupslibs gets pulled in on behave of several packages. To be able to verify you setup one will need CSWcupsclient. The actual printing can be done with the onboard toolchain. Apart from that - what happens to /usr/bin/lpr, is it deleted ? Is SUNWpcu deinstalled ? Before making such modification one should think about making his on distribution rather than build packages for an existing one. Nicolai From maciej at opencsw.org Thu Nov 19 10:02:26 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 19 Nov 2009 09:02:26 +0000 Subject: [csw-maintainers] nspr in testing/ Message-ID: I've seen that William has done some work on the nspr library (netscape portable runtime). I know that Firefox needs it, so I'm not sure how is William currently compiling Firefox. I thought it would be good to have nspr as a separate library, in case someone wants to build a package with nspr as a dependency, such as Evolution, xulrunner, NSS (Mozilla's Network Security Services library), etc. I did some changes to the Makefile which was in the repository. I took out the --with-dist-prefix and --with-dist-bindir options. I assumed that William worked with only Firefox in mind, I want to have a regular system library. The library has been built with 32 and 64-bit support. It's currently in testing/. Maciej From maciej at opencsw.org Thu Nov 19 10:26:15 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 19 Nov 2009 09:26:15 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 1:10 PM, Dagobert Michelsen wrote: > You assume that using 64 bit is always better than using 32 bit. That's too strong a statement. Let's put it this way: I assume it's not significantly worse. But let's stop guessing and look at data. Do we have any numbers on it? What's the difference in memory footprint between 32 and 64-bit versions? > This > is not the case. If you need more than 2 GB of RAM or have large > databases you are right. Basically, if somebody's database is growing, we're making sure that it's already grown big when they realize they need to switch to the 64-bit version. > But if the database is not that big you are > better off using 32 bit. IMHO it is good to automatically make the > 32/64 bit decision under the following circumstances: > > (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 see that any of the above applies in the case of postgres. So why are we building everything else with isaexec? For instance, why do we want cups to be 64-bit enabled? Maciej From maciej at opencsw.org Thu Nov 19 10:30:31 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 19 Nov 2009 09:30:31 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 11:07 AM, Maciej (Matchek) Blizinski wrote: > On Wed, Nov 18, 2009 at 10:04 AM, Dagobert Michelsen wrote: >> Hi Maciej, >> >> Am 18.11.2009 um 10:55 schrieb Maciej (Matchek) Blizinski: >>> >>> It persists. ?Your example looks different from mine: You have >>> /opt/csw/postgresql/bin/initdb, I have >>> /opt/csw/bin/postgresql/8.4/initdb. The same thing happens with pkg/mysql5/branches/mysql-5.1.x-optcsw. It looks like GAR puts sparcv9 subdirectory always directly under bin/, ignoring any subdirectories under bin/. Maciej From bchill at opencsw.org Thu Nov 19 16:42:24 2009 From: bchill at opencsw.org (Brian Hill) Date: Thu, 19 Nov 2009 15:42:24 +0000 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin Message-ID: <20091119154224.GA28243@vm-1.bch.net> Nicolai Schwindt wrote: > [...] > >>>> There's a user request to create symlinks from /usr/bin to >>>> /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. >>>> >>> I think it's not good. >>> >>> It will fail in a zone with global /usr. >>> >> It is a purely optional package that depends on cups and its whole purpose >> is to replace the SysV-lp system. Nothing more. If you don't want the >> system replaced you don't install this package. We may choose a slightly >> modifed prefix like >> CSWScups (CSW Solaris cups) >> or something to mark that it doesn't install in /opt/csw but replaced >> Solaris core functionality. >> > > Which I can do by adjusting the order of my PATH elements. > Nothing belongs in /usr besides what SUN puts there. > The zones are are an example where this fails, and also the fact that I've seen several customer > mount /usr read only. > > Besides that, it is law - at least to me - that's why there is /opt. > This is not linux ! > Also I do not see cupsclient as purely optional. CSWcupslibs gets pulled in on behave of several > packages. To be able to verify you setup one will need CSWcupsclient. The actual printing can > be done with the onboard toolchain. > > Apart from that - what happens to /usr/bin/lpr, is it deleted ? Is SUNWpcu deinstalled ? > > Before making such modification one should think about making his on distribution rather than > build packages for an existing one. > > > Nicolai Hi Nicolai, Solaris does not exist in its a vacuum. :-) As a system manager, I want to deploy as few OS-specific solutions as possible; that is, I don't want to defer to FHS (File Hierarchy Standard) on Linux systems, which most 3rd-party Linux rpms follow to install files, but then have to modify /etc/default/login and other files on Sun systems, and /opt/local or /sw on Macs in some other file, if that's even possible on Macs (still looking into how Darwin handles a global PATH). Remote execution (ssh, rsh) and cron are additional examples of how trying to add to a PATH globally becomes difficult. And that Solaris 10 has the issue of zones affecting /usr isn't persuasive enough. To address this, I have made /usr/local on my systems strictly a symbolic link tree, with symbolic links pointing all over the place, which has helped a lot, but it's really not a substitute /usr/bin. The sysadmin is the user in the 'user experience' that CSW works for. We could argue forever about the direction that the PATH vs. /usr/bin debate is headed in the broader UNIX world, but CSW could offer at least one other avenue, especially if someone is CSW land is willing to offer that flexibility to deal with this. No solution will tip-toe with complete success around an installed OS. CSW already does it in /etc/rc* and /etc/init.d (I have to move CSW's init files out of the way after installing CSW's tools because I use my own init file method). Creating /usr/bin symbolic links in optional pkgs is as reasonable as modifying /etc/default/login, /detc/default/su and/or /etc/profile & /etc/csh.login. That a filesystem 'namespace' clash can happen somewhere in user land is a guarantee, but not all sysadmin's should be held hostage in the effort to avoid that clash. My 2 cents. Brian From korpela at opencsw.org Thu Nov 19 17:57:09 2009 From: korpela at opencsw.org (Eric J Korpela) Date: Thu, 19 Nov 2009 08:57:09 -0800 Subject: [csw-maintainers] Fwd: wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: <83CED7D4-8FCB-4D9D-965F-4D8975BEEF6D@opencsw.org> Message-ID: ---------- Forwarded message ---------- From: Eric J Korpela Date: Thu, Nov 19, 2009 at 8:56 AM Subject: Re: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) To: List for OpenCSW maintainers 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. Eric On Tue, Nov 17, 2009 at 8:45 AM, Dagobert Michelsen wrote: > Hi Erik, > > Am 16.11.2009 um 22:19 schrieb Eric J Korpela: >> >> I'll try to build boincmanager against the new libraries some time this >> week > > Cool. Let me know if you need additional machines or installs on build*t as > the > updated wxwidgets library will only be installed on build*s/x after release > and > there is still an unresolved issue. > > > Best regards > > ?-- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > From phil at bolthole.com Thu Nov 19 18:31:38 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 19 Nov 2009 09:31:38 -0800 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> Message-ID: On Thu, Nov 19, 2009 at 1:26 AM, Maciej (Matchek) Blizinski wrote: > > > So why are we building everything else with isaexec? we dont build "everything else" with isaexec. there is no 64bit "grep" for example. > ?For instance, > why do we want cups to be 64-bit enabled? there is a difference between "enabled[/available]", and "default to using it". hopefully, we havent bothered making 64bit executables for cups. but we need 64bit versions of the libraries AVAILABLE, so that some applications that want cups support, can be compiled in 64bit mode, if beneficial. obvious candidate: GIMP. From phil at bolthole.com Thu Nov 19 18:34:07 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 19 Nov 2009 09:34:07 -0800 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: <20091119154224.GA28243@vm-1.bch.net> References: <20091119154224.GA28243@vm-1.bch.net> Message-ID: On Thu, Nov 19, 2009 at 7:42 AM, Brian Hill wrote: > > Creating /usr/bin symbolic links in optional pkgs is as reasonable as > modifying /etc/default/login, /detc/default/su and/or /etc/profile & > /etc/csh.login. i would have to disagree there. those files, are /etc files. they are meant to be modified. From phil at bolthole.com Thu Nov 19 21:43:33 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 19 Nov 2009 12:43:33 -0800 Subject: [csw-maintainers] f-spot, anyone? Message-ID: Sooo.. anyone feel like packaging "f-spot"? It's a light(er)-weight photo cropping/tweaking tool. http://f-spot.org/Features From bwalton at opencsw.org Thu Nov 19 21:57:15 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 19 Nov 2009 15:57:15 -0500 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: References: Message-ID: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Nov 19 15:43:33 -0500 2009: > It's a light(er)-weight photo cropping/tweaking tool. ...that requires the mono runtime. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Thu Nov 19 22:05:47 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 19 Nov 2009 13:05:47 -0800 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Nov 19, 2009 at 12:57 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Nov 19 15:43:33 -0500 2009: >> It's a light(er)-weight photo cropping/tweaking tool. > > ...that requires the mono runtime. > so much for light.. Euuuuu.... From phil at bolthole.com Thu Nov 19 22:16:35 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 19 Nov 2009 13:16:35 -0800 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Nov 19, 2009 at 1:05 PM, Philip Brown wrote: > On Thu, Nov 19, 2009 at 12:57 PM, Ben Walton wrote: >> Excerpts from Philip Brown's message of Thu Nov 19 15:43:33 -0500 2009: >>> It's a light(er)-weight photo cropping/tweaking tool. >> >> ...that requires the mono runtime. >> > > so much for light.. Euuuuu.... > A pure java based one might be interesting. http://www.jhlabs.com/ie/index.html "Java Image Editor" Looks pretty. java kinda makes it non-light. but at least it has minimal (zero) other dependancies ;-) From william at wbonnet.net Thu Nov 19 23:50:55 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 19 Nov 2009 23:50:55 +0100 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> Message-ID: <4B05CBCF.4050106@wbonnet.net> Hi > A pure java based one might be interesting. > > http://www.jhlabs.com/ie/index.html > > "Java Image Editor" > > Looks pretty. > done :) Package is ready, but license is unclear on the web site. I mailed the author for more information about the license and authorization to distribute it. I have found information about the use of the APL 2.0 license, but it is not clear if it applies to every software on the web site, or only to filters sources. I suggest that i commit to GAR and put package in testing only when the author will have answered me... I would be surprised if redistribution was not authorized, but i prefer to wait for. Any thoughts ? cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From bwalton at opencsw.org Fri Nov 20 04:00:40 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 19 Nov 2009 22:00:40 -0500 Subject: [csw-maintainers] /testing cfengine, cvsproxy, diffuse, oinkmaster, perl, snort In-Reply-To: <625385e30911180700l21c7472y67b655c7ff195249@mail.gmail.com> References: <625385e30911170911o7e76ae6bme982ec90ccd7fdc8@mail.gmail.com> <20091117205453.GA9219@vm-1.bch.net> <625385e30911180700l21c7472y67b655c7ff195249@mail.gmail.com> Message-ID: <1258686013-sup-6695@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Wed Nov 18 10:00:35 -0500 2009: Hi Peter, > Thanks a lot for that report, I've been running that perl package for > a while myself but I can't test cfengine right now. I updated cfengine on my primary server here and it looks ok to me so far. 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 Fri Nov 20 14:42:43 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 20 Nov 2009 08:42:43 -0500 Subject: [csw-maintainers] gnulinks Message-ID: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> Hi All, A user queried me today about the current setup of CSWgnulinks. He wondered why gnulinks didn't depend on all of the gnu *utils packages for which it provides links to. Part of the answer is that I simply updated the existing package and left it functionally equivalent to the previous version. I'd also be hesitant to make it so heavy weight. I wonder though, and I realize there is a pile of work involved, whether a better solution would be to have each package that uses the g prefix on binaries provide its own links in /opt/csw/gnu? This would provide a solution without extra dependencies and prevent broken symlink possibilities in /opt/csw/gnu without being an overly heavy solution (packaging work aside). Thoughts? -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 Nov 20 14:47:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 14:47:45 +0100 Subject: [csw-maintainers] gnulinks In-Reply-To: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> Message-ID: <3FD6CA1C-1808-4820-A8A5-2998E95C097C@opencsw.org> Hi Ben, Am 20.11.2009 um 14:42 schrieb Ben Walton: > A user queried me today about the current setup of CSWgnulinks. He > wondered why gnulinks didn't depend on all of the gnu *utils packages > for which it provides links to. > > Part of the answer is that I simply updated the existing package and > left it functionally equivalent to the previous version. I'd also be > hesitant to make it so heavy weight. > > I wonder though, and I realize there is a pile of work involved, > whether a better solution would be to have each package that uses the > g prefix on binaries provide its own links in /opt/csw/gnu? This > would provide a solution without extra dependencies and prevent broken > symlink possibilities in /opt/csw/gnu without being an overly heavy > solution (packaging work aside). Sounds like a good solution to me. In addition to that adding the links is not that complicated. Best regards -- Dago From dam at opencsw.org Fri Nov 20 15:22:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 15:22:49 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: <4D11E69F-0C02-4F3A-BFED-1A9268EEF8B5@opencsw.org> Hi Maciej, Am 18.11.2009 um 18:57 schrieb Maciej (Matchek) Blizinski: > On Wed, Nov 18, 2009 at 5:21 PM, Dagobert Michelsen > wrote: >> is cleanly separated from the CSW-only packages. If the "-ln" >> suffix is consistent may be discussed, in the current naming >> scheme "CSWcupslinks" would IMHO be better, but that is another >> thing. > > I couldn't decide which was better. I had the following ideas: > > CSWcupsln > CSWcupslinks > CSWcupslpdcompat > CSWcupsusrbin > CSWcups-ln > CSWcups-links > CSWcups-lpdcompat > CSWcups-usrbin > CSWcupsclientln > CSWcupsclientlinks > CSWcupsclientlpdcompat > CSWcupsclientusrbin > CSWcupsclient-ln > CSWcupsclient-links > CSWcupsclient-lpdcompat > CSWcupsclient-usrbin > > Which one do you like best? Maybe we should choose a different prefix that makes it clear that we replace a Solaris system with it. Maybe something like CSWXcupsclient which then depends on CSWcupsclient Best regards -- Dago From dam at opencsw.org Fri Nov 20 15:23:29 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 15:23:29 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: <927C1D38-948D-4830-A8C4-DB8AA20FBEDE@opencsw.org> Hi Phil, Am 18.11.2009 um 19:11 schrieb Philip Brown: > On Wed, Nov 18, 2009 at 9:21 AM, Dagobert Michelsen > wrote: >> >> I prefer the way Maciej has done it: with a separete package per >> software (Cups in this case), marked incompatible to the Solaris >> packages it replaces. > > eu, ick. I didnt notice that "feature". > > I dont think we have any business conflicting with packages that > arent "ours". If the package has files that conflict with an existing Solaris package we should conflict with it. Bets regrads -- Dago From dam at opencsw.org Fri Nov 20 15:24:33 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 15:24:33 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: Hi Phil, Am 18.11.2009 um 19:16 schrieb Philip Brown: > On Wed, Nov 18, 2009 at 10:11 AM, Philip Brown > wrote: >> >> ... >> I dont think we have any business conflicting with packages that >> arent "ours". > > Let me give just one explicit example of why: > > "pkg-get install all" I can't imagine a single use of this. Why would anybody would want all packages? There is so much special stuff in the catalog that I simply cannot imagine that anybody would actually want to install everything. Best regards -- Dago From dam at opencsw.org Fri Nov 20 15:51:50 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 15:51:50 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: <200911190723.nAJ7NgYL012355@dfki.uni-kl.de> References: <200911190723.nAJ7NgYL012355@dfki.uni-kl.de> Message-ID: Hi Nicolai, Am 19.11.2009 um 08:23 schrieb Nicolai Schwindt: > [...] >>>> There's a user request to create symlinks from /usr/bin to >>>> /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. >>> >>> I think it's not good. >>> >>> It will fail in a zone with global /usr. >> >> It is a purely optional package that depends on cups and its whole >> purpose >> is to replace the SysV-lp system. Nothing more. If you don't want the >> system replaced you don't install this package. We may choose a >> slightly >> modifed prefix like >> CSWScups (CSW Solaris cups) >> or something to mark that it doesn't install in /opt/csw but replaced >> Solaris core functionality. > > Which I can do by adjusting the order of my PATH elements. > Nothing belongs in /usr besides what SUN puts there. The problem start when you have binaries that explicitly call /usr/bin/ lp which are distributed as binaries and you want CSW CUPS as print system. > The zones are are an example where this fails, and also the fact > that I've > seen several customer > mount /usr read only. > > Besides that, it is law - at least to me - that's why there is /opt. > This is not linux ! > > Also I do not see cupsclient as purely optional. CSWcupslibs gets > pulled in on > behave of several > packages. To be able to verify you setup one will need > CSWcupsclient. The > actual printing can > be done with the onboard toolchain. The idea is to have an ADDITIONAL package which depends on the cups client package, provides the links from the original Sun lp-system to /opt/csw/ and be incompatible with the existing print packages. > Apart from that - what happens to /usr/bin/lpr, is it deleted ? Is > SUNWpcu > deinstalled ? You must deinstall the Solaris packages first, than add the link package. > Before making such modification one should think about making his on > distribution rather than > build packages for an existing one. The idea is to have a supported system and replace the outdated parts with usable replacements. This would be cups here. So again: This is meant as an add-on. Optional. Which you may or may not install and install only if you want to replace the original print system. If you don't want to replace the original print system you install the other cups packages, but not this one. Best regards -- Dago From dam at opencsw.org Fri Nov 20 15:56:41 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 15:56:41 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> Message-ID: <7B5B1DC6-D0C9-49A2-8AC8-3877C3DB9B83@opencsw.org> Hi Maciej, Am 19.11.2009 um 10:26 schrieb Maciej (Matchek) Blizinski: > On Wed, Nov 18, 2009 at 1:10 PM, Dagobert Michelsen > wrote: >> You assume that using 64 bit is always better than using 32 bit. > > That's too strong a statement. Let's put it this way: I assume it's > not significantly worse. But let's stop guessing and look at data. > Do we have any numbers on it? What's the difference in memory > footprint between 32 and 64-bit versions? > >> This >> is not the case. If you need more than 2 GB of RAM or have large >> databases you are right. > > Basically, if somebody's database is growing, we're making sure that > it's already grown big when they realize they need to switch to the > 64-bit version. The biggest concern for me is that the decision if 32 or 64 bit is used is triggered from the state of the calling OS. That means if the outer conditions from the OS change the database will change. I admit that this will most of the time not make problems, but I don't like the idea that moving to another host invalidates my db structure. Defining 32/64 statically on installation and even defaulting to 64 bit would IMHO be much better than isaexec here. >> But if the database is not that big you are >> better off using 32 bit. IMHO it is good to automatically make the >> 32/64 bit decision under the following circumstances: >> >> (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 see that any of the above applies in the case of postgres. > > So why are we building everything else with isaexec? For instance, > why do we want cups to be 64-bit enabled? We don't. As Phil explained, the libs should be available in 64 bit everytime to allow compiling apps in 64 bit that need the libraries. There is no need for an isaexec 64 bit print system. Best regards -- Dago From dam at opencsw.org Fri Nov 20 16:06:15 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 16:06:15 +0100 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: <4B05CBCF.4050106@wbonnet.net> References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> <4B05CBCF.4050106@wbonnet.net> Message-ID: <74232416-CCBA-4C8C-B925-44F1FD55C009@opencsw.org> Hi William, Am 19.11.2009 um 23:50 schrieb William Bonnet: > Hi >> A pure java based one might be interesting. >> >> http://www.jhlabs.com/ie/index.html >> >> "Java Image Editor" >> >> Looks pretty. >> > done :) > > Package is ready, but license is unclear on the web site. I mailed > the author for more information about the license and authorization > to distribute it. I have found information about the use of the APL > 2.0 license, but it is not clear if it applies to every software on > the web site, or only to filters sources. > > I suggest that i commit to GAR and put package in testing only when > the author will have answered me... I would be surprised if > redistribution was not authorized, but i prefer to wait for. Any > thoughts ? Yes. Please commit the Makefile anyway. Even if the license prohibits binary distribution we may distribute the source package in the future. Best regards -- Dago From dam at opencsw.org Fri Nov 20 16:17:25 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 16:17:25 +0100 Subject: [csw-maintainers] New cswclassutils: cswcron, cswtexinfo, cswmigrateconf and GAR integration In-Reply-To: <4B046F0F.6060509@opencsw.org> References: <0691F15A-1BF5-4817-968F-449FC848E2D7@opencsw.org> <4B046F0F.6060509@opencsw.org> Message-ID: <8D0258D5-569F-4FD5-BB5E-1A1B72209D25@opencsw.org> Hi Sebastian, Am 18.11.2009 um 23:02 schrieb Sebastian Kayser: > Dagobert Michelsen wrote on 11.11.2009 15:58: >> as of r7226 and cswclassutils 1.28 there is support for three new >> classes: >> >> - cswcron allows modifying of the crontab >> - cswtexinfo allows automatic addition of .info files to the >> texinfo dir >> - cswmigrateconf allows easy migration of config files from /opt/ >> csw/etc >> to /etc/opt/csw >> >> The usage has been documented at >> > > i have been trying to leverage MIGRATE_FILES for axel, the > cswmigrateconf stays empty though. > > ... > sysconfdir = /etc/opt/csw > SAMPLECONF = $(sysconfdir)/axelrc > MIGRATE_FILES = axelrc > ... > > skayser @ build8x ~/mgar/pkg/axel/trunk$ cat work/solaris8-i386/ > pkgroot/etc/opt/csw/pkg/CSWaxel/cswmigrateconf > MIGRATE_FILES="" > > Build files are checked in, would you mind having a look? You are right. This rule-specific assignment in GNU Make is tricky. This is hopefully fixed in r7361. Best regards -- Dago From Darin.Perusich at cognigencorp.com Fri Nov 20 16:31:42 2009 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 20 Nov 2009 10:31:42 -0500 Subject: [csw-maintainers] cswclassutils cswinetdconf Message-ID: <4B06B65E.80008@cognigencorp.com> The documentation on the wiki needs to be updated regarding this particular class. The section on this class only relates to the term 'cswinetdconf' as the class, but the class to be executed is actually 'cswinetd'. Can someone please update the docs to reflect this? Otherwise packagers attempting to use this class, like me, are going wonder why inetd isn't properly updated. Can examples for the pkginfo and prototype files be added as well. Have these examples for all classes would be very helpful. Now onto the problem. After updating my pkginfo and prototypes accordingly the conversion of the inetd entry is failing with the following. Installing class ... /opt/csw/etc/pkg/CSWcheck_mk_agent/inetd.conf inetconv: Error opening /var/opt/csw/svc/manifest/network/check_mk-tcp.xml: No such file or directory pkgadd: ERROR: class action script did not complete successfully When I perform a verbose install I see the class is trying to install the manifest into /var/opt/csw/svc/manifest/network, a directory which doesn't exist! Shouldn't the class action script create this directory if it doesn't exist or fall back on /var/svc/manifest/network? -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From dam at opencsw.org Fri Nov 20 16:35:01 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 16:35:01 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: <988C113A-0FD5-4D91-B3DE-8174D2620B61@opencsw.org> Hi Maciej, Am 19.11.2009 um 10:30 schrieb Maciej (Matchek) Blizinski: > On Wed, Nov 18, 2009 at 11:07 AM, Maciej (Matchek) Blizinski > wrote: >> On Wed, Nov 18, 2009 at 10:04 AM, Dagobert Michelsen >> wrote: >>> Hi Maciej, >>> >>> Am 18.11.2009 um 10:55 schrieb Maciej (Matchek) Blizinski: >>>> >>>> It persists. Your example looks different from mine: You have >>>> /opt/csw/postgresql/bin/initdb, I have >>>> /opt/csw/bin/postgresql/8.4/initdb. > > The same thing happens with pkg/mysql5/branches/mysql-5.1.x-optcsw. > It looks like GAR puts sparcv9 subdirectory always directly under > bin/, ignoring any subdirectories under bin/. I just verified, the problem is there. You are relocating postgres inside each subdirectory: /opt/csw/bin/postgres/ /opt/csw/lib/postgres/ instead of confining the installation to /opt/csw/postgres/ as it is done for e. g. Berkeley DB. This is not a problem by itself, you must however use different variables if you finegrained tune install variables. $(bindir) for example is the directory where the binaries go. It is defined as bindir_install ?= $(exec_prefix)/bin bindir ?= $(abspath $(bindir_install)/$(MM_BINDIR)) That means bindir is used directly as option to configure and GAR expects it to be adjusted the way it thinks is good. If it is adjusted manually it can be done by using the corresponding bindir_install variable. The variables that are sensitive to this are bindir, sbindir, libexecdir and libdir I adjusted your Makefile to now work fully with ISA modulations as https://sourceforge.net/apps/trac/gar/changeset/7362 Best regards -- Dago From dam at opencsw.org Fri Nov 20 16:42:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 16:42:32 +0100 Subject: [csw-maintainers] cswclassutils cswinetdconf In-Reply-To: <4B06B65E.80008@cognigencorp.com> References: <4B06B65E.80008@cognigencorp.com> Message-ID: Hi Darin, Am 20.11.2009 um 16:31 schrieb Darin Perusich: > The documentation on the wiki needs to be updated regarding this > particular class. The section on this class only relates to the term > 'cswinetdconf' as the class, but the class to be executed is actually > 'cswinetd'. Can someone please update the docs to reflect this? Thanks for catching this, fixed. > Otherwise packagers attempting to use this class, like me, are going > wonder why inetd isn't properly updated. Can examples for the pkginfo > and prototype files be added as well. Have these examples for all > classes would be very helpful. > > Now onto the problem. After updating my pkginfo and prototypes > accordingly the conversion of the inetd entry is failing with the > following. > > Installing class ... > /opt/csw/etc/pkg/CSWcheck_mk_agent/inetd.conf > inetconv: Error opening > /var/opt/csw/svc/manifest/network/check_mk-tcp.xml: No such file or > directory > pkgadd: ERROR: class action script did not complete successfully > > When I perform a verbose install I see the class is trying to install > the manifest into /var/opt/csw/svc/manifest/network, a directory which > doesn't exist! Shouldn't the class action script create this directory > if it doesn't exist or fall back on /var/svc/manifest/network? That should be create, yes. Ben, would you mind adding it and ask Peter to release a new version? Best regards -- Dago From william at wbonnet.net Fri Nov 20 16:46:26 2009 From: william at wbonnet.net (William Bonnet) Date: Fri, 20 Nov 2009 16:46:26 +0100 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: <74232416-CCBA-4C8C-B925-44F1FD55C009@opencsw.org> References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> <4B05CBCF.4050106@wbonnet.net> <74232416-CCBA-4C8C-B925-44F1FD55C009@opencsw.org> Message-ID: <4B06B9D2.6080003@wbonnet.net> Hi >> I suggest that i commit to GAR and put package in testing only when >> the author will have answered me... I would be surprised if >> redistribution was not authorized, but i prefer to wait for. Any >> thoughts ? > > Yes. Please commit the Makefile anyway. Even if the license prohibits > binary distribution we may distribute the source package in the future. Actually i have no source, only a jar to redistribute. cheers W. From dam at opencsw.org Fri Nov 20 16:49:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 16:49:43 +0100 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: <4B06B9D2.6080003@wbonnet.net> References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> <4B05CBCF.4050106@wbonnet.net> <74232416-CCBA-4C8C-B925-44F1FD55C009@opencsw.org> <4B06B9D2.6080003@wbonnet.net> Message-ID: <956C2ABD-DAD3-4E8A-B0F0-F5CCB0B42DF6@opencsw.org> Hi William, Am 20.11.2009 um 16:46 schrieb William Bonnet: >>> I suggest that i commit to GAR and put package in testing only >>> when the author will have answered me... I would be surprised if >>> redistribution was not authorized, but i prefer to wait for. Any >>> thoughts ? >> >> Yes. Please commit the Makefile anyway. Even if the license prohibits >> binary distribution we may distribute the source package in the >> future. > Actually i have no source, only a jar to redistribute. Hugh? "I suggest that i commit to GAR", why not commit that? Best regards -- Dago From william at wbonnet.net Fri Nov 20 16:54:24 2009 From: william at wbonnet.net (William Bonnet) Date: Fri, 20 Nov 2009 16:54:24 +0100 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: <956C2ABD-DAD3-4E8A-B0F0-F5CCB0B42DF6@opencsw.org> References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> <4B05CBCF.4050106@wbonnet.net> <74232416-CCBA-4C8C-B925-44F1FD55C009@opencsw.org> <4B06B9D2.6080003@wbonnet.net> <956C2ABD-DAD3-4E8A-B0F0-F5CCB0B42DF6@opencsw.org> Message-ID: <4B06BBB0.3050703@wbonnet.net> Dagobert Michelsen a ?crit : > Hi William, > > Am 20.11.2009 um 16:46 schrieb William Bonnet: >>>> I suggest that i commit to GAR and put package in testing only when >>>> the author will have answered me... I would be surprised if >>>> redistribution was not authorized, but i prefer to wait for. Any >>>> thoughts ? >>> >>> Yes. Please commit the Makefile anyway. Even if the license prohibits >>> binary distribution we may distribute the source package in the future. >> Actually i have no source, only a jar to redistribute. > > Hugh? "I suggest that i commit to GAR", why not commit that? > Yes no problem :) What i meant is that actually i cannot produce a source package unless i "source" the jar file. I see no real problem to distribute a way to make people create the package by themselves. I'll do it when i'll be home. cheers W. From dam at opencsw.org Fri Nov 20 16:56:29 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 16:56:29 +0100 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: <4B06BBB0.3050703@wbonnet.net> References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> <4B05CBCF.4050106@wbonnet.net> <74232416-CCBA-4C8C-B925-44F1FD55C009@opencsw.org> <4B06B9D2.6080003@wbonnet.net> <956C2ABD-DAD3-4E8A-B0F0-F5CCB0B42DF6@opencsw.org> <4B06BBB0.3050703@wbonnet.net> Message-ID: <0D76C9F6-5400-44AC-8743-0DD1964682A2@opencsw.org> Hi William, Am 20.11.2009 um 16:54 schrieb William Bonnet: > Dagobert Michelsen a ?crit : >> Hi William, >> >> Am 20.11.2009 um 16:46 schrieb William Bonnet: >>>>> I suggest that i commit to GAR and put package in testing only >>>>> when the author will have answered me... I would be surprised if >>>>> redistribution was not authorized, but i prefer to wait for. Any >>>>> thoughts ? >>>> >>>> Yes. Please commit the Makefile anyway. Even if the license >>>> prohibits >>>> binary distribution we may distribute the source package in the >>>> future. >>> Actually i have no source, only a jar to redistribute. >> >> Hugh? "I suggest that i commit to GAR", why not commit that? >> > > Yes no problem :) > > What i meant is that actually i cannot produce a source package > unless i "source" the jar file. I see no real problem to distribute > a way to make people create the package by themselves. > > I'll do it when i'll be home. The idea is to provide a manual download location and let the user fill $GARCHIVEDIR. You can see https://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/jdk6/trunk/Makefile for an example of how it could be done. Best regards -- Dago From Darin.Perusich at cognigencorp.com Fri Nov 20 17:07:45 2009 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 20 Nov 2009 11:07:45 -0500 Subject: [csw-maintainers] not displaying the license during install Message-ID: <4B06BED1.6040206@cognigencorp.com> What is the procedure for this and is it documented anywhere? -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From bwalton at opencsw.org Fri Nov 20 17:12:51 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 20 Nov 2009 11:12:51 -0500 Subject: [csw-maintainers] cswclassutils cswinetdconf In-Reply-To: References: <4B06B65E.80008@cognigencorp.com> Message-ID: <1258733431-sup-8799@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Nov 20 10:42:32 -0500 2009: Hi Darin, Dago, > > When I perform a verbose install I see the class is trying to install > > the manifest into /var/opt/csw/svc/manifest/network, a directory which > > doesn't exist! Shouldn't the class action script create this directory > > if it doesn't exist or fall back on /var/svc/manifest/network? > > That should be create, yes. Ben, would you mind adding it and ask > Peter to release a new version? Yes, I'll certainly fix that. It's not something I encountered though...I wonder if I created that directory manually on my test boxes? I didn't encounter issues adding the updated CSWgitosis on mirror.opencsw.org, either, which implies that directory existed. I'll compare cswinetd with svc/init script to see if it's creating that directory too and harmonize things. 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 Nov 20 17:37:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 17:37:28 +0100 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: <4B06BED1.6040206@cognigencorp.com> References: <4B06BED1.6040206@cognigencorp.com> Message-ID: Hi Darin, Am 20.11.2009 um 17:07 schrieb Darin Perusich: > not displaying the license during install > What is the procedure for this and is it documented anywhere? The notice displayed on install is in the package at install/copyright The real license should be in /opt/csw/share/doc//license Best regards -- Dago From dam at opencsw.org Fri Nov 20 17:43:06 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 17:43:06 +0100 Subject: [csw-maintainers] [csw-buildfarm] gmake: warning: Clock skew detected. Your build may be incomplete. In-Reply-To: References: <4B047CB6.5050007@opencsw.org> Message-ID: <479BDAAC-3A9D-44E9-BEC4-46E5C73237EE@opencsw.org> Hi, Am 19.11.2009 um 00:26 schrieb Gary Law: > 2009/11/18 Sebastian Kayser : >> I am working on build8x and build8s mostly and lately there seems to >> be a time keeping issue. At least i am seeing lots of messages >> like the following >> >> ... >> gmake: Warning: File `work/solaris8-i386/cookies/global' has >> modification time 3.3 s in the future >> ... >> gmake: warning: Clock skew detected. Your build may be incomplete. >> ... >> >> Looking at the systems, it seems as if the build.s are in sync, >> whereas >> the build.x boxes have different notions of "the current time". Could >> someone please have a look at it? > > and the time on build9x is out by 1 hour (or the timezone is wrong, > depending on your point of view) All NTP issues should be fixed. A network was disconnected from the global zone which was unused. Well, not really unused as only NTP was synchronized from there... Best regards -- Dago From james at opencsw.org Fri Nov 20 17:45:03 2009 From: james at opencsw.org (James Lee) Date: Fri, 20 Nov 2009 16:45:03 GMT Subject: [csw-maintainers] not displaying the license during install In-Reply-To: <4B06BED1.6040206@cognigencorp.com> References: <4B06BED1.6040206@cognigencorp.com> Message-ID: <20091120.16450300.3887259882@gyor.oxdrove.co.uk> On 20/11/09, 16:07:45, Darin Perusich wrote regarding [csw-maintainers] not displaying the license during install: > What is the procedure for this # pkgadd -S ... > and is it documented anywhere? It's not in the man page. James. From dam at opencsw.org Fri Nov 20 17:59:12 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 17:59:12 +0100 Subject: [csw-maintainers] Mike Watters going sabbatical Message-ID: <281EC0A2-937C-4649-8CF0-7DC95F3F1488@opencsw.org> Hi, due to high workload Mike Watters is taking a sabbatical. There are some bugs reported on his packages: http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mwatters As all of them are in GAR it should be fairly easy to fix them. Important packages are subversion, gcc4, sudo, python, squid. If anybody is interested in adopting some this would be really great. Best regards -- Dago From dam at opencsw.org Fri Nov 20 18:04:15 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 18:04:15 +0100 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: <20091120.16450300.3887259882@gyor.oxdrove.co.uk> References: <4B06BED1.6040206@cognigencorp.com> <20091120.16450300.3887259882@gyor.oxdrove.co.uk> Message-ID: <14D0FF44-B460-4D02-B0B3-63313B6A7C33@opencsw.org> Hi, Am 20.11.2009 um 17:45 schrieb James Lee: > On 20/11/09, 16:07:45, Darin Perusich > > wrote regarding [csw-maintainers] not displaying the license during > install: > >> What is the procedure for this > > # pkgadd -S ... > >> and is it documented anywhere? > > It's not in the man page. How come every time you write an email I learn something? ;-) However, it is documented in the source: Best regards -- Dago From phil at bolthole.com Fri Nov 20 18:04:48 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 09:04:48 -0800 Subject: [csw-maintainers] gnulinks In-Reply-To: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 20, 2009 at 5:42 AM, Ben Walton wrote: > > Hi All, > > A user queried me today about the current setup of CSWgnulinks. ?He > wondered why gnulinks didn't depend on all of the gnu *utils packages > for which it provides links to. > maybe because that's a LOT of packages, and may be not everyone WANTS to have all those packages automagically pulled in? From phil at bolthole.com Fri Nov 20 18:10:04 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 09:10:04 -0800 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: On Fri, Nov 20, 2009 at 6:24 AM, Dagobert Michelsen wrote: > Hi Phil, > > Am 18.11.2009 um 19:16 schrieb Philip Brown: >> >>> I dont think we have any business conflicting with packages that arent >>> "ours". >> >> Let me give just one explicit example of why: >> >> "pkg-get install all" > > I can't imagine a single use of this. Why would anybody would want all > packages? > There is so much special stuff in the catalog that I simply cannot imagine > that > anybody would actually want to install everything. That's kind of like saying, "I cant imagine anyone would do a 'full install' in solaris. there's so many packages in there, no-one will want to actually use everything". :-P People DO install everything. Because it's easier/quicker than wading through everything deciding, "Hmm, install this yes or no?" From dam at opencsw.org Fri Nov 20 18:10:36 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 18:10:36 +0100 Subject: [csw-maintainers] gnulinks In-Reply-To: References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> Message-ID: <4842F4C8-F165-4908-BD47-F37B3C6CCE87@opencsw.org> Hi Phil, Am 20.11.2009 um 18:04 schrieb Philip Brown: > On Fri, Nov 20, 2009 at 5:42 AM, Ben Walton > wrote: >> A user queried me today about the current setup of CSWgnulinks. He >> wondered why gnulinks didn't depend on all of the gnu *utils packages >> for which it provides links to. > > maybe because that's a LOT of packages, and may be not everyone WANTS > to have all those packages automagically pulled in? Understood. But wouldn't it be good if each package would provide his own gnulinks? Best regards -- Dago From Darin.Perusich at cognigencorp.com Fri Nov 20 18:12:36 2009 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 20 Nov 2009 12:12:36 -0500 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: References: <4B06BED1.6040206@cognigencorp.com> Message-ID: <4B06CE04.2060408@cognigencorp.com> Dagobert Michelsen wrote: > Hi Darin, > > Am 20.11.2009 um 17:07 schrieb Darin Perusich: >> not displaying the license during install >> What is the procedure for this and is it documented anywhere? > > The notice displayed on install is in the package at > install/copyright > The real license should be in > /opt/csw/share/doc//license > Yes, but when you use 'createpkg' and the prototype doesn't contain 'i copyright' it exists and tells you to add it. I'm going to assume people getting around this by including 'i copyright' in their prototypes which has a blurp about where to see the full license or bypassing 'createpkg' all together. I don't have a problem using either of these methods, I'm simply looking for a little guidance on what might be considered the best practice for accomplishing this. -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From phil at bolthole.com Fri Nov 20 18:21:22 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 09:21:22 -0800 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: <4B06CE04.2060408@cognigencorp.com> References: <4B06BED1.6040206@cognigencorp.com> <4B06CE04.2060408@cognigencorp.com> Message-ID: On Fri, Nov 20, 2009 at 9:12 AM, Darin Perusich wrote: > > > Yes, but when you use 'createpkg' and the prototype doesn't contain 'i > copyright' it exists and tells you to add it. I'm going to assume people > getting around this by including 'i copyright' in their prototypes which > has a blurp about where to see the full license... yes exactly. It's not a "getting around this" thing, it's a "what you're expected to do" sort of thing. Sorry if it isnt documented well. GAR automatically puts in a stub "here's where the copyright is" thing automagically, btw. From phil at bolthole.com Fri Nov 20 18:22:23 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 09:22:23 -0800 Subject: [csw-maintainers] Mike Watters going sabbatical In-Reply-To: <281EC0A2-937C-4649-8CF0-7DC95F3F1488@opencsw.org> References: <281EC0A2-937C-4649-8CF0-7DC95F3F1488@opencsw.org> Message-ID: On Fri, Nov 20, 2009 at 8:59 AM, Dagobert Michelsen wrote: > Hi, > > due to high workload Mike Watters is taking a sabbatical. > There are some bugs reported on his packages: > ?http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mwatters > As all of them are in GAR it should be fairly easy to fix them. > Important packages are subversion, gcc4, sudo, python, squid. > If anybody is interested in adopting some this would be really > great. > > FYI, Maciej is already working on a sudo update. From phil at bolthole.com Fri Nov 20 18:25:44 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 09:25:44 -0800 Subject: [csw-maintainers] gnulinks In-Reply-To: <4842F4C8-F165-4908-BD47-F37B3C6CCE87@opencsw.org> References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> <4842F4C8-F165-4908-BD47-F37B3C6CCE87@opencsw.org> Message-ID: On Fri, Nov 20, 2009 at 9:10 AM, Dagobert Michelsen wrote: > Hi Phil, *wave* >> maybe because that's a LOT of packages, and may be not everyone WANTS >> to have all those packages automagically pulled in? > > Understood. But wouldn't it be good if each package would provide his > own gnulinks? That's another interesting alternative. From bwalton at opencsw.org Fri Nov 20 18:28:20 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 20 Nov 2009 12:28:20 -0500 Subject: [csw-maintainers] gnulinks In-Reply-To: References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> Message-ID: <1258738007-sup-8273@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Nov 20 12:04:48 -0500 2009: > maybe because that's a LOT of packages, and may be not everyone WANTS > to have all those packages automagically pulled in? I agree with this, in principle. In practice though, the decision to not depends on everything pointed is suboptimal. Personally, I'm leaning toward the 'provide your own gnulinks' approach. If coreutils can be built (and pass tests), I'll be add links appropriately in that package...to get the ball rolling. -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 bonivart at opencsw.org Fri Nov 20 18:44:50 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 20 Nov 2009 18:44:50 +0100 Subject: [csw-maintainers] cswclassutils cswinetdconf In-Reply-To: <1258733431-sup-8799@ntdws12.chass.utoronto.ca> References: <4B06B65E.80008@cognigencorp.com> <1258733431-sup-8799@ntdws12.chass.utoronto.ca> Message-ID: <625385e30911200944rf45927clb1a5a27f320860f2@mail.gmail.com> On Fri, Nov 20, 2009 at 5:12 PM, Ben Walton wrote: > Yes, I'll certainly fix that. ?It's not something I encountered > though...I wonder if I created that directory manually on my test > boxes? ?I didn't encounter issues adding the updated CSWgitosis on > mirror.opencsw.org, either, which implies that directory existed. Cswclassutils creates /var/opt/csw/svc/manifest and maybe on your system you had a package installed using the network path because it gets created by cswinitsmf if needed. As you always use network you could just do something like this: [ ! -d $outdir ] && mkdir $outdir -- /peter From bchill at opencsw.org Fri Nov 20 19:40:05 2009 From: bchill at opencsw.org (Brian Hill) Date: Fri, 20 Nov 2009 18:40:05 +0000 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: <20091120184005.GA20699@vm-1.bch.net> On Fri, Nov 20, 2009 at 09:10:04AM -0800, Philip Brown wrote: > On Fri, Nov 20, 2009 at 6:24 AM, Dagobert Michelsen wrote: > > Hi Phil, > > > > Am 18.11.2009 um 19:16 schrieb Philip Brown: > >> > >>> I dont think we have any business conflicting with packages that arent > >>> "ours". > >> > >> Let me give just one explicit example of why: > >> > >> "pkg-get install all" > > > > I can't imagine a single use of this. Why would anybody would want all > > packages? > > There is so much special stuff in the catalog that I simply cannot imagine > > that > > anybody would actually want to install everything. > > > That's kind of like saying, "I cant imagine anyone would do a 'full > install' in solaris. there's so many packages in there, no-one will > want to actually use everything". > > > :-P > > > People DO install everything. > Because it's easier/quicker than wading through everything deciding, > "Hmm, install this yes or no?" I completely agree. When I do OS installs, I install everything. The time spent micro-deciding before system installs on what's-going-to-be-installed-where across potentially hundreds or thousands of systems is time totally wasted. It confuses users and sysadmins alike, and causes productivity interuptions when a tool or service is then suddenly needed on a system where it was thought it would not be needed. I haven't installed all of the CSW tools yet, but as soon as I find I need one, I install it on all Suns for consistency. I might install it all at some point. I also don't think there is a problem with dangling symlinks. My /usr/local tree has links that dangle depending on the OS - it's never been a problem. In short, indeed, some people either do install everything or are very likely to install everything. :-) Brian From phil at bolthole.com Fri Nov 20 20:12:02 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 11:12:02 -0800 Subject: [csw-maintainers] gnulinks In-Reply-To: <1258738007-sup-8273@ntdws12.chass.utoronto.ca> References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> <1258738007-sup-8273@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 20, 2009 at 9:28 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Nov 20 12:04:48 -0500 2009: > >> maybe because that's a LOT of packages, and may be not everyone WANTS >> to have all those packages automagically pulled in? > > I agree with this, in principle. ?In practice though, the decision to > not depends on everything pointed is suboptimal. ?Personally, I'm > leaning toward the 'provide your own gnulinks' approach. > > If coreutils can be built (and pass tests), I'll be add links > appropriately in that package...to get the ball rolling. > coreutils is kinda a sore spot. It should be an easy build, in and of itself. However, no-one so far who has mentioned it, has been willing to do the work to "nicely" transition us to it. The issue is that coreutils is a conglomerate of previously separate utils. So if you're going to replace them, you need to handle the dependancies from packages that depend on those. (Another issue, is that coreutils is a lot bigger, and it's kinda annoying to download the whole bloatware lot, if you only want one of the original pieces of it. But that's just a side issue thats kinda optional; the main issue is handling the transition smoothly) From bwalton at opencsw.org Fri Nov 20 20:21:25 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 20 Nov 2009 14:21:25 -0500 Subject: [csw-maintainers] gnulinks In-Reply-To: References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> <1258738007-sup-8273@ntdws12.chass.utoronto.ca> Message-ID: <1258744738-sup-8496@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Nov 20 14:12:02 -0500 2009: > coreutils is kinda a sore spot. It should be an easy build, in and > of itself. However, no-one so far who has mentioned it, has been > willing to do the work to "nicely" transition us to it. I'm willing to do the work and will add it to my task list. I miss 'readlink'[1] which wasn't included in the old separate packages. > (Another issue, is that coreutils is a lot bigger, and it's kinda > annoying to download the whole bloatware lot, if you only want one > of the original pieces of it. But that's just a side issue thats > kinda optional; the main issue is handling the transition smoothly) The transition shouldn't be _that_ difficult, should it? It would simply be a matter of marking itself I with CSWgfile, CSWshutils, etc, right? Given that it's a superset of those packages... -Ben [1] Apparently a few script-ish apps also miss this too. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Nov 20 20:25:02 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 11:25:02 -0800 Subject: [csw-maintainers] gnulinks In-Reply-To: <1258744738-sup-8496@ntdws12.chass.utoronto.ca> References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> <1258738007-sup-8273@ntdws12.chass.utoronto.ca> <1258744738-sup-8496@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 20, 2009 at 11:21 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Nov 20 14:12:02 -0500 2009: > >> coreutils is kinda a sore spot. It should be an easy build, in and >> of itself. ?However, no-one so far who has mentioned it, has been >> willing to do the work to "nicely" transition us to it. >.... > > The transition shouldn't be _that_ difficult, should it? ?It would > simply be a matter of marking itself I with CSWgfile, CSWshutils, etc, > right? ?Given that it's a superset of those packages... > that would be fine, if nothing depended on those packages. But... things DO depend on those packages. for example, one of them that you named, CSWshutils, has 3 packages depending on it. From bwalton at opencsw.org Fri Nov 20 20:29:33 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 20 Nov 2009 14:29:33 -0500 Subject: [csw-maintainers] gnulinks In-Reply-To: References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> <1258738007-sup-8273@ntdws12.chass.utoronto.ca> <1258744738-sup-8496@ntdws12.chass.utoronto.ca> Message-ID: <1258745329-sup-4788@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Nov 20 14:25:02 -0500 2009: > that would be fine, if nothing depended on those packages. > But... things DO depend on those packages. *face*palm*...of course. > for example, one of them that you named, CSWshutils, has 3 packages > depending on it. Ok, bigger job, but the payoff is worthwhile. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Fri Nov 20 20:43:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 20 Nov 2009 19:43:54 +0000 Subject: [csw-maintainers] Mike Watters going sabbatical In-Reply-To: References: <281EC0A2-937C-4649-8CF0-7DC95F3F1488@opencsw.org> Message-ID: On Fri, Nov 20, 2009 at 5:22 PM, Philip Brown wrote: > FYI, Maciej is already working on a sudo update. Yes, I am. I also have filed a bug against Python (deprecate the CSWpython-rt package) which is easy enough to do. There's a number of very significant packages that Mike has been maintaining. I think it's a very good thing that it's easy to continue Mike's work, and I might be building new versions of some if his packages. However, I'm slightly loathing to take on much more packages before I make sure I can keep up with the ones I have at the moment. Maciej From phil at bolthole.com Fri Nov 20 20:53:19 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 11:53:19 -0800 Subject: [csw-maintainers] Mike Watters going sabbatical In-Reply-To: References: <281EC0A2-937C-4649-8CF0-7DC95F3F1488@opencsw.org> Message-ID: On Fri, Nov 20, 2009 at 11:43 AM, Maciej (Matchek) Blizinski wrote: > On Fri, Nov 20, 2009 at 5:22 PM, Philip Brown wrote: >> FYI, Maciej is already working on a sudo update. > > Yes, I am. ?I also have filed a bug against Python (deprecate the > CSWpython-rt package) which is easy enough to do. ?There's a number of > very significant packages that Mike has been maintaining. ?I think > it's a very good thing that it's easy to continue Mike's work, and I > might be building new versions of some if his packages. ?However, I'm > slightly loathing to take on much more packages before I make sure I > can keep up with the ones I have at the moment. > The REAALLY important one,is php ! From phil at bolthole.com Fri Nov 20 20:57:26 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 11:57:26 -0800 Subject: [csw-maintainers] coreutils Message-ID: On Fri, Nov 20, 2009 at 11:29 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Nov 20 14:25:02 -0500 2009: >> >> for example, one of them that you named, CSWshutils, has 3 packages >> depending on it. > > Ok, bigger job, but the payoff is worthwhile. > A thought: one way to handle this, over a LONG term, would be to define a virtual package CSWcoreutils (hmm.. or CSWgcoreutils, or CSWgnucoreutils might be better) which depended on all the ones it will eventually replace. Then you could focus on updating dependancies to point at the new package, over time. THEN, once things are finally all pointing at the new package, you would then be free and clear to do your original planned "easy way". Contrariwise, you could compile coreutils, but actually have it split up into the old-style packages, release it now as-is (replacing those older CSWgxxx packages), and that wya, leave the dependancies alone :-) From bwalton at opencsw.org Fri Nov 20 22:27:22 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 20 Nov 2009 16:27:22 -0500 Subject: [csw-maintainers] cswclassutils cswinetdconf In-Reply-To: <625385e30911200944rf45927clb1a5a27f320860f2@mail.gmail.com> References: <4B06B65E.80008@cognigencorp.com> <1258733431-sup-8799@ntdws12.chass.utoronto.ca> <625385e30911200944rf45927clb1a5a27f320860f2@mail.gmail.com> Message-ID: <1258752409-sup-2194@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Fri Nov 20 12:44:50 -0500 2009: > As you always use network you could just do something like this: > > [ ! -d $outdir ] && mkdir $outdir ...changes committed. Can you stick an update in testing/? 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 Nov 21 10:56:15 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 21 Nov 2009 10:56:15 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: <41050420-A9A4-4241-9332-16A4A16BF73E@opencsw.org> Hi Phil, Am 20.11.2009 um 18:10 schrieb Philip Brown: > On Fri, Nov 20, 2009 at 6:24 AM, Dagobert Michelsen > wrote: >> Hi Phil, >> >> Am 18.11.2009 um 19:16 schrieb Philip Brown: >>> >>>> I dont think we have any business conflicting with packages that >>>> arent >>>> "ours". >>> >>> Let me give just one explicit example of why: >>> >>> "pkg-get install all" >> >> I can't imagine a single use of this. Why would anybody would want >> all >> packages? >> There is so much special stuff in the catalog that I simply cannot >> imagine >> that >> anybody would actually want to install everything. > > That's kind of like saying, "I cant imagine anyone would do a 'full > install' in solaris. there's so many packages in there, no-one will > want to actually use everything". Anyway, this is not the point here. The point is: how can we integrate packages that replace existing Solaris functionality without breaking the usecase you described. I proposed a different package name prefix. Please state if this would be feasible or if you have a better idea. At least Sebastian and me are using it, so there is obiously a need for this kind of packages. The example sendmail would also be a good candidate for this. Best regards -- Dago From dam at opencsw.org Sat Nov 21 10:59:16 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 21 Nov 2009 10:59:16 +0100 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: References: <4B06BED1.6040206@cognigencorp.com> <4B06CE04.2060408@cognigencorp.com> Message-ID: Hi, Am 20.11.2009 um 18:21 schrieb Philip Brown: > On Fri, Nov 20, 2009 at 9:12 AM, Darin Perusich > wrote: >> Yes, but when you use 'createpkg' and the prototype doesn't contain >> 'i >> copyright' it exists and tells you to add it. I'm going to assume >> people >> getting around this by including 'i copyright' in their prototypes >> which >> has a blurp about where to see the full license... > > yes exactly. It's not a "getting around this" thing, it's a "what > you're expected to do" sort of thing. > Sorry if it isnt documented well. > > GAR automatically puts in a stub "here's where the copyright is" thing > automagically, btw. Am 20.11.2009 um 18:12 schrieb Darin Perusich: > I don't have a problem using either of these methods, I'm simply > looking > for a little guidance on what might be considered the best practice > for > accomplishing this. And, yes, using GAR is the best practice for this. With the sabbatical of Mike we have another excellent example why it is a good idea to have a central repository with standardized build recipes. It allowed Maciej to take over sudo in no time. Best regards -- Dago From maciej at opencsw.org Sat Nov 21 12:09:10 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 21 Nov 2009 11:09:10 +0000 Subject: [csw-maintainers] nspr in testing/ In-Reply-To: References: Message-ID: I have a question, mostly to Phil, about one shared object file in CSWnspr. Here's the prototype bit: d none /opt/csw/lib/nspr/cpu 0755 root bin d none /opt/csw/lib/nspr/cpu/sparcv8plus 0755 root bin f none /opt/csw/lib/nspr/cpu/sparcv8plus/libnspr_flt4.so 0755 root bin It looks like nspr builds one V8+ shared library on purpose. It puts it in a separate directory. All other shared libraries are V8. Normally, packages with V8+ binaries are rejected. In this case, there's a clearly separate V8+ binary, which looks optional to me. Would it be a problem to include it in the package? Or should I just exclude it? Maciej From bwalton at opencsw.org Sat Nov 21 15:11:47 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 21 Nov 2009 09:11:47 -0500 Subject: [csw-maintainers] cswclassutils cswinetdconf In-Reply-To: <4B06B65E.80008@cognigencorp.com> References: <4B06B65E.80008@cognigencorp.com> Message-ID: <1258811600-sup-8997@ntdws12.chass.utoronto.ca> Excerpts from Darin Perusich's message of Fri Nov 20 10:31:42 -0500 2009: Hi Darin, > When I perform a verbose install I see the class is trying to install > the manifest into /var/opt/csw/svc/manifest/network, a directory which > doesn't exist! Shouldn't the class action script create this directory > if it doesn't exist or fall back on /var/svc/manifest/network? There is an updated version of cswclassutils in testing/. Peter is going to release it later today, but if you want to do local tests of the packaging and install, etc, please use 1.30. 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 Sat Nov 21 21:43:09 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 21 Nov 2009 20:43:09 +0000 Subject: [csw-maintainers] Building Mozilla NSS (it aborts) Message-ID: I'm working on NSS, Mozilla's Network Security Services[1] library. I've already jumped over a number of hoops, but I'm now stuck-ish. During the build stage, a 'shlibsign' binary is called; it's part of the NSS build. At first it was (consistently) segfaulting. I figured out that it was missing a search path to libsqlite3.so, I added a runtime search path option (not via GNU make flags, I had to patch the NSS sources as their build ignores LDFLAGS and LD_OPTIONS). Now it aborts, like this: gmake[5]: Leaving directory `/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/mangle' cd SunOS5.8_OPT.OBJ ; sh /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/./sign.sh /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/../../../dist/SunOS5.8_OPT.OBJ \ /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/SunOS5.8_OPT.OBJ SunOS \ /opt/csw/lib/nspr /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/../../../dist/SunOS5.8_OPT.OBJ/lib/libsoftokn3.so /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/SunOS5.8_OPT.OBJ/shlibsign -v -i /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/../../../dist/SunOS5.8_OPT.OBJ/lib/libsoftokn3.so moduleSpec configdir='' certPrefix='' keyPrefix='' secmod='' flags=noCertDB, noModDB Abort - core dumped gmake[4]: *** [../../../dist/SunOS5.8_OPT.OBJ/lib/libsoftokn3.chk] Error 134 gmake[4]: Leaving directory `/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign' The relevant bit of truss output: 17896: stat("/opt/csw/lib/nspr/libkstat.so.1", 0xFFBFDF30) Err#2 ENOENT 17896: stat("/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/dist/SunOS5.8_OPT.OBJ/lib/libkstat.so.1", 0xFFBFDF30) Err#2 ENOENT 17896: stat("/usr/lib/libkstat.so.1", 0xFFBFDF30) = 0 17896: resolvepath("/usr/lib/libkstat.so.1", "/usr/lib/libkstat.so.1", 1023) = 22 17896: open("/usr/lib/libkstat.so.1", O_RDONLY) = 3 17896: mmap(0xFF010000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF010000 17896: mmap(0x00000000, 81920, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON, -1, 0) = 0xFED90000 17896: mmap(0xFED90000, 4030, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFED90000 17896: mmap(0xFEDA2000, 460, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 8192) = 0xFEDA2000 17896: munmap(0xFED92000, 65536) = 0 17896: memcntl(0xFED90000, 2244, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 17896: close(3) = 0 17896: munmap(0xFF010000, 8192) = 0 17896: sigaction(SIGABRT, 0x00000000, 0xFFBFE2C8) = 0 17896: lwp_sigtimedwait(0xFFBFE2D0, 0xFFBFE220, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE210, 0xFFBFE2D0, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE2C8, 0xFFBFE560, 0x00000020) = 0 17896: llseek(0, 0, SEEK_CUR) = 7044041 17896: lwp_sigtimedwait(0xFFBFE390, 0xFFBFE250, 0x00000020) = 0 17896: lwp_sigtimedwait(0xFFBFE258, 0xFFBFE180, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE170, 0xFFBFE258, 0x00000010) = 0 17896: sigaction(SIGABRT, 0xFFBFE250, 0xFFBFE228) = 0 17896: lwp_sigtimedwait(0xFFBFE230, 0xFFBFE180, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE170, 0xFFBFE230, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE228, 0xFFBFE4B0, 0x00000020) = 0 17896: lwp_sigtimedwait(0xFF167C18, 0xFFBFE248, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE238, 0xFFBFE2C0, 0x00000010) = 0 17896: sigprocmask(SIG_SETMASK, 0xFFBFE2C0, 0xFFBFE2D0) = 0 17896: lwp_sigtimedwait(0xFFBFE2D0, 0xFFBFE248, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE238, 0xFFBFE410, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE3FC, 0xFFBFE248, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE238, 0xFFBFE2C0, 0x00000010) = 0 17896: sigprocmask(SIG_SETMASK, 0xFFBFE2C0, 0x00000000) = 0 17896: lwp_kill(1, SIGABRT) = 0 17896: Received signal #6, SIGABRT [default] 17896: siginfo: SIGABRT pid=17896 uid=17108 code=-1 17896: *** process killed *** My vague plan is to alter the build so that a binary with debugging symbols is produced; then run the offending program under dbx. Before I continue attacking this build, do you have any ideas on how to proceed? Do you have any other ideas than just debugging this binary? The problem is 100% reproducible, the code is in Subversion. In order to reproduce it, one needs to have CSWnspr-devel installed (it's in testing). I was working on NSS on build8st. Maciej [1] http://www.mozilla.org/projects/security/pki/nss/ From maciej at opencsw.org Sun Nov 22 13:10:18 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 22 Nov 2009 12:10:18 +0000 Subject: [csw-maintainers] Building Mozilla NSS (it aborts) In-Reply-To: References: Message-ID: I've found the place where it aborts[1], by running shlibsign under dbx: (dbx) unOS5.8_DBG.OBJ/lib/libsoftokn3.so" < Running: shlibsign -v -i /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/../../../dist/SunOS5.8_DBG.OBJ/lib/libsoftokn3.so (process id 1696) Reading libsoftokn3.so Reading libnssutil3.so Reading libsqlite3.so.0 Reading libbsm.so.1 moduleSpec configdir='' certPrefix='' keyPrefix='' secmod='' flags=noCertDB, noModDB Reading libfreebl_32fpu_3.so Reading libkstat.so.1 t at 1 (l at 1) signal ABRT (Abort) in (unknown) at 0xff3db7b0 0xff3db7b0: bcc,pt %icc,0xff3db7c4 ! 0xff3db7c4 Current function is PR_NewLock_stub 429 abort(); (dbx) where current thread: t at 1 [1] 0xff3db7b0(0xffbfe220, 0xa3, 0x1, 0x6, 0x0, 0x6), at 0xff3db7b0 [2] 0xff3d7ff4(0x1, 0x6, 0x0, 0xfefbc000, 0xff166000, 0x0), at 0xff3d7ff4 [3] 0xff3db710(0x1, 0x6, 0x0, 0xfefbc000, 0xff166000, 0x0), at 0xff3db710 [4] raise(0x6, 0x0, 0x0, 0xffffffff, 0xfefc03cc, 0x29010), at 0xfef4bd1c [5] abort(0xfefbc000, 0xff1b3e18, 0xff1b2984, 0x1494, 0x1e90c, 0x1400), at 0xfef35a34 =>[6] PR_NewLock_stub(), line 429 in "stubs.c" [7] rng_init(), line 391 in "drbg.c" [8] PR_CallOnce(0x1494, 0xfec3ac08, 0x1400, 0x27c24, 0xfecbdcfc, 0xff1b2984), at 0xff18adcc [9] PR_CallOnce_stub(once = 0xfecbdcfc, func = 0xfec3ac08 = &`libfreebl_32fpu_3.so`drbg.c`rng_init()), line 463 in "stubs.c" [10] RNG_RNGInit(), line 469 in "drbg.c" [11] RNG_RNGInit(), line 834 in "loader.c" [12] nsc_CommonInitialize(pReserved = 0xffbfe8f4, isFIPS = 0), line 2582 in "pkcs11.c" [13] NSC_Initialize(pReserved = 0xffbfe8f4), line 2710 in "pkcs11.c" [14] softokn_Init(pFunctionList = 0xfee59224, configDir = (nil), dbPrefix = (nil)), line 474 in "shlibsign.c" [15] main(argc = 4, argv = 0xffbff314), line 802 in "shlibsign.c" (dbx) >From reading the comments at the top of the stubs.c file it looks like it's a file which defines function stubs which are to be later overriden when loading shared libraries (util and nspr). I've trussed the execution of shlibsign and as far as I can tell, it finds each and every shared object it's looking for. Also, ldd shows that it finds all the libraries: maciej at build8st [build8st]:~/src/opencsw/pkg/nss/trunk > ldd /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/SunOS5.8_DBG.OBJ/shlibsign /usr/lib/secure/s8_preload.so.1 libplc4.so => /opt/csw/lib/nspr//libplc4.so libplds4.so => /opt/csw/lib/nspr//libplds4.so libnspr4.so => /opt/csw/lib/nspr//libnspr4.so libthread.so.1 => /usr/lib/libthread.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 librt.so.1 => /usr/lib/librt.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libc.so.1 => /usr/lib/libc.so.1 libpthread.so.1 => /usr/lib/libpthread.so.1 libmp.so.2 => /usr/lib/libmp.so.2 libaio.so.1 => /usr/lib/libaio.so.1 /opt/csw/lib/nspr/cpu/sparcv8plus/libnspr_flt4.so /usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 I'm really stuck now. Right now, it looks like I have to see how shared libraries are loaded and how function names get overriden. Hic sunt dracones. How do I debug the order in which shared libraries are loaded and why aren't NSPR stubs overriden with the actual functions? Do you have any hints? [1] http://mxr.mozilla.org/security/source/security/nss/lib/freebl/stubs.c#424 [2] http://mxr.mozilla.org/security/source/security/nss/lib/freebl/stubs.c#38 From korpela at ssl.berkeley.edu Thu Nov 19 17:56:24 2009 From: korpela at ssl.berkeley.edu (Eric J Korpela) Date: Thu, 19 Nov 2009 08:56:24 -0800 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: <83CED7D4-8FCB-4D9D-965F-4D8975BEEF6D@opencsw.org> References: <83CED7D4-8FCB-4D9D-965F-4D8975BEEF6D@opencsw.org> Message-ID: 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. Eric On Tue, Nov 17, 2009 at 8:45 AM, Dagobert Michelsen wrote: > Hi Erik, > > Am 16.11.2009 um 22:19 schrieb Eric J Korpela: >> >> I'll try to build boincmanager against the new libraries some time this >> week > > Cool. Let me know if you need additional machines or installs on build*t as > the > updated wxwidgets library will only be installed on build*s/x after release > and > there is still an unresolved issue. > > > Best regards > > ?-- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > From wbonnet at opencsw.org Sat Nov 21 15:26:51 2009 From: wbonnet at opencsw.org (William Bonnet) Date: Sat, 21 Nov 2009 15:26:51 +0100 Subject: [csw-maintainers] nspr in testing/ In-Reply-To: References: Message-ID: <4B07F8AB.4060607@opencsw.org> Hi > I've seen that William has done some work on the nspr library > (netscape portable runtime). I know that Firefox needs it, so I'm not > sure how is William currently compiling Firefox. I thought it would > be good to have nspr as a separate library, in case someone wants to > build a package with nspr as a dependency, such as Evolution, > xulrunner, NSS (Mozilla's Network Security Services library), etc. > I do agree. I was planning to do it one day, but it is deep in my too long todo list ;) Thanks for working on this. Actually it is need for evolution which depends on firefox only for this runtime. > I did some changes to the Makefile which was in the repository. I > took out the --with-dist-prefix and --with-dist-bindir options. I > assumed that William worked with only Firefox in mind, I want to have > a regular system library. > It was a very first version. You can modify everything you need. I stopped working on this some month ago. It seems to me that this runtime will be useful for application like evolution xulrunner, etc. but i am not sure i'll be able to use it for FF, SM or TB. Versions are different, and they need the associated NSPR which is currently provided with the package. For others application it's really cool :) cheers W. -- William Bonnet http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From rupert at opencsw.org Sun Nov 22 17:00:48 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 22 Nov 2009 17:00:48 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <20091117084609.GD1788@sebastiankayser.de> References: <4ADA85FA.7090506@opencsw.org> <20091110134933.GC30301@sebastiankayser.de> <6af4270911141103p550e49ebr208a62ae9cdf3836@mail.gmail.com> <20091117084609.GD1788@sebastiankayser.de> Message-ID: <6af4270911220800y8267bffua1e85e151a8f76e0@mail.gmail.com> On Tue, Nov 17, 2009 at 09:46, Sebastian Kayser wrote: > * rupert THURNER wrote: > >> On Tue, Nov 10, 2009 at 14:49, Sebastian Kayser <[1]skayser at opencsw.org > > > >> wrote: > >> Any progress on the "new subversion/trac packages" front? I have had > >> internal requests for 1.6.6 (quite a bit of bugfixes [1] from our > >> current/ 1.6.2) and saw that a 1.6.5 build recipe with the adjusted > >> python bindings package name is already in GAR. > > > > i compiled it and put it in testing - as we want to do that upgrade as > > well soon. i made it world writeable so anybody can overwrite it in case. > > Thanks, Rupert. The GAR build recipe for subversion skips the tests, did > you run these for the updated version? > > i did PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" rupert at build8s :~/mgar/pkg/subversion/trunk/work/solaris8-sparc/build-isa-sparcv8/subversion-1.6.6 $ make check -j $PARALLELMFLAGS Running all tests in auth-test [1/71]...success Running all tests in cache-test [2/71]...success ... but i must admit i had only the patience to wait until test 34 out of 71 on both build8x and build8s - then it started to take forever. so i wonder if this parallel make is really working, or how it could be made working? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Nov 22 17:08:08 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 22 Nov 2009 16:08:08 +0000 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <6af4270911220800y8267bffua1e85e151a8f76e0@mail.gmail.com> References: <4ADA85FA.7090506@opencsw.org> <20091110134933.GC30301@sebastiankayser.de> <6af4270911141103p550e49ebr208a62ae9cdf3836@mail.gmail.com> <20091117084609.GD1788@sebastiankayser.de> <6af4270911220800y8267bffua1e85e151a8f76e0@mail.gmail.com> Message-ID: On Sun, Nov 22, 2009 at 4:00 PM, rupert THURNER wrote: > but i must admit i had only the patience to wait until test 34 out of 71 I suggest issuing "gmake platforms" in GNU screen on the login host and going to sleep. You'll see the results the next morning. That's what I do anyway. Maciej From skayser at opencsw.org Sun Nov 22 22:28:07 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 22 Nov 2009 22:28:07 +0100 Subject: [csw-maintainers] OpenCSW Winter Camp 2009, when/where? Feedback needed. In-Reply-To: <4AC51D40.7060007@opencsw.org> References: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> <4AC51D40.7060007@opencsw.org> Message-ID: <4B09ACE7.9040307@opencsw.org> Sebastian Kayser wrote on 01.10.2009 23:21: > Sebastian Kayser wrote on 24.09.2009 19:02: >> before we head to Toronto next year in summer :D, i would like to kick off >> this year's winter camp preparations for Munich. Two votes need your >> input. >> >> - Which weekend can you participate? >> http://doodle.com/p3rvwqkx542cu4rx >> >> - Which venue would you prefer (city/nature)? >> http://doodle.com/xwnhvxp274i8b3iv > > Thanks to those who already voted, looking forward to seeing you (again) > in a couple of months. Anyone else interested in coming? If so, please > take part in the above polls so that we can plan accordingly (i will try > to fix a date and venue by the end of next week). Sorry, it has taking me so long to pick this up again. Is the 22.01. - 24.01. still a valid date for those who are interested in coming? If there are no objections, I will go ahead and book the venue this Tuesday. Sebastian From maciej at opencsw.org Sun Nov 22 22:28:06 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 22 Nov 2009 21:28:06 +0000 Subject: [csw-maintainers] nspr in testing/ In-Reply-To: <4B07F8AB.4060607@opencsw.org> References: <4B07F8AB.4060607@opencsw.org> Message-ID: On Sat, Nov 21, 2009 at 2:26 PM, William Bonnet wrote: > Thanks for working on this. ?Actually it is need for evolution which depends > on firefox only for this runtime. Right, I've seen the nss libraries in the Firefox package. Packages for Linux distributions also include the nss.pc file, which isn't there in the Firefox package. Interestingly, it's also not in the separate NSS source, distributions create custom nss.pc to allow other programs to compile. Debian also creates custom nss-config. > It was a very first version. You can modify everything you need. I stopped > working on this some month ago. It seems to me that this runtime will be > useful for application like evolution xulrunner, etc. but i am not sure i'll > be able to use it for FF, SM or TB. Versions are different, and they need > the associated NSPR which is currently provided with the package. I see. I would be curious to see how is the Firefox-bundled NSS compiled. I'm banging my head against shlibsign which won't be nice load shared objects. Maciej From dam at opencsw.org Sun Nov 22 23:01:40 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 22 Nov 2009 23:01:40 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <6af4270911220800y8267bffua1e85e151a8f76e0@mail.gmail.com> References: <4ADA85FA.7090506@opencsw.org> <20091110134933.GC30301@sebastiankayser.de> <6af4270911141103p550e49ebr208a62ae9cdf3836@mail.gmail.com> <20091117084609.GD1788@sebastiankayser.de> <6af4270911220800y8267bffua1e85e151a8f76e0@mail.gmail.com> Message-ID: Hi Rupert, Am 22.11.2009 um 17:00 schrieb rupert THURNER: > On Tue, Nov 17, 2009 at 09:46, Sebastian Kayser wrote: > * rupert THURNER wrote: > >> On Tue, Nov 10, 2009 at 14:49, Sebastian Kayser <[1]skayser at opencsw.org> > >> wrote: > >> Any progress on the "new subversion/trac packages" front? I have had > >> internal requests for 1.6.6 (quite a bit of bugfixes [1] from our > >> current/ 1.6.2) and saw that a 1.6.5 build recipe with the adjusted > >> python bindings package name is already in GAR. > > > > i compiled it and put it in testing - as we want to do that upgrade as > > well soon. i made it world writeable so anybody can overwrite it in case. > > Thanks, Rupert. The GAR build recipe for subversion skips the tests, did > you run these for the updated version? > > > > i did > > PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" > rupert at build8s:~/mgar/pkg/subversion/trunk/work/solaris8-sparc/build-isa-sparcv8/subversion-1.6.6 > $ make check -j $PARALLELMFLAGS > Running all tests in auth-test [1/71]...success > Running all tests in cache-test [2/71]...success > ... > > but i must admit i had only the patience to wait until test 34 out of 71 on both build8x and build8s - then it started to take forever. so i wonder if this parallel make is really working, or how it could be made working? Usually the tests are one script which doesn't honor parallel builds. It is only valid for builds inside make. Best regards -- Dago From bwalton at opencsw.org Sun Nov 22 23:05:20 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 22 Nov 2009 17:05:20 -0500 Subject: [csw-maintainers] coreutils In-Reply-To: References: Message-ID: <1258926663-sup-4645@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Nov 20 14:57:26 -0500 2009: > one way to handle this, over a LONG term, would be to define a > virtual package CSWcoreutils (hmm.. or CSWgcoreutils, or > CSWgnucoreutils might be better) which depended on all the ones it > will eventually replace. I don't think it's as large a task as I'd thought. The following packages have dependencies on one or more of {textutils, shutils, fileutils}. CSWquilt (Murray Jensen) CSWgardevel (me) CSWbuildbot (Maciej) CSWcswutils (Dago) CSWxmlto (me) CSWlogwatch (Christian Pearce, retired) CSWgcc3core (Peter F) CSWrubydev (me) CSWcolormake (orphaned) CSWwgetpaste (Maciej) So, of the 10 affected packages, I'm responsible for 3, Maciej 2, Dago 1 and Peter F 1. I'm not sure how active Murray is, but his status is still 'active', so presumably he'd reroll quilt. That leaves only 2 orphaned packages for pickup. Logwatch should be near trivial, I think and I'm not sure what colormake would be like. I've fixed a bunch of the breakages I found in coreutils already and we have a coreutils devel with a buildfarm account that I'll leverage to help fix anything I can't do on my own. Given the above, I think it's pretty reasonable to have all packages with deps on the old names updated and a coreutils release at the same time. Thoughts? 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 Sun Nov 22 23:14:09 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 22 Nov 2009 23:14:09 +0100 Subject: [csw-maintainers] coreutils In-Reply-To: <1258926663-sup-4645@ntdws12.chass.utoronto.ca> References: <1258926663-sup-4645@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 22.11.2009 um 23:05 schrieb Ben Walton: > Excerpts from Philip Brown's message of Fri Nov 20 14:57:26 -0500 2009: > >> one way to handle this, over a LONG term, would be to define a >> virtual package CSWcoreutils (hmm.. or CSWgcoreutils, or >> CSWgnucoreutils might be better) which depended on all the ones it >> will eventually replace. > > I don't think it's as large a task as I'd thought. The following > packages have dependencies on one or more of {textutils, shutils, > fileutils}. > > CSWquilt (Murray Jensen) > CSWgardevel (me) > CSWbuildbot (Maciej) > CSWcswutils (Dago) > CSWxmlto (me) > CSWlogwatch (Christian Pearce, retired) > CSWgcc3core (Peter F) > CSWrubydev (me) > CSWcolormake (orphaned) > CSWwgetpaste (Maciej) > > So, of the 10 affected packages, I'm responsible for 3, Maciej 2, Dago > 1 and Peter F 1. I'm not sure how active Murray is, but his status is > still 'active', so presumably he'd reroll quilt. I just got an email from him that he is still with us, but didn't have the time (yet) to jump onto GAR. Maybe we can help him to get started with a one-on-one tutorial with one of his packages. > That leaves only 2 > orphaned packages for pickup. Logwatch should be near trivial, I > think and I'm not sure what colormake would be like. Just a script, but a manual build. Should be no longer than maybe two hours or so. > I've fixed a bunch of the breakages I found in coreutils already and > we have a coreutils devel with a buildfarm account that I'll leverage > to help fix anything I can't do on my own. > > Given the above, I think it's pretty reasonable to have all packages > with deps on the old names updated and a coreutils release at the same > time. > > Thoughts? I really like to see that you are going to work on this. Will your work also include adding the gnu links inside the packages? Best regards -- Dago From bwalton at opencsw.org Sun Nov 22 23:33:18 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 22 Nov 2009 17:33:18 -0500 Subject: [csw-maintainers] coreutils In-Reply-To: References: <1258926663-sup-4645@ntdws12.chass.utoronto.ca> Message-ID: <1258929133-sup-6551@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sun Nov 22 17:14:09 -0500 2009: > I really like to see that you are going to work on this. Will your work > also include adding the gnu links inside the packages? Yes, I'll add all the gnulinks as required for the coreutils package. A few other tools (gmake, gpatch), etc would need to be updated to provide their own links too. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton at opencsw.org Mon Nov 23 01:42:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 22 Nov 2009 19:42:12 -0500 Subject: [csw-maintainers] coreutils In-Reply-To: <1258929133-sup-6551@ntdws12.chass.utoronto.ca> References: <1258926663-sup-4645@ntdws12.chass.utoronto.ca> <1258929133-sup-6551@ntdws12.chass.utoronto.ca> Message-ID: <1258936877-sup-2095@ntdws12.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Nov 22 17:33:18 -0500 2009: > Yes, I'll add all the gnulinks as required for the coreutils package. > A few other tools (gmake, gpatch), etc would need to be updated to > provide their own links too. ...I wonder if a class action script might be nice for this instead of packaged files? That way, each site could still determine whether or not /opt/csw/gnu files were desired by setting a flag in csw.conf. Thoughts? -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 Mon Nov 23 13:20:38 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 23 Nov 2009 13:20:38 +0100 Subject: [csw-maintainers] New cswclassutils: cswcron, cswtexinfo, cswmigrateconf and GAR integration In-Reply-To: <8D0258D5-569F-4FD5-BB5E-1A1B72209D25@opencsw.org> References: <0691F15A-1BF5-4817-968F-449FC848E2D7@opencsw.org> <4B046F0F.6060509@opencsw.org> <8D0258D5-569F-4FD5-BB5E-1A1B72209D25@opencsw.org> Message-ID: <20091123122038.GL1788@sebastiankayser.de> * Dagobert Michelsen wrote: > Am 18.11.2009 um 23:02 schrieb Sebastian Kayser: > >i have been trying to leverage MIGRATE_FILES for axel, the > >cswmigrateconf stays empty though. > > > >... > >sysconfdir = /etc/opt/csw > >SAMPLECONF = $(sysconfdir)/axelrc > >MIGRATE_FILES = axelrc > >... > > > >skayser @ build8x ~/mgar/pkg/axel/trunk$ cat work/solaris8-i386/ > >pkgroot/etc/opt/csw/pkg/CSWaxel/cswmigrateconf > >MIGRATE_FILES="" > > > >Build files are checked in, would you mind having a look? > > You are right. This rule-specific assignment in GNU Make is tricky. > This is hopefully fixed in r7361. Works for me. Thanks! Sebastian From maciej at opencsw.org Mon Nov 23 13:41:37 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 23 Nov 2009 12:41:37 +0000 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link Message-ID: I'm working on a library package with the *.so files in /opt/csw/lib/foo. The package will have 64-bit support, so the shared objects will be: /opt/csw/lib/foo/*.so /opt/csw/lib/foo/sparcv9/*.so /opt/csw/lib/foo/amd64/*.so I've noticed that CSWcommon provides a symlink: /opt/csw/lib/64. It points to amd64 or sparcv9 depending on the host architecture. This link is needed to provide a architecture independent -L flag for 64-bit builds: /opt/csw/lib/foo/64. I guess that something along the lines of ln -s sparcv9 /opt/csw/lib/foo/64, or amd64, depending on the architecture. What's the right GAR idiom for it? Should it be a post-merge target? Maciej From phil at bolthole.com Mon Nov 23 18:51:46 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Nov 2009 09:51:46 -0800 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: References: <4B06BED1.6040206@cognigencorp.com> <4B06CE04.2060408@cognigencorp.com> Message-ID: On Sat, Nov 21, 2009 at 1:59 AM, Dagobert Michelsen wrote: > > And, yes, using GAR is the best practice for this. With the sabbatical > of Mike we have another excellent example why it is a good idea to have > a central repository with standardized build recipes. It allowed > Maciej to take over sudo in no time. > bad example :-) From phil at bolthole.com Mon Nov 23 18:53:48 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Nov 2009 09:53:48 -0800 Subject: [csw-maintainers] nspr in testing/ In-Reply-To: References: Message-ID: On Sat, Nov 21, 2009 at 3:09 AM, Maciej (Matchek) Blizinski wrote: > I have a question, mostly to Phil, about one shared object file in > CSWnspr. ?Here's the prototype bit: > > d none /opt/csw/lib/nspr/cpu 0755 root bin > d none /opt/csw/lib/nspr/cpu/sparcv8plus 0755 root bin > f none /opt/csw/lib/nspr/cpu/sparcv8plus/libnspr_flt4.so 0755 root bin > > It looks like nspr builds one V8+ shared library on purpose. ?It puts > it in a separate directory. ?All other shared libraries are V8. > Normally, packages with V8+ binaries are rejected. ?In this case, > there's a clearly separate V8+ binary, which looks optional to me. > Would it be a problem to include it in the package? ?Or should I just > exclude it? > you absolutely SHOULD include it. looks very clean. There is no global restriction about V8+ binaries. there's just a restriction against them as /opt/csw/bin/executable_here From phil at bolthole.com Mon Nov 23 18:56:06 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Nov 2009 09:56:06 -0800 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: Message-ID: On Mon, Nov 23, 2009 at 4:41 AM, Maciej (Matchek) Blizinski wrote: > I'm working on a library package with the *.so files in > /opt/csw/lib/foo. ?The package will have 64-bit support, so the shared > objects will be: > > /opt/csw/lib/foo/*.so > /opt/csw/lib/foo/sparcv9/*.so > /opt/csw/lib/foo/amd64/*.so > > I've noticed that CSWcommon provides a symlink: /opt/csw/lib/64. ?It > points to amd64 or sparcv9 depending on the host architecture. ?This > link is needed to provide a architecture independent -L flag for > 64-bit builds: /opt/csw/lib/foo/64. > > I guess that something along the lines of ln -s sparcv9 > /opt/csw/lib/foo/64, or amd64, depending on the architecture. ?What's > the right GAR idiom for it? ?Should it be a post-merge target? > Eh, that's just a convention. If the library (or packages USING the library) work as-is, there's no need for you to be making those symlinks. From phil at bolthole.com Mon Nov 23 18:59:28 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Nov 2009 09:59:28 -0800 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: <41050420-A9A4-4241-9332-16A4A16BF73E@opencsw.org> References: <41050420-A9A4-4241-9332-16A4A16BF73E@opencsw.org> Message-ID: On Sat, Nov 21, 2009 at 1:56 AM, Dagobert Michelsen wrote: > >> >> That's kind of like saying, "I cant imagine anyone would do a 'full >> install' in solaris. there's so many packages in there, no-one will >> want to actually use everything". > > Anyway, this is not the point here. The point is: how can we integrate > packages that replace existing Solaris functionality without breaking > the usecase you described. I proposed a different package name prefix. > Please state if this would be feasible or if you have a better idea. > At least Sebastian and me are using it, so there is obiously a need > for this kind of packages. The example sendmail would also be a good > candidate for this. > I think you are stating the "need" in an overly narrow way. Probably the "need" would be better stated as, "How can we replace sun-package functionality, WHEN THE USER CHOOSES US TO, in a way that is easy for the user?" Woudl you like to start a fresh email "thread", with that as the start prompt? (and re-mention the concern that "install all" of CSW packages, should not blow away sun stuff by default; only if the user has made some kind of choice somewhere) From phil at bolthole.com Mon Nov 23 19:02:10 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Nov 2009 10:02:10 -0800 Subject: [csw-maintainers] coreutils In-Reply-To: <1258936877-sup-2095@ntdws12.chass.utoronto.ca> References: <1258926663-sup-4645@ntdws12.chass.utoronto.ca> <1258929133-sup-6551@ntdws12.chass.utoronto.ca> <1258936877-sup-2095@ntdws12.chass.utoronto.ca> Message-ID: On Sun, Nov 22, 2009 at 4:42 PM, Ben Walton wrote: > Excerpts from Ben Walton's message of Sun Nov 22 17:33:18 -0500 2009: >> Yes, I'll add all the gnulinks as required for the coreutils package. >> A few other tools (gmake, gpatch), etc would need to be updated to >> provide their own links too. > > ...I wonder if a class action script might be nice for this instead of > packaged files? ?That way, each site could still determine whether or > not /opt/csw/gnu files were desired by setting a flag in csw.conf. > > Thoughts? > well, there's no harm in providing the /opt/csw/gnu links. If they dont like em, then just dont add /opt/csw/gnu to their path. so I dont see a need to allow the user to opt out of creating them. From maciej at opencsw.org Mon Nov 23 22:57:48 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 23 Nov 2009 21:57:48 +0000 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: Message-ID: On Mon, Nov 23, 2009 at 5:56 PM, Philip Brown wrote: > On Mon, Nov 23, 2009 at 4:41 AM, Maciej (Matchek) Blizinski > wrote: >> I'm working on a library package with the *.so files in >> /opt/csw/lib/foo. ?The package will have 64-bit support, so the shared >> objects will be: >> >> /opt/csw/lib/foo/*.so >> /opt/csw/lib/foo/sparcv9/*.so >> /opt/csw/lib/foo/amd64/*.so >> >> I've noticed that CSWcommon provides a symlink: /opt/csw/lib/64. ?It >> points to amd64 or sparcv9 depending on the host architecture. ?This >> link is needed to provide a architecture independent -L flag for >> 64-bit builds: /opt/csw/lib/foo/64. >> >> I guess that something along the lines of ln -s sparcv9 >> /opt/csw/lib/foo/64, or amd64, depending on the architecture. ?What's >> the right GAR idiom for it? ?Should it be a post-merge target? >> > > Eh, that's just a convention. If the library (or packages USING the > library) work as-is, there's no need for you to be making those > symlinks. It seems to me as those links are very useful. When you have the 64 --> {sparcv9,amd64} symlinks, you can say: LD_OPTIONS = -R/opt/csw/lib/$ISALIST -R/opt/csw/lib/64 ...and it will work on both sparcv9 and amd64. Here's how I did it in GAR: post-merge: if [ "$(GARCH)" = sparc ]; then \ gln -sf sparc9 $(PKGROOT)$(libdir)/64; \ elif [ "$(GARCH)" = i386 ]; then \ gln -sf amd64 $(PKGROOT)$(libdir)/64; \ fi @$(MAKECOOKIE) It created the right structure: maciej at build8s [build8s]:~/src/opencsw/pkg/nspr/trunk > tree work/solaris8-sparc/pkgroot/opt/csw/lib/nspr work/solaris8-sparc/pkgroot/opt/csw/lib/nspr |-- 64 -> sparc9 |-- cpu | `-- sparcv8plus | `-- libnspr_flt4.so |-- libnspr4.so -> libnspr4.so.8 |-- libnspr4.so.8 |-- libplc4.so -> libplc4.so.8 |-- libplc4.so.8 |-- libplds4.so -> libplds4.so.8 |-- libplds4.so.8 `-- sparcv9 |-- libnspr4.so -> libnspr4.so.8 |-- libnspr4.so.8 |-- libplc4.so -> libplc4.so.8 |-- libplc4.so.8 |-- libplds4.so -> libplds4.so.8 `-- libplds4.so.8 3 directories, 14 files After making the package: d none /opt/csw/lib/nspr 0755 root bin s none /opt/csw/lib/nspr/64=sparcv9 (...) I'll be able now to create NSS packages using -L/opt/csw/lib/nspr/64. From blizinski at google.com Mon Nov 23 13:36:47 2009 From: blizinski at google.com (Maciej (Matchek) Blizinski) Date: Mon, 23 Nov 2009 12:36:47 +0000 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link Message-ID: I'm working on a library package with the *.so files in /opt/csw/lib/foo. The package will have 64-bit support, so the shared objects will be: /opt/csw/lib/foo/*.so /opt/csw/lib/foo/sparcv9/*.so /opt/csw/lib/foo/amd64/*.so I've noticed that CSWcommon provides a symlink: /opt/csw/lib/64. It points to amd64 or sparcv9 depending on the host architecture. This link is needed to provide a architecture independent -L flag for 64-bit builds: /opt/csw/lib/foo/64. I guess that something along the lines of ln -s sparcv9 /opt/csw/lib/foo/64, or amd64, depending on the architecture. What's the right GAR idiom for it? Should it be a post-merge target? Maciej From dam at opencsw.org Tue Nov 24 16:41:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Nov 2009 16:41:18 +0100 Subject: [csw-maintainers] New members welcome! Message-ID: <64918FC7-ABDB-4D85-BEF8-D2C884350A7E@opencsw.org> Hi, the association welcomes the newly accepted members - Maciej Blizinski Maciej already maintains several packages including some hard updates including TightVNC and WxWidgets. 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. If you have applied for membership and don't see your name anywhere above please let me know. Best regards -- Dago From dam at opencsw.org Tue Nov 24 16:42:54 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Nov 2009 16:42:54 +0100 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: Message-ID: Hi, Am 23.11.2009 um 18:56 schrieb Philip Brown: > On Mon, Nov 23, 2009 at 4:41 AM, Maciej (Matchek) Blizinski > wrote: >> I'm working on a library package with the *.so files in >> /opt/csw/lib/foo. The package will have 64-bit support, so the >> shared >> objects will be: >> >> /opt/csw/lib/foo/*.so >> /opt/csw/lib/foo/sparcv9/*.so >> /opt/csw/lib/foo/amd64/*.so >> >> I've noticed that CSWcommon provides a symlink: /opt/csw/lib/64. It >> points to amd64 or sparcv9 depending on the host architecture. This >> link is needed to provide a architecture independent -L flag for >> 64-bit builds: /opt/csw/lib/foo/64. >> >> I guess that something along the lines of ln -s sparcv9 >> /opt/csw/lib/foo/64, or amd64, depending on the architecture. What's >> the right GAR idiom for it? Should it be a post-merge target? >> > > Eh, that's just a convention. If the library (or packages USING the > library) work as-is, there's no need for you to be making those > symlinks. If you need to include the library in any other package it is mandatory to have these links as linking is GAR goes per default against the /64 directory. Best regards -- Dago From dam at opencsw.org Tue Nov 24 16:54:58 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Nov 2009 16:54:58 +0100 Subject: [csw-maintainers] Replacing existing Solaris functionality by OpenCSW packages Message-ID: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> Hi, continuing the discussion about CUPS it would be nice to have a standardized method of replacing certain subsystems of Solaris with the corresponding OpenCSW packages. The idea is to have a base set of packages working simply as add-on which lives in the standard /opt/csw location (this is what we have now). To replace the existing Solaris subsystem an additional package is provided which links from the standard Solaris locations like /usr/bin to the OpenCSW binaries. This package depends on the CSW packages and is marked incompatible to the Solaris packages taking up the locations of the CSW links. 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 prefix The addons would be named CSWX... to mark that they are Xtra to install. On the contra side these exclusion must be hardwired to pkg* tools. - Different catalog The extra packages may be put in a separate catalog. This required a complete duplication of the current/s|i/5.x/ directory structure and could be intergated by catalog overlays alreaddy present in pkgutil. Packages which could profit from these concepts are - OpenSSH (replacing Sun SSH) - CUPS (replacing Sys V printing) - sendmail (replacing Sun sendmail) Feedback welcome! Best regards --Dago From dam at opencsw.org Tue Nov 24 17:01:52 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Nov 2009 17:01:52 +0100 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: Message-ID: Hi Maciej, Am 23.11.2009 um 22:57 schrieb Maciej (Matchek) Blizinski: > It seems to me as those links are very useful. When you have the 64 > --> {sparcv9,amd64} symlinks, you can say: > > LD_OPTIONS = -R/opt/csw/lib/$ISALIST -R/opt/csw/lib/64 > > ...and it will work on both sparcv9 and amd64. > > Here's how I did it in GAR: > > post-merge: > if [ "$(GARCH)" = sparc ]; then \ > gln -sf sparc9 $(PKGROOT)$(libdir)/64; \ > elif [ "$(GARCH)" = i386 ]; then \ > gln -sf amd64 $(PKGROOT)$(libdir)/64; \ > fi > @$(MAKECOOKIE) It is easier to use this: post-merge-modulated: gln -s $(ISA_DEFAULT64) $(PKGROOT)$(libdir)/64 @$(MAKECOOKIE) ISA_DEFAULT contains the default 32 bit ISA on this platform, ISA_DEFAULT64 contains the default 64 bit ISA on this platform. Best regards -- Dago From dam at opencsw.org Tue Nov 24 17:09:35 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Nov 2009 17:09:35 +0100 Subject: [csw-maintainers] General update of Perl to 5.10 Message-ID: <5C593CC9-E888-419F-A5F7-262215EE4561@opencsw.org> Hi Peter, I start to encounter the first modules requiring Perl 5.10: > ==> Running Makefile.PL in work/build-isa-i386/Date-Manip-6.01 > Perl v5.10.0 required--this is only v5.8.8, stopped at Makefile.PL > line 3. However, Sebastian stated that there are some serious issues in the past with 5.10. Should we wait some more ot has this already been settled? Best regards -- Dago From maciej at opencsw.org Tue Nov 24 17:30:02 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 24 Nov 2009 16:30:02 +0000 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: Message-ID: On Tue, Nov 24, 2009 at 4:01 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 23.11.2009 um 22:57 schrieb Maciej (Matchek) Blizinski: >> >> It seems to me as those links are very useful. ?When you have the 64 >> --> {sparcv9,amd64} symlinks, you can say: >> >> LD_OPTIONS = -R/opt/csw/lib/$ISALIST -R/opt/csw/lib/64 >> >> ...and it will work on both sparcv9 and amd64. >> >> Here's how I did it in GAR: >> >> post-merge: >> ? ? ? if [ "$(GARCH)" = sparc ]; then \ >> ? ? ? ? ? ? ? gln -sf sparc9 $(PKGROOT)$(libdir)/64; \ >> ? ? ? elif [ "$(GARCH)" = i386 ]; then \ >> ? ? ? ? ? ? ? gln -sf amd64 $(PKGROOT)$(libdir)/64; \ >> ? ? ? fi >> ? ? ? @$(MAKECOOKIE) > > It is easier to use this: > > post-merge-modulated: > ? ? ? ?gln -s $(ISA_DEFAULT64) $(PKGROOT)$(libdir)/64 > ? ? ? ?@$(MAKECOOKIE) > > ISA_DEFAULT contains the default 32 bit ISA on this platform, > ISA_DEFAULT64 contains the default 64 bit ISA on this platform. This fails: gln -s "sparcv9" "/home/maciej/src/opencsw/pkg/nspr/trunk/work/solaris8-sparc/pkgroot/opt/csw/lib/nspr/64/64" gln: `/home/maciej/src/opencsw/pkg/nspr/trunk/work/solaris8-sparc/pkgroot/opt/csw/lib/nspr/64/64/sparcv9': cannot overwrite directory gmake[1]: *** [post-merge-modulated] Error 1 gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/nspr/trunk' gmake: *** [merge-isa-sparcv9] Error 2 I think it's because it must be run only once per architecture, that's why I initially chose post-merge and not post-merge-modulated. Is that correct? Maciej From phil at bolthole.com Tue Nov 24 17:32:19 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 24 Nov 2009 08:32:19 -0800 Subject: [csw-maintainers] Replacing existing Solaris functionality by OpenCSW packages In-Reply-To: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> References: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> Message-ID: 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") From skayser at opencsw.org Tue Nov 24 17:36:22 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 24 Nov 2009 17:36:22 +0100 Subject: [csw-maintainers] General update of Perl to 5.10 In-Reply-To: <5C593CC9-E888-419F-A5F7-262215EE4561@opencsw.org> References: <5C593CC9-E888-419F-A5F7-262215EE4561@opencsw.org> Message-ID: <20091124163621.GQ1788@sebastiankayser.de> * Dagobert Michelsen wrote: > I start to encounter the first modules requiring Perl 5.10: > > > ==> Running Makefile.PL in work/build-isa-i386/Date-Manip-6.01 > >Perl v5.10.0 required--this is only v5.8.8, stopped at Makefile.PL > >line 3. > > However, Sebastian stated that there are some serious issues in the past > with 5.10. Should we wait some more ot has this already been settled? A former colleague of mine working with perl quite extensively pointed out those 5.10 problems (related to perl warning messages which were unable to narrow down the offending source code line). Just asked him. These problems are fixed in 5.10.1 and although he doesn't use 5.10.1 in his historically grown production environment many people from #dbix-class, #catalyst, and #moose already do. This is 2nd hand information, but doesn't sound too bad. Sebastian From dam at opencsw.org Tue Nov 24 17:38:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Nov 2009 17:38:45 +0100 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: Message-ID: <2654364D-F74C-4F13-BD30-0471BD74C9D5@opencsw.org> Hi Maciej, Am 24.11.2009 um 17:30 schrieb Maciej (Matchek) Blizinski: >> It is easier to use this: >> >> post-merge-modulated: >> gln -s $(ISA_DEFAULT64) $(PKGROOT)$(libdir)/64 >> @$(MAKECOOKIE) >> >> ISA_DEFAULT contains the default 32 bit ISA on this platform, >> ISA_DEFAULT64 contains the default 64 bit ISA on this platform. > > This fails: > > gln -s "sparcv9" > "/home/maciej/src/opencsw/pkg/nspr/trunk/work/solaris8-sparc/pkgroot/ > opt/csw/lib/nspr/64/64" > gln: `/home/maciej/src/opencsw/pkg/nspr/trunk/work/solaris8-sparc/ > pkgroot/opt/csw/lib/nspr/64/64/sparcv9': > cannot overwrite directory > gmake[1]: *** [post-merge-modulated] Error 1 > gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/nspr/trunk' > gmake: *** [merge-isa-sparcv9] Error 2 > > I think it's because it must be run only once per architecture, that's > why I initially chose post-merge and not post-merge-modulated. Is > that correct? Yes, correct, just replace the gln line and drop the -modulated. I want to get rid of the -modulated at some time but here it actually makes a difference. Maybe there is need for differentiation, I'll do some more thinking... Best regards -- Dago From phil at bolthole.com Tue Nov 24 17:50:36 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 24 Nov 2009 08:50:36 -0800 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: <2654364D-F74C-4F13-BD30-0471BD74C9D5@opencsw.org> References: <2654364D-F74C-4F13-BD30-0471BD74C9D5@opencsw.org> Message-ID: On Tue, Nov 24, 2009 at 8:38 AM, Dagobert Michelsen wrote: > > > Yes, correct, just replace the gln line and drop the -modulated. > I want to get rid of the -modulated at some time but here it > actually makes a difference. Maybe there is need for differentiation, > I'll do some more thinking... > btw, why "gln" not "ln" ?? (i'm presuming thats GNU ln, not "gar ln" :-) From maciej at opencsw.org Tue Nov 24 17:59:04 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 24 Nov 2009 16:59:04 +0000 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: <2654364D-F74C-4F13-BD30-0471BD74C9D5@opencsw.org> Message-ID: On Tue, Nov 24, 2009 at 4:50 PM, Philip Brown wrote: > btw, why "gln" not "ln" ?? Once upon a time ln didn't do what I wanted it to do, and gln did. It was related to the -f flag. I tend to prefer gln since. > (i'm presuming thats GNU ln, not "gar ln" :-) It's GNU ln, but did you know that GNU stands for GAR is Not Unix? ;-) From maciej at opencsw.org Wed Nov 25 11:43:11 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 25 Nov 2009 10:43:11 +0000 Subject: [csw-maintainers] Symlinks to shared libraries Message-ID: I just got a review of my NSPR build from a NSPR/NSS developer, Wan-Teh Chang. One of the comments was to stop creating a symlink to a shared library. By default, nspr creates bare *.so files. My build script renamed them to *.so.$(MINOR_VERSION) and created symlinks from *.so to *.so.$(MINOR_VERSION). > ls -l /opt/csw/lib/nspr/libnspr4.so* lrwxrwxrwx 1 root other 13 Nov 23 23:46 /opt/csw/lib/nspr/libnspr4.so -> libnspr4.so.8 -rwxr-xr-x 1 root bin 324344 Nov 23 23:02 /opt/csw/lib/nspr/libnspr4.so.8 Do we have any policy which requires creating symlinks? I'm afraid that shipping bare unversioned libraries is going to create problems during updates. Maciej From dam at opencsw.org Wed Nov 25 12:15:56 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 25 Nov 2009 12:15:56 +0100 Subject: [csw-maintainers] Symlinks to shared libraries In-Reply-To: References: Message-ID: <6695242C-A227-40E6-9F8C-3444A89723E0@opencsw.org> Hi Maciej, Am 25.11.2009 um 11:43 schrieb Maciej (Matchek) Blizinski: > I just got a review of my NSPR build from a NSPR/NSS developer, > Wan-Teh Chang. One of the comments was to stop creating a symlink to > a shared library. By default, nspr creates bare *.so files. My build > script renamed them to *.so.$(MINOR_VERSION) and created symlinks from > *.so to *.so.$(MINOR_VERSION). > >> ls -l /opt/csw/lib/nspr/libnspr4.so* > lrwxrwxrwx 1 root other 13 Nov 23 23:46 > /opt/csw/lib/nspr/libnspr4.so -> libnspr4.so.8 > -rwxr-xr-x 1 root bin 324344 Nov 23 23:02 > /opt/csw/lib/nspr/libnspr4.so.8 > > Do we have any policy which requires creating symlinks? I'm afraid > that shipping bare unversioned libraries is going to create problems > during updates. I don't think that we have an official "policy" on this as most libraries are well-behaved. One of the real troublemakers is libnet which was packaged unversioned and has been resisted to be updated until now. Best regards -- Dago From ihsan at opencsw.org Wed Nov 25 12:18:51 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 25 Nov 2009 12:18:51 +0100 Subject: [csw-maintainers] OpenCSW Winter Camp 2009, when/where? Feedback needed. In-Reply-To: <4B09ACE7.9040307@opencsw.org> References: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> <4AC51D40.7060007@opencsw.org> <4B09ACE7.9040307@opencsw.org> Message-ID: <4B0D129B.7030205@opencsw.org> Am 22.11.2009 22:28 Uhr, Sebastian Kayser schrieb: >>> before we head to Toronto next year in summer :D, i would like to kick off >>> this year's winter camp preparations for Munich. Two votes need your >>> input. >>> >>> - Which weekend can you participate? >>> http://doodle.com/p3rvwqkx542cu4rx >>> >>> - Which venue would you prefer (city/nature)? >>> http://doodle.com/xwnhvxp274i8b3iv >> Thanks to those who already voted, looking forward to seeing you (again) >> in a couple of months. Anyone else interested in coming? If so, please >> take part in the above polls so that we can plan accordingly (i will try >> to fix a date and venue by the end of next week). > > Sorry, it has taking me so long to pick this up again. Is the 22.01. - > 24.01. still a valid date for those who are interested in coming? If > there are no objections, I will go ahead and book the venue this Tuesday. I'm very sorry, but I can't attend at these dates. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Wed Nov 25 12:20:54 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 25 Nov 2009 12:20:54 +0100 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> Message-ID: <4B0D1316.5000704@opencsw.org> Am 8.11.2009 23:58 Uhr, Maciej (Matchek) Blizinski schrieb: >>> Sebastian mentioned someone who was interested in collaborating on the >>> MySQL package. I got us up to the point where we get something which >>> passes the smoke test: we can install the package and it doesn't blow >>> right after installation. That's a nice start, but it might still be >>> a long way to go. I think the main current issue is getting the tests >>> to pass. >> What do you mean with "it doesn't blow right after installation"? > Um, I meant "blow up". I meant that the package works after you > install it and start up the database. You could make default initialisation, but from my perspective, it's not really needed. It can be also dangerous with existing databases. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Wed Nov 25 12:43:10 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 25 Nov 2009 11:43:10 +0000 Subject: [csw-maintainers] Symlinks to shared libraries In-Reply-To: <6695242C-A227-40E6-9F8C-3444A89723E0@opencsw.org> References: <6695242C-A227-40E6-9F8C-3444A89723E0@opencsw.org> Message-ID: On Wed, Nov 25, 2009 at 11:15 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 25.11.2009 um 11:43 schrieb Maciej (Matchek) Blizinski: >> >> I just got a review of my NSPR build from a NSPR/NSS developer, >> Wan-Teh Chang. ?One of the comments was to stop creating a symlink to >> a shared library. ?By default, nspr creates bare *.so files. ?My build >> script renamed them to *.so.$(MINOR_VERSION) and created symlinks from >> *.so to *.so.$(MINOR_VERSION). >> >>> ls -l /opt/csw/lib/nspr/libnspr4.so* >> >> lrwxrwxrwx ? 1 root ? ? other ? ? ? ? 13 Nov 23 23:46 >> /opt/csw/lib/nspr/libnspr4.so -> libnspr4.so.8 >> -rwxr-xr-x ? 1 root ? ? bin ? ? ? 324344 Nov 23 23:02 >> /opt/csw/lib/nspr/libnspr4.so.8 >> >> Do we have any policy which requires creating symlinks? ?I'm afraid >> that shipping bare unversioned libraries is going to create problems >> during updates. > > I don't think that we have an official "policy" on this as most libraries > are well-behaved. One of the real troublemakers is libnet which was > packaged unversioned and has been resisted to be updated until now. Perhaps it makes sense to update the package using the same binary, but this time with a symlink. Then wait five or ten years (a blink of an eye in Solaris galactic time) and release the update. NSPR developer guidelines[1] say: """Downward Compatibility. Because many different applications, besides the mozilla client, use the NSPR API, the API must remain downward compatible across even major releases. This means that the behavior of an existing public API item in NSPR cannot change. Should you need to have a similar API, with some slightly different behavior or different function prototype, then suggest a new API with a different name.""" In theory, there should be no API changes. But I guess you know, that in theory, there's no difference between theory and practice. In practice, there is. ;-) Maciej [1] http://www.mozilla.org/projects/nspr/eng-process/contributors.html#GeneralGuidelines From james at opencsw.org Wed Nov 25 12:43:53 2009 From: james at opencsw.org (James Lee) Date: Wed, 25 Nov 2009 11:43:53 GMT Subject: [csw-maintainers] Symlinks to shared libraries In-Reply-To: References: Message-ID: <20091125.11435300.988074789@gyor.oxdrove.co.uk> On 25/11/09, 10:43:11, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] Symlinks to shared libraries: > I just got a review of my NSPR build from a NSPR/NSS developer, > Wan-Teh Chang. One of the comments was to stop creating a symlink to > a shared library. By default, nspr creates bare *.so files. My build > script renamed them to *.so.$(MINOR_VERSION) and created symlinks from > *.so to *.so.$(MINOR_VERSION). > > ls -l /opt/csw/lib/nspr/libnspr4.so* > lrwxrwxrwx 1 root other 13 Nov 23 23:46 > /opt/csw/lib/nspr/libnspr4.so -> libnspr4.so.8 > -rwxr-xr-x 1 root bin 324344 Nov 23 23:02 > /opt/csw/lib/nspr/libnspr4.so.8 > Do we have any policy which requires creating symlinks? It's not about CSW policy but how ld and ld.so.1 work and versioning. What's the SONAME? James. From maciej at opencsw.org Wed Nov 25 12:54:25 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 25 Nov 2009 11:54:25 +0000 Subject: [csw-maintainers] Symlinks to shared libraries In-Reply-To: <20091125.11435300.988074789@gyor.oxdrove.co.uk> References: <20091125.11435300.988074789@gyor.oxdrove.co.uk> Message-ID: On Wed, Nov 25, 2009 at 11:43 AM, James Lee wrote: > On 25/11/09, 10:43:11, Maciej "(Matchek)" Blizinski > wrote regarding [csw-maintainers] Symlinks to shared libraries: > >> I just got a review of my NSPR build from a NSPR/NSS developer, >> Wan-Teh Chang. ?One of the comments was to stop creating a symlink to >> a shared library. ?By default, nspr creates bare *.so files. ?My build >> script renamed them to *.so.$(MINOR_VERSION) and created symlinks from >> *.so to *.so.$(MINOR_VERSION). > >> ?> ls -l /opt/csw/lib/nspr/libnspr4.so* >> lrwxrwxrwx ? 1 root ? ? other ? ? ? ? 13 Nov 23 23:46 >> /opt/csw/lib/nspr/libnspr4.so -> libnspr4.so.8 >> -rwxr-xr-x ? 1 root ? ? bin ? ? ? 324344 Nov 23 23:02 >> /opt/csw/lib/nspr/libnspr4.so.8 > >> Do we have any policy which requires creating symlinks? > > It's not about CSW policy but how ld and ld.so.1 work and versioning. > What's the SONAME? $ /.SUNWnative/usr/sfw/bin/gobjdump -p work/solaris8-sparc/install-isa-sparcv8/opt/csw/lib/libnspr4.so.8 | grep SONAME SONAME libnspr4.so This means applications will be linked against libnspr4.so no matter which is the symlink and which is the regular file, right? Maciej From maciej at opencsw.org Wed Nov 25 13:21:38 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 25 Nov 2009 12:21:38 +0000 Subject: [csw-maintainers] Symlinks to shared libraries In-Reply-To: References: <20091125.11435300.988074789@gyor.oxdrove.co.uk> Message-ID: On Wed, Nov 25, 2009 at 11:54 AM, Maciej (Matchek) Blizinski wrote: > On Wed, Nov 25, 2009 at 11:43 AM, James Lee wrote: >> It's not about CSW policy but how ld and ld.so.1 work and versioning. >> What's the SONAME? > > $ /.SUNWnative/usr/sfw/bin/gobjdump -p > work/solaris8-sparc/install-isa-sparcv8/opt/csw/lib/libnspr4.so.8 ?| > grep SONAME > ?SONAME ? ? ?libnspr4.so > > This means applications will be linked against libnspr4.so no matter > which is the symlink and which is the regular file, right? Gentoo injects a custom SONAME via a gcc flag[1]: --- mozilla/nsprpub/configure.orig 2006-01-14 22:41:37.000000000 +0000 +++ mozilla/nsprpub/configure 2006-01-14 22:49:14.000000000 +0000 @@ -3893,7 +3893,7 @@ PR_MD_CSRCS=linux.c MKSHLIB='$(CC) $(DSO_LDOPTS) -o $@' DSO_CFLAGS=-fPIC - DSO_LDOPTS='-shared -Wl,-soname -Wl,$(notdir $@)' + DSO_LDOPTS='-shared -Wl,-soname -Wl,$(notdir $@).$(MOD_MINOR_VERSION)' _OPTIMIZE_FLAGS=-O2 _DEBUG_FLAGS="-g -fno-inline" # most people on linux use gcc/gdb, and that Can we do the same in Sun Studio? [1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/nspr/files/nspr-4.6.1-config-1.patch?rev=1.1&view=markup From skayser at opencsw.org Wed Nov 25 13:22:06 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 25 Nov 2009 13:22:06 +0100 Subject: [csw-maintainers] Released pkgs feed broken? Message-ID: <20091125122206.GS1788@sebastiankayser.de> Hi, I noticed that our IRC bot hasn't announced released packages for a while, although we have had quite a few released. Seems as if the released packages feed is broken. http://www.opencsw.org/feed/releasedpkgs.atom A manual download shows that it simply doesn't contain any items. Phil, would you mind having a look? Sebastian From dam at opencsw.org Wed Nov 25 13:28:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 25 Nov 2009 13:28:55 +0100 Subject: [csw-maintainers] Released pkgs feed broken? In-Reply-To: <20091125122206.GS1788@sebastiankayser.de> References: <20091125122206.GS1788@sebastiankayser.de> Message-ID: <8CAF018F-1D33-4E38-9F60-DA5FA6228F8E@opencsw.org> Hi Sebastian, Am 25.11.2009 um 13:22 schrieb Sebastian Kayser: > I noticed that our IRC bot hasn't announced released packages for a > while, although we have had quite a few released. Seems as if the > released packages feed is broken. > > http://www.opencsw.org/feed/releasedpkgs.atom > > A manual download shows that it simply doesn't contain any items. > Phil, > would you mind having a look? This was due to a changed master rsync directory layout, probably caused by Phils changed release process. This should be fixed now. Best regards -- Dago From james at opencsw.org Wed Nov 25 13:32:21 2009 From: james at opencsw.org (James Lee) Date: Wed, 25 Nov 2009 12:32:21 GMT Subject: [csw-maintainers] Symlinks to shared libraries In-Reply-To: References: <20091125.11435300.988074789@gyor.oxdrove.co.uk> Message-ID: <20091125.12322100.2618620288@gyor.oxdrove.co.uk> On 25/11/09, 11:54:25, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] Symlinks to shared libraries: > > It's not about CSW policy but how ld and ld.so.1 work and versioning. > > What's the SONAME? > $ /.SUNWnative/usr/sfw/bin/gobjdump -p > work/solaris8-sparc/install-isa-sparcv8/opt/csw/lib/libnspr4.so.8 | > grep SONAME > SONAME libnspr4.so > This means applications will be linked against libnspr4.so no matter > which is the symlink and which is the regular file, right? Correct. Thus file naming with the version is only for our convenience, the .so file will always be used and the fact it's a link is transparent to its use and of no interest to the developers. The developers are very sure of the future and are disregarding the standard method of protecting themselves against unknown eventualities. Changing the library name to handle versions makes changes difficult because the builds need to know, -lnsprwhat? It's handy you are in communication with the developers as you can call them twats. James. From phil at bolthole.com Wed Nov 25 18:22:08 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 25 Nov 2009 09:22:08 -0800 Subject: [csw-maintainers] new subversion package? Message-ID: hi folks, i vaguely recall someone was planning on working on a new subversion package release. Cant find the email any more though. Someone going to do this,and take it over? I vaguely recall they were waiting for our berkeleydb packages to stabilize? well.. they're stabilized... and I got a complaint about a bug in our existing subversion package. From phil at bolthole.com Wed Nov 25 18:25:10 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 25 Nov 2009 09:25:10 -0800 Subject: [csw-maintainers] Symlinks to shared libraries In-Reply-To: References: Message-ID: On Wed, Nov 25, 2009 at 2:43 AM, Maciej (Matchek) Blizinski wrote: > I just got a review of my NSPR build from a NSPR/NSS developer, > Wan-Teh Chang. ?One of the comments was to stop creating a symlink to > a shared library. ?By default, nspr creates bare *.so files. ?My build > script renamed them to *.so.$(MINOR_VERSION) and created symlinks from > *.so to *.so.$(MINOR_VERSION). > > ?> ls -l /opt/csw/lib/nspr/libnspr4.so* > lrwxrwxrwx ? 1 root ? ? other ? ? ? ? 13 Nov 23 23:46 > /opt/csw/lib/nspr/libnspr4.so -> libnspr4.so.8 > -rwxr-xr-x ? 1 root ? ? bin ? ? ? 324344 Nov 23 23:02 > /opt/csw/lib/nspr/libnspr4.so.8 > > Do we have any policy which requires creating symlinks? ?I'm afraid > that shipping bare unversioned libraries is going to create problems > during updates. > as James has pointed out, the core issue here is the SONAME. since the SONAME is unversioned, you may as well just stop messing around with the renaming/symlink. With other libraries, I'd be worried. However, since they have an EXPLICIT commitment to compatibility between versions (and if they ever broke it, people would scream bloody murder), I think it is ok in this specific situation. From phil at bolthole.com Wed Nov 25 18:26:08 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 25 Nov 2009 09:26:08 -0800 Subject: [csw-maintainers] Symlinks to shared libraries In-Reply-To: References: Message-ID: PS: they have explicit "versioning", in that they have "4" in -lnspr4. It is reasonable to infer that if they ever came out with an incompatible version, it would be nspr5. so, dont worry about it. From dam at opencsw.org Wed Nov 25 18:29:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 25 Nov 2009 18:29:17 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: References: Message-ID: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> Hi Phil, Am 25.11.2009 um 18:22 schrieb Philip Brown: > i vaguely recall someone was planning on working on a new subversion > package release. Cant find the email any more though. > Someone going to do this,and take it over? > > I vaguely recall they were waiting for our berkeleydb packages to > stabilize? well.. they're stabilized... and I got a complaint about a > bug in our existing subversion package. Rupert worked on this. Rupert, any light at the end of the tunnel? Best regards -- Dago From bwalton at opencsw.org Thu Nov 26 04:22:46 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 25 Nov 2009 22:22:46 -0500 Subject: [csw-maintainers] logwatch in testing/ Message-ID: <1259205604-sup-6305@ntdws12.chass.utoronto.ca> Hi All, I've placed a first attempt at updating logwatch (for the upcoming coreutils fun) in testing/. As I don't (and won't) use this package, I'd appreciate feedback from anyone that does. It's a large version delta and I'm moving files around to meet current standards. Feedback welcome. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Thu Nov 26 09:23:28 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 26 Nov 2009 08:23:28 +0000 Subject: [csw-maintainers] Symlinks to shared libraries In-Reply-To: References: Message-ID: On Wed, Nov 25, 2009 at 5:25 PM, Philip Brown wrote: > as James has pointed out, the core issue here is the SONAME. > > since the SONAME is unversioned, you may as well just stop messing > around with the renaming/symlink. I found the right compiler invocation to create the SONAME I wanted, but I couldn't make the arcane NSPR build system include the right flag in the appropriate place. There is a nice Debian patch I could cherrypick, but I've decided to give up on this and ship the library with the retarded official versioning. From hson at opencsw.org Thu Nov 26 14:38:27 2009 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 26 Nov 2009 14:38:27 +0100 Subject: [csw-maintainers] Problem with latest perl update Message-ID: <4B0E84D3.6030003@opencsw.org> I don't know if anyone else have seen this problem (and have a solution to it), but the latest perl update (installed 24th on build8s) seems to be have broken something, I can no longer package exiftool. First I thought it was something wrong with the new exiftool package, but even the one I released two weeks ago fails to package. ==> Running make install in work/solaris8-sparc/build-isa-sparcv8/Image-ExifTool-8.00 gmake[2]: Entering directory `/home/hson/mgar/pkg/exiftool/trunk/work/solaris8-sparc/build-isa-sparcv8/Image-ExifTool-8.00' Can't coerce array into hash at /opt/csw/share/perl/5.8.8/ExtUtils/Install.pm line 94. gmake[2]: *** [pure_vendor_install] Error 255 Anyone got a workaround/fix for this? From dam at opencsw.org Thu Nov 26 14:41:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 26 Nov 2009 14:41:22 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: <4B0E84D3.6030003@opencsw.org> References: <4B0E84D3.6030003@opencsw.org> Message-ID: <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> Hi Roger, Am 26.11.2009 um 14:38 schrieb Roger H?kansson: > I don't know if anyone else have seen this problem (and have a > solution to it), but the latest perl update (installed 24th on > build8s) seems to be have broken something, I can no longer package > exiftool. > > First I thought it was something wrong with the new exiftool > package, but even the one I released two weeks ago fails to package. > > ==> Running make install in work/solaris8-sparc/build-isa-sparcv8/ > Image-ExifTool-8.00 > gmake[2]: Entering directory `/home/hson/mgar/pkg/exiftool/trunk/ > work/solaris8-sparc/build-isa-sparcv8/Image-ExifTool-8.00' > Can't coerce array into hash at /opt/csw/share/perl/5.8.8/ExtUtils/ > Install.pm line 94. > gmake[2]: *** [pure_vendor_install] Error 255 > > Anyone got a workaround/fix for this? I am seeing the exact Problem for two packages. I guess this needs to be solved fast, so I'll have a look, cc'ing Peter. Best regards -- Dago From dam at opencsw.org Thu Nov 26 14:59:48 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 26 Nov 2009 14:59:48 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> Message-ID: <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> Hi, Am 26.11.2009 um 14:41 schrieb Dagobert Michelsen: > Am 26.11.2009 um 14:38 schrieb Roger H?kansson: >> I don't know if anyone else have seen this problem (and have a >> solution to it), but the latest perl update (installed 24th on >> build8s) seems to be have broken something, I can no longer package >> exiftool. >> >> First I thought it was something wrong with the new exiftool >> package, but even the one I released two weeks ago fails to package. >> >> ==> Running make install in work/solaris8-sparc/build-isa-sparcv8/ >> Image-ExifTool-8.00 >> gmake[2]: Entering directory `/home/hson/mgar/pkg/exiftool/trunk/ >> work/solaris8-sparc/build-isa-sparcv8/Image-ExifTool-8.00' >> Can't coerce array into hash at /opt/csw/share/perl/5.8.8/ExtUtils/ >> Install.pm line 94. >> gmake[2]: *** [pure_vendor_install] Error 255 >> >> Anyone got a workaround/fix for this? > > I am seeing the exact Problem for two packages. I guess this needs > to be > solved fast, so I'll have a look, cc'ing Peter. Ok, I hacked this so it works again: On line 94 from /opt/csw/share/perl/5.8.8/ExtUtils/Install.pm it must say my(%from_to) = @$from_to; instead of my(%from_to) = %$from_to; I changed this only on build8s, please verify that this works. Between the previous release and this one MakeMaker was updated to suite some requests. The one shipped with CSWperl is already the latest and should in general be compatible with Perl. Best regards -- Dago From hson at opencsw.org Thu Nov 26 18:05:54 2009 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 26 Nov 2009 18:05:54 +0100 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: <4B0EB572.2000703@opencsw.org> Dagobert Michelsen wrote: >> I am seeing the exact Problem for two packages. I guess this needs to be >> solved fast, so I'll have a look, cc'ing Peter. > > Ok, I hacked this so it works again: > > On line 94 from /opt/csw/share/perl/5.8.8/ExtUtils/Install.pm it must say > my(%from_to) = @$from_to; > instead of > my(%from_to) = %$from_to; > > I changed this only on build8s, please verify that this works. > > Between the previous release and this one MakeMaker was updated to suite > some > requests. The one shipped with CSWperl is already the latest and should > in general be compatible with Perl. My imagemagick package builds without a error now (exiftool still gives me an error, but a different one which I suspect is in gar and have nothing to do with the perl update) From dam at opencsw.org Thu Nov 26 18:10:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 26 Nov 2009 18:10:02 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: <4B0EB572.2000703@opencsw.org> References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> <4B0EB572.2000703@opencsw.org> Message-ID: Hi Roger, Am 26.11.2009 um 18:05 schrieb Roger H?kansson: > Dagobert Michelsen wrote: >>> I am seeing the exact Problem for two packages. I guess this needs >>> to be >>> solved fast, so I'll have a look, cc'ing Peter. >> Ok, I hacked this so it works again: >> On line 94 from /opt/csw/share/perl/5.8.8/ExtUtils/Install.pm it >> must say >> my(%from_to) = @$from_to; >> instead of >> my(%from_to) = %$from_to; >> I changed this only on build8s, please verify that this works. >> Between the previous release and this one MakeMaker was updated to >> suite some >> requests. The one shipped with CSWperl is already the latest and >> should >> in general be compatible with Perl. > > My imagemagick package builds without a error now (exiftool still > gives me an error, but a different one which I suspect is in gar and > have nothing to do with the perl update) Good to hear. If there is a problem with GAR just let me know also. Best regards -- Dago From dam at opencsw.org Fri Nov 27 10:57:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 27 Nov 2009 10:57:31 +0100 Subject: [csw-maintainers] New in testing/: Zebra Message-ID: <1405AC81-4D98-4BEC-B9EB-D43D0795B3D3@opencsw.org> Hi, I just packaged up Zebra in testing/: zebra-0.95a,REV=2009.11.27-SunOS5.8-sparc-CSW.pkg.gz zebra-0.95a,REV=2009.11.27-SunOS5.8-i386-CSW.pkg.gz As I don't use it myself it would be nice if some network expert would try it. Best regards -- Dago From dam at opencsw.org Fri Nov 27 14:29:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 27 Nov 2009 14:29:31 +0100 Subject: [csw-maintainers] Major cleanup of testing/ Message-ID: Hi, I have now a script active that removes files from testing/ after they have been released and resync through the main mirror back to the farm. The current deletion rules go like this: (1) If the package has the same name and is identical to a released package it is deleted from testing/ (2) If the package has the same name, but has a different contents the files are listed it should IMHO be deleted. (3) If the package in testing/ has a REV-stamp older than the released package it should IMHO be deleted. (4) If the package is testing/ doesn't have a REV-stamp it should IMHO be deleted. At the moment only packages according to (1) have been deleted as they exist by definition also in the repository. If you want to keep stuff or be informed on conditions (2)-(4) speak up now or they will be deleted soon. You'll find a report with the specific files attached. Best regards -- Dago Newer PKG released. Testing: ap2_prefork-2.2.12,REV=2009.07.31- SunOS5.8-i386-CSW.pkg.gz Released: ap2_prefork-2.2.13,REV=2009.08.22- SunOS5.8-i386-CSW.pkg.gz Newer PKG released. Testing: ap2_prefork-2.2.12,REV=2009.07.31- SunOS5.8-sparc-CSW.pkg.gz Released: ap2_prefork-2.2.13,REV=2009.08.22- SunOS5.8-i386-CSW.pkg.gz Newer PKG released. Testing: ap2_prefork-2.2.13,REV=2009.08.10- SunOS5.8-i386-CSW.pkg.gz Released: ap2_prefork-2.2.13,REV=2009.08.22- SunOS5.8-i386-CSW.pkg.gz Newer PKG released. Testing: ap2_prefork-2.2.13,REV=2009.08.10- SunOS5.8-sparc-CSW.pkg.gz Released: ap2_prefork-2.2.13,REV=2009.08.22- SunOS5.8-i386-CSW.pkg.gz Newer PKG released. Testing: ap2_suexec-2.2.12,REV=2009.07.31-SunOS5.8- i386-CSW.pkg.gz Released: ap2_suexec-2.2.13,REV=2009.08.22- SunOS5.8-i386-CSW.pkg.gz Newer PKG released. Testing: ap2_suexec-2.2.12,REV=2009.07.31-SunOS5.8- sparc-CSW.pkg.gz Released: ap2_suexec-2.2.13,REV=2009.08.22- SunOS5.8-i386-CSW.pkg.gz Newer PKG released. Testing: ap2_suexec-2.2.13,REV=2009.08.10-SunOS5.8- i386-CSW.pkg.gz Released: ap2_suexec-2.2.13,REV=2009.08.22- SunOS5.8-i386-CSW.pkg.gz Newer PKG released. Testing: ap2_suexec-2.2.13,REV=2009.08.10-SunOS5.8- sparc-CSW.pkg.gz Released: ap2_suexec-2.2.13,REV=2009.08.22- SunOS5.8-i386-CSW.pkg.gz Newer PKG released. Testing: ap2_worker-2.2.12,REV=2009.07.31-SunOS5.8- i386-CSW.pkg.gz Released: ap2_worker-2.2.13,REV=2009.08.22- SunOS5.8-sparc-CSW.pkg.gz Newer PKG released. Testing: ap2_worker-2.2.12,REV=2009.07.31-SunOS5.8- sparc-CSW.pkg.gz Released: ap2_worker-2.2.13,REV=2009.08.22- SunOS5.8-sparc-CSW.pkg.gz Newer PKG released. Testing: ap2_worker-2.2.12,REV=2009.08.10-SunOS5.8- i386-CSW.pkg.gz Released: ap2_worker-2.2.13,REV=2009.08.22- SunOS5.8-sparc-CSW.pkg.gz Newer PKG released. Testing: ap2_worker-2.2.12,REV=2009.08.10-SunOS5.8- sparc-CSW.pkg.gz Released: ap2_worker-2.2.13,REV=2009.08.22- SunOS5.8-sparc-CSW.pkg.gz Newer PKG released. Testing: apache2-2.2.12,REV=2009.07.31-SunOS5.8- all-CSW.pkg.gz Released: apache2-2.2.13,REV=2009.08.22-SunOS5.8- all-CSW.pkg.gz Newer PKG released. Testing: apache2_devel-2.2.12,REV=2009.07.31- SunOS5.8-i386-CSW.pkg.gz Released: apache2_devel-2.2.13,REV=2009.08.22- SunOS5.8-i386-CSW.pkg.gz Newer PKG released. Testing: apache2_devel-2.2.12,REV=2009.07.31- SunOS5.8-sparc-CSW.pkg.gz Released: apache2_devel-2.2.13,REV=2009.08.22- SunOS5.8-i386-CSW.pkg.gz Newer PKG released. Testing: apache2_devel-2.2.13,REV=2009.08.10- SunOS5.8-i386-CSW.pkg.gz Released: apache2_devel-2.2.13,REV=2009.08.22- SunOS5.8-i386-CSW.pkg.gz Newer PKG released. Testing: apache2_devel-2.2.13,REV=2009.08.10- SunOS5.8-sparc-CSW.pkg.gz Released: apache2_devel-2.2.13,REV=2009.08.22- SunOS5.8-i386-CSW.pkg.gz Newer PKG released. Testing: apache2_manual-2.2.12,REV=2009.07.31- SunOS5.8-all-CSW.pkg.gz Released: apache2_manual-2.2.13,REV=2009.08.22- SunOS5.8-all-CSW.pkg.gz Newer PKG released. Testing: apache2c-2.2.12,REV=2009.07.31-SunOS5.8- i386-CSW.pkg.gz Released: apache2c-2.2.13,REV=2009.08.22-SunOS5.8- sparc-CSW.pkg.gz Newer PKG released. Testing: apache2c-2.2.12,REV=2009.07.31-SunOS5.8- sparc-CSW.pkg.gz Released: apache2c-2.2.13,REV=2009.08.22-SunOS5.8- sparc-CSW.pkg.gz Newer PKG released. Testing: apache2c-2.2.13,REV=2009.08.10-SunOS5.8- i386-CSW.pkg.gz Released: apache2c-2.2.13,REV=2009.08.22-SunOS5.8- sparc-CSW.pkg.gz Newer PKG released. Testing: apache2c-2.2.13,REV=2009.08.10-SunOS5.8- sparc-CSW.pkg.gz Released: apache2c-2.2.13,REV=2009.08.22-SunOS5.8- sparc-CSW.pkg.gz Newer PKG released. Testing: apache2rt-2.2.12,REV=2009.07.31-SunOS5.8- i386-CSW.pkg.gz Released: apache2rt-2.2.13,REV=2009.08.22-SunOS5.8- i386-CSW.pkg.gz Newer PKG released. Testing: apache2rt-2.2.12,REV=2009.07.31-SunOS5.8- sparc-CSW.pkg.gz Released: apache2rt-2.2.13,REV=2009.08.22-SunOS5.8- i386-CSW.pkg.gz Newer PKG released. Testing: apache2rt-2.2.13,REV=2009.08.10-SunOS5.8- i386-CSW.pkg.gz Released: apache2rt-2.2.13,REV=2009.08.22-SunOS5.8- i386-CSW.pkg.gz Newer PKG released. Testing: apache2rt-2.2.13,REV=2009.08.10-SunOS5.8- sparc-CSW.pkg.gz Released: apache2rt-2.2.13,REV=2009.08.22-SunOS5.8- i386-CSW.pkg.gz Contents differs: axel-2.4,REV=2009.11.23-SunOS5.8-i386- CSW.pkg.gz Contents differs: axel-2.4,REV=2009.11.23-SunOS5.8-sparc- CSW.pkg.gz Newer PKG released. Testing: cdrtools-2.01.01a59,REV=2009.05.15- SunOS5.8-sparc-CSW.pkg.gz Released: cdrtools-2.01.01a59,REV=2009.05.29- SunOS5.8-sparc-CSW.pkg.gz Newer PKG released. Testing: denyhosts-2.6,REV=2009.11.03-SunOS5.8-all- CSW.pkg.gz Released: denyhosts-2.6,REV=2009.11.17-SunOS5.8- all-CSW.pkg.gz No REV in pkgname: djbdns-1.05-SunOS5.8-i386-CSW.pkg.gz No REV in pkgname: djbdns-1.05-SunOS5.8-sparc-CSW.pkg.gz Newer PKG released. Testing: kawa-1.9.1,REV=2009.04.09-SunOS5.8-i386- CSW.pkg.gz Released: kawa-1.9.1,REV=2009.04.26-SunOS5.8-sparc- CSW.pkg.gz Newer PKG released. Testing: kawa-1.9.1,REV=2009.04.10-SunOS5.8-i386- CSW.pkg.gz Released: kawa-1.9.1,REV=2009.04.26-SunOS5.8-sparc- CSW.pkg.gz Newer PKG released. Testing: kawa-1.9.1,REV=2009.04.10-SunOS5.8-sparc- CSW.pkg.gz Released: kawa-1.9.1,REV=2009.04.26-SunOS5.8-sparc- CSW.pkg.gz No REV in pkgname: libtalloc.so.1.sparc Contents differs: maven2-2.0.10,REV=2009.04.09-SunOS5.8- all-CSW.pkg.gz Newer PKG released. Testing: mercurial-1.3.1,REV=2009.10.03-SunOS5.8- i386-CSW.pkg.gz Released: mercurial-1.3.1,REV=2009.10.05-SunOS5.8- i386-CSW.pkg.gz Contents differs: mercurial-1.3.1,REV=2009.10.03-SunOS5.8- sparc-CSW.pkg.gz Newer PKG released. Testing: mercurial-1.3.1,REV=2009.10.03-SunOS5.8- sparc-CSW.pkg.gz Released: mercurial-1.3.1,REV=2009.10.05-SunOS5.8- i386-CSW.pkg.gz Newer PKG released. Testing: puppet-0.25.0,REV=2009.09.21-SunOS5.9-all- CSW.pkg.gz Released: puppet-0.25.1,REV=2009.11.16-SunOS5.9- all-CSW.pkg.gz Newer PKG released. Testing: pxupgrade-1.47,REV=2009.05.15-SunOS5.8- sparc-CSW.pkg.gz Released: pxupgrade-1.47,REV=2009.05.29-SunOS5.8- sparc-CSW.pkg.gz No REV in pkgname: samba.extralibs.sparc.tar No REV in pkgname: samba_binary_test-3.2.4-SunOS5.8-i386- CSW.pkg.gz No REV in pkgname: samba_binary_test-3.2.4-SunOS5.8-sparc- CSW.pkg.gz Newer PKG released. Testing: sccs-1.00.04,REV=2009.05.15-SunOS5.8- sparc-CSW.pkg.gz Released: sccs-1.00.04,REV=2009.05.29-SunOS5.8- sparc-CSW.pkg.gz Newer PKG released. Testing: schilybase-1.01,REV=2009.05.15-SunOS5.8- sparc-CSW.pkg.gz Released: schilybase-1.01,REV=2009.05.29-SunOS5.8- sparc-CSW.pkg.gz Newer PKG released. Testing: schilyutils-1.02,REV=2009.05.15-SunOS5.8- sparc-CSW.pkg.gz Released: schilyutils-1.02,REV=2009.05.29-SunOS5.8- sparc-CSW.pkg.gz Newer PKG released. Testing: smake-1.2a43,REV=2009.05.15-SunOS5.8- sparc-CSW.pkg.gz Released: smake-1.2a43,REV=2009.05.29-SunOS5.8- sparc-CSW.pkg.gz Newer PKG released. Testing: star-1.5,REV=2009.05.15-SunOS5.8-sparc- CSW.pkg.gz Released: star-1.5,REV=2009.05.29-SunOS5.8-sparc- CSW.pkg.gz No REV in pkgname: ucspi_tcp-0.88-SunOS5.8-i386-CSW.pkg.gz No REV in pkgname: ucspi_tcp-0.88-SunOS5.8-sparc-CSW.pkg.gz No REV in pkgname: update_xml_pkgs.sh No REV in pkgname: usepackage-1.8-SunOS5.8-i386-CSW.pkg.gz No REV in pkgname: usepackage-1.8-SunOS5.8-sparc-CSW.pkg.gz Newer PKG released. Testing: ved-1.7a07,REV=2009.05.15-SunOS5.8-sparc- CSW.pkg.gz Released: ved-1.7a07,REV=2009.05.29-SunOS5.8-sparc- CSW.pkg.gz From hson at opencsw.org Fri Nov 27 14:45:20 2009 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 27 Nov 2009 14:45:20 +0100 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> <4B0EB572.2000703@opencsw.org> Message-ID: <4B0FD7F0.8020309@opencsw.org> >> My imagemagick package builds without a error now (exiftool still >> gives me an error, but a different one which I suspect is in gar and >> have nothing to do with the perl update) > > Good to hear. If there is a problem with GAR just let me know also. The problem is that pkgcheck fails with the following error Examining 'depend' file P CSWcommon common - common files and dirs for CSW packages P CSWpmiocompress pm_iocompress - A Perl interface to allow reading and writing of compressed data P CSWcommon common - common files and dirs for CSW packages ERROR: CSWexiftool has double depends gmake: *** [pkgcheck] Error 2 In my Makefile I have "REQUIRED_PKGS += CSWperl CSWpmiocompress" and I don't have a depend file (i.e use csw_dyndepend.gspec). If I remove REQUIRED_PKGS totally, pkgcheck doesn't fail since CSWcommon is only found once in the depend file, but regardless of what package I have in REQUIRED_PKGS when pkgcheck is run, there is two occurances of CSWcommon in the generated depend file. From bonivart at opencsw.org Fri Nov 27 15:10:29 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 27 Nov 2009 15:10:29 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: <4B0FD7F0.8020309@opencsw.org> References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> <4B0EB572.2000703@opencsw.org> <4B0FD7F0.8020309@opencsw.org> Message-ID: <625385e30911270610oec0ef7ajca4498aba03710ca@mail.gmail.com> On Fri, Nov 27, 2009 at 2:45 PM, Roger H?kansson wrote: > The problem is that pkgcheck fails with the following error > > Examining 'depend' file > P CSWcommon common - common files and dirs for CSW packages > P CSWpmiocompress pm_iocompress - A Perl interface to allow reading and > writing of compressed data > P CSWcommon common - common files and dirs for CSW packages > ERROR: CSWexiftool has double depends > gmake: *** [pkgcheck] Error 2 If it's a cpan-module you're building, try not listing CSWperl either since that and CSWcommon should be added automatically. -- /peter From maciej at opencsw.org Fri Nov 27 15:25:27 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 27 Nov 2009 14:25:27 +0000 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: <4B0FD7F0.8020309@opencsw.org> References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> <4B0EB572.2000703@opencsw.org> <4B0FD7F0.8020309@opencsw.org> Message-ID: On Fri, Nov 27, 2009 at 1:45 PM, Roger H?kansson wrote: >>> My imagemagick package builds without a error now (exiftool still gives >>> me an error, but a different one which I suspect is in gar and have nothing >>> to do with the perl update) >> >> Good to hear. If there is a problem with GAR just let me know also. > > The problem is that pkgcheck fails with the following error > > Examining 'depend' file > P CSWcommon common - common files and dirs for CSW packages > P CSWpmiocompress pm_iocompress - A Perl interface to allow reading and > writing of compressed data > P CSWcommon common - common files and dirs for CSW packages > ERROR: CSWexiftool has double depends > gmake: *** [pkgcheck] Error 2 Yey, my test works! If not for it, you'd be stopped later on by the release manager. From dam at opencsw.org Fri Nov 27 15:28:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 27 Nov 2009 15:28:45 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem with latest perl update In-Reply-To: <4B0FD7F0.8020309@opencsw.org> References: <4B0E84D3.6030003@opencsw.org> <75CAB7E4-893D-463D-8CF8-FBD9CBB837A4@opencsw.org> <9BA12F40-F5FF-4F07-A0DD-A2E1747D0322@opencsw.org> <4B0EB572.2000703@opencsw.org> <4B0FD7F0.8020309@opencsw.org> Message-ID: <53B771A3-81D6-4791-8977-9B53E0783BBF@opencsw.org> Hi Roger, Am 27.11.2009 um 14:45 schrieb Roger H?kansson: >>> My imagemagick package builds without a error now (exiftool still >>> gives me an error, but a different one which I suspect is in gar >>> and have nothing to do with the perl update) >> Good to hear. If there is a problem with GAR just let me know also. > > The problem is that pkgcheck fails with the following error > > Examining 'depend' file > P CSWcommon common - common files and dirs for CSW packages > P CSWpmiocompress pm_iocompress - A Perl interface to allow reading > and > writing of compressed data > P CSWcommon common - common files and dirs for CSW packages > ERROR: CSWexiftool has double depends > gmake: *** [pkgcheck] Error 2 > > In my Makefile I have "REQUIRED_PKGS += CSWperl CSWpmiocompress" and I > don't have a depend file (i.e use csw_dyndepend.gspec). > If I remove REQUIRED_PKGS totally, pkgcheck doesn't fail since > CSWcommon > is only found once in the depend file, but regardless of what > package I > have in REQUIRED_PKGS when pkgcheck is run, there is two occurances of > CSWcommon in the generated depend file. You are using a static gspec. This is generally possible, but GAR has been tuned to be of easiest use for dynamic gspec files: This means that the information which resided in CSWexiftool.gspec is now generated dynamically from the Makefile. For you this is only ARCHALL = 1 as the package- and catalogname are already ok with the default. I change the Makefile to dynamic gspec for you in r7481. However, the install-section doesn't seem to install anything, so you have to look into that at exiftool. Let me know if I can be of further assistance. Best regards -- Dago From rupert at opencsw.org Sat Nov 28 01:56:03 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 28 Nov 2009 01:56:03 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> Message-ID: <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> its in testing, but we did not test a real life test yet, and also got no feedback yet. should we put to productive anyway? rupert. On Wed, Nov 25, 2009 at 18:29, Dagobert Michelsen wrote: > Hi Phil, > > Am 25.11.2009 um 18:22 schrieb Philip Brown: > > i vaguely recall someone was planning on working on a new subversion >> package release. Cant find the email any more though. >> Someone going to do this,and take it over? >> >> I vaguely recall they were waiting for our berkeleydb packages to >> stabilize? well.. they're stabilized... and I got a complaint about a >> bug in our existing subversion package. >> > > Rupert worked on this. > > Rupert, any light at the end of the tunnel? > > > Best regards > > -- Dago > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Nov 28 02:20:14 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 27 Nov 2009 20:20:14 -0500 Subject: [csw-maintainers] package updates for gnulink support Message-ID: <1259370836-sup-9125@ntdws12.chass.utoronto.ca> Hi All, Would those of you responsible for the following packages please reroll them so that they provide their own gnulinks? (eg: /opt/csw/gnu/patch -> /opt/csw/bin/gpatch). CSWbinutils CSWbison CSWdiffutils CSWfindutils CSWgawk CSWggetopt CSWggettext CSWggettextrt CSWggrep CSWgm4 CSWgmake CSWgpatch CSWgsed CSWgtar CSWgwhois If it's appropriate, I can file a packaging bug against each of these to track the progress...? I've re-factored the GAR recipe for CSWgnulinks so that I can drop links from it easily, package by package. If you let me know when you've updated your package, I'll make a gnulinks update to coincide with its release. This work is part of what I'm doing with the coreutils[1] package, which is coming along quite nicely. Thanks -Ben [1] coreutils will provide its own gnulinks too. When the dust settles, there shouldn't be dangling symlinks in /opt/csw/gnu due to packages that aren't installed. -- 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 bonivart at opencsw.org Sat Nov 28 12:28:22 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 28 Nov 2009 12:28:22 +0100 Subject: [csw-maintainers] new subversion package? In-Reply-To: <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> Message-ID: <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> On Sat, Nov 28, 2009 at 1:56 AM, rupert THURNER wrote: > its in testing, but we did not test a real life test yet, and also got no > feedback yet. should we put to productive anyway? I tested 1.6.6 from testing and it fails due to ldap 2.4 also from testing. $ svn ld.so.1: svn: fatal: libldap-2.3.so.0: open failed: No such file or directory Killed If used with ldap 2.3 from current it seems to work. -- /peter From maciej at opencsw.org Sat Nov 28 13:50:23 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 28 Nov 2009 12:50:23 +0000 Subject: [csw-maintainers] new subversion package? In-Reply-To: <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> References: <924E9B0F-E117-4193-B1EF-1AAA6D461C48@opencsw.org> <6af4270911271656jdb9a923ye0b45d9ae345b3ee@mail.gmail.com> <625385e30911280328j4ecdbdbbjff1458607387a6ea@mail.gmail.com> Message-ID: On Sat, Nov 28, 2009 at 11:28 AM, Peter Bonivart wrote: > On Sat, Nov 28, 2009 at 1:56 AM, rupert THURNER wrote: >> its in testing, but we did not test a real life test yet, and also got no >> feedback yet. should we put to productive anyway? > > I tested 1.6.6 from testing and it fails due to ldap 2.4 also from testing. > > $ svn > ld.so.1: svn: fatal: libldap-2.3.so.0: open failed: No such file or directory > Killed > > If used with ldap 2.3 from current it seems to work. Looks like the current openldap package doesn't provide the old shared library. By the way, I once heard that 'some people use testing/ for their systems'. If this is true, they don't use subversion, otherwise they'd complain or stop using testing/ for full updates. From dam at opencsw.org Sat Nov 28 14:01:04 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 28 Nov 2009 14:01:04 +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> Message-ID: <25F064BF-4C8A-4AA9-836A-E2B6230D2992@opencsw.org> Hi Maciej, Am 28.11.2009 um 13:50 schrieb Maciej (Matchek) Blizinski: > On Sat, Nov 28, 2009 at 11:28 AM, Peter Bonivart > wrote: >> On Sat, Nov 28, 2009 at 1:56 AM, rupert THURNER >> wrote: >>> its in testing, but we did not test a real life test yet, and also >>> got no >>> feedback yet. should we put to productive anyway? >> >> I tested 1.6.6 from testing and it fails due to ldap 2.4 also from >> testing. >> >> $ svn >> ld.so.1: svn: fatal: libldap-2.3.so.0: open failed: No such file or >> directory >> Killed >> >> If used with ldap 2.3 from current it seems to work. > > Looks like the current openldap package doesn't provide the old > shared library. > > By the way, I once heard that 'some people use testing/ for their > systems'. If this is true, they don't use subversion, otherwise they'd > complain or stop using testing/ for full updates. I am already working on a version-modulated OpenLDAP package including the previous shared version. In the meantime I removed the broken OpenLDAP package. Best regards -- Dago From maciej at opencsw.org Sat Nov 28 14:31:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 28 Nov 2009 13:31:39 +0000 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: References: <4B06BED1.6040206@cognigencorp.com> <4B06CE04.2060408@cognigencorp.com> Message-ID: On Mon, Nov 23, 2009 at 5:51 PM, Philip Brown wrote: > On Sat, Nov 21, 2009 at 1:59 AM, Dagobert Michelsen wrote: >> >> And, yes, using GAR is the best practice for this. With the sabbatical >> of Mike we have another excellent example why it is a good idea to have >> a central repository with standardized build recipes. It allowed >> Maciej to take over sudo in no time. >> > > bad example :-) I'm not sure what makes you smile. If you want precise language, I was able to fix a bug in no time, and start maintaining my own company-internal version of the package. As far as taking over is concerned, the process has gone over my fuss-making quota. The failure modes you've given involve local symlink alterations while failure modes I've pointed out involve plain CSW package updates. If my new package and the explanation I've given isn't enough, it's too bad. I'm tired of debating the topic in private. Maciej From dam at opencsw.org Sat Nov 28 16:19:46 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 28 Nov 2009 16:19:46 +0100 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: References: <4B06BED1.6040206@cognigencorp.com> <4B06CE04.2060408@cognigencorp.com> Message-ID: <251CF571-F7B8-44FF-9231-123227290D02@opencsw.org> Hi, Am 28.11.2009 um 14:31 schrieb Maciej (Matchek) Blizinski: > On Mon, Nov 23, 2009 at 5:51 PM, Philip Brown > wrote: >> On Sat, Nov 21, 2009 at 1:59 AM, Dagobert Michelsen >> wrote: >>> >>> And, yes, using GAR is the best practice for this. With the >>> sabbatical >>> of Mike we have another excellent example why it is a good idea to >>> have >>> a central repository with standardized build recipes. It allowed >>> Maciej to take over sudo in no time. >>> >> >> bad example :-) > > I'm not sure what makes you smile. If you want precise language, I > was able to fix a bug in no time, and start maintaining my own > company-internal version of the package. As far as taking over is > concerned, the process has gone over my fuss-making quota. > > The failure modes you've given involve local symlink alterations while > failure modes I've pointed out involve plain CSW package updates. If > my new package and the explanation I've given isn't enough, it's too > bad. I'm tired of debating the topic in private. Hugh? What's going on? Why is the updated sudo not released? Best regards -- Dago From ihsan at opencsw.org Sun Nov 29 12:38:51 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 29 Nov 2009 12:38:51 +0100 Subject: [csw-maintainers] delays on the mail server Message-ID: <4B125D4B.1020802@opencsw.org> Hello, Due some troubles with Spamassassin's bayes database there have been delays with the e-mail delivery during the last 12 hours. I was not able to fix the bayes databases and I have to train it again. This might cause that spam might not be detected as good as before for the next few days. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From james at opencsw.org Sun Nov 29 13:01:16 2009 From: james at opencsw.org (James Lee) Date: Sun, 29 Nov 2009 12:01:16 GMT Subject: [csw-maintainers] delays on the mail server In-Reply-To: <4B125D4B.1020802@opencsw.org> References: <4B125D4B.1020802@opencsw.org> Message-ID: <20091129.12011600.2849215160@gyor.oxdrove.co.uk> On 29/11/09, 11:38:51, Ihsan Dogan wrote regarding [csw-maintainers] delays on the mail server: > Due some troubles with Spamassassin's bayes database there have been > delays with the e-mail delivery during the last 12 hours. Do you use SQL to store the SA data? It works well for me. James. From ihsan at opencsw.org Sun Nov 29 13:12:31 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 29 Nov 2009 13:12:31 +0100 Subject: [csw-maintainers] delays on the mail server In-Reply-To: <20091129.12011600.2849215160@gyor.oxdrove.co.uk> References: <4B125D4B.1020802@opencsw.org> <20091129.12011600.2849215160@gyor.oxdrove.co.uk> Message-ID: <4B12652F.9000307@opencsw.org> Am 29.11.2009 13:01 Uhr, James Lee schrieb: >> Due some troubles with Spamassassin's bayes database there have been >> delays with the e-mail delivery during the last 12 hours. > Do you use SQL to store the SA data? It works well for me. I do, but for some obscure reason Spamassassin started to work extremely slow. I've decided to reduce bayes_expiry_max_db_size to 5000000. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From james at opencsw.org Sun Nov 29 13:35:45 2009 From: james at opencsw.org (James Lee) Date: Sun, 29 Nov 2009 12:35:45 GMT Subject: [csw-maintainers] delays on the mail server In-Reply-To: <4B12652F.9000307@opencsw.org> References: <4B125D4B.1020802@opencsw.org> <20091129.12011600.2849215160@gyor.oxdrove.co.uk> <4B12652F.9000307@opencsw.org> Message-ID: <20091129.12354500.1729877317@gyor.oxdrove.co.uk> On 29/11/09, 12:12:31, Ihsan Dogan wrote regarding Re: [csw-maintainers] delays on the mail server: > >> Due some troubles with Spamassassin's bayes database there have been > >> delays with the e-mail delivery during the last 12 hours. > > Do you use SQL to store the SA data? It works well for me. > I do, but for some obscure reason Spamassassin started to work extremely > slow. I've decided to reduce bayes_expiry_max_db_size to 5000000. That's still a lot of words, I keep the default of 150,000. (I use personalised bayes lists so I end up with a many sets in total). Given most people's vocabulary is in the 1,000s I think all a large list does is store words it is unlikely to encounter again which is contrary to the purpose of the storage. Expire? I set: bayes_auto_expire 0 and batch expire nightly /opt/csw/bin/sa-learn --force-expire -u ${name} James. From ja at opencsw.org Sat Nov 28 21:47:14 2009 From: ja at opencsw.org (Juergen Arndt) Date: Sat, 28 Nov 2009 21:47:14 +0100 Subject: [csw-maintainers] Munin 1.4 in testing Message-ID: Hi all, I put munin packages for the new version 1.4 into testing. Because munin master and munin node now have some files in common, I created an additional package CSWmunincommon. The packages are now: CSWmunincommon CSWmuninmaster (depends on CSWmunincommon) CSWmuninnode (depends on CSWmunincommon) Feedback is welcome. Juergen -- Juergen Arndt From phil at bolthole.com Mon Nov 30 18:45:04 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 30 Nov 2009 09:45:04 -0800 Subject: [csw-maintainers] Major cleanup of testing/ In-Reply-To: References: Message-ID: 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. From phil at bolthole.com Mon Nov 30 18:47:39 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 30 Nov 2009 09:47:39 -0800 Subject: [csw-maintainers] new subversion package? In-Reply-To: <25F064BF-4C8A-4AA9-836A-E2B6230D2992@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> Message-ID: 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? From phil at bolthole.com Mon Nov 30 18:49:24 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 30 Nov 2009 09:49:24 -0800 Subject: [csw-maintainers] package updates for gnulink support In-Reply-To: <1259370836-sup-9125@ntdws12.chass.utoronto.ca> References: <1259370836-sup-9125@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 27, 2009 at 5:20 PM, Ben Walton wrote: > > Hi All, > > Would those of you responsible for the following packages please > reroll them so that they provide their own gnulinks? (eg: > /opt/csw/gnu/patch -> /opt/csw/bin/gpatch). > > [list snipped] Any that are "mine", people should feel free to take over. > > If it's appropriate, I can file a packaging bug against each of these > to track the progress...? > Might be nicer to do an informal "nudge" of individual people first. Remember that bugs get copied to our bugs list, so no need to spam that needlessly. > I've re-factored the GAR recipe for CSWgnulinks so that I can drop > links from it easily, package by package. ?If you let me know when > you've updated your package, I'll make a gnulinks update to coincide > with its release. > very nice! From phil at bolthole.com Mon Nov 30 19:01:01 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 30 Nov 2009 10:01:01 -0800 Subject: [csw-maintainers] (now about sudo) Message-ID: On Sat, Nov 28, 2009 at 7:19 AM, Dagobert Michelsen wrote: > > > ... What's going on? Why is the updated sudo not released? > Hmm. Maciej and I had been having a technical discussion over sudo, trying to avoid potential failure cases. I thought we had a very useful discussion. 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...? From dam at opencsw.org Mon Nov 2 14:09:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Nov 2009 14:09:28 +0100 Subject: [csw-maintainers] Update of libevent and memcached Message-ID: Hi Rupert, hi Ben, I would need an updated libevent and memcached and I noticed you already did most of the work :-) I took the liberty of adding the legacy lib to the recipe of libevent and 64 bit to it and put it in testing/. Feel free to rebuild and release libevent. Next thing I need is memcached. It needs stdbool and stdint which I added from gnulib. However, the header files end up in lib/ and are not added to the include path. Ben, would you please enlighten me what is going wrong here? Additionally, I found these excellent Blog posts from Trond Norbye: http://blogs.sun.com/trond/category/Memcached regarding memcached on Solaris. Nice, but only starting from OpenSolaris. I wonder if we can get the manifest and stuff for our package. Best regards -- Dago From maciej at opencsw.org Mon Nov 2 15:05:26 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 2 Nov 2009 14:05:26 +0000 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: On Tue, Oct 27, 2009 at 9:28 AM, Dagobert Michelsen wrote: > In addition to migrating single files is there the possibility to migrate > complete directories? Like > ?/opt/csw/var/postgresql/ ?to ?/var/opt/csw/posgresql/ ? Yes, it is possible. For copying directories, tar is being used, to preserve the whole tree structure that's being copied. Files and directories can be specified the same way; you don't have to say which one is a file and which one is a directory. Maciej From dam at opencsw.org Mon Nov 2 15:13:10 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Nov 2009 15:13:10 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: Hi Maciej, Am 02.11.2009 um 15:05 schrieb Maciej (Matchek) Blizinski: > On Tue, Oct 27, 2009 at 9:28 AM, Dagobert Michelsen > wrote: >> In addition to migrating single files is there the possibility to >> migrate >> complete directories? Like >> /opt/csw/var/postgresql/ to /var/opt/csw/posgresql/ ? > > Yes, it is possible. For copying directories, tar is being used, to > preserve the whole tree structure that's being copied. Files and > directories can be specified the same way; you don't have to say which > one is a file and which one is a directory. Excellent! Unfortunately now I no longer have an excuse for not relocating ;-) I guess I'll make a try with fontconfig first which is waiting in testing with the old layout scheme. Best regards -- Dago From maciej at opencsw.org Mon Nov 2 15:49:48 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 2 Nov 2009 14:49:48 +0000 Subject: [csw-maintainers] New library 'jack' wants to be build with 'waf' In-Reply-To: <47F4C2E7-7170-4DA0-B287-ED592FE6328C@opencsw.org> References: <47F4C2E7-7170-4DA0-B287-ED592FE6328C@opencsw.org> Message-ID: On Thu, Oct 29, 2009 at 10:21 AM, Dagobert Michelsen wrote: > Hi, > > I just tried to build a dependency for libsndfile 'jack' which wants > to be built with the waf build system: > ?http://code.google.com/p/waf/ > > I haven't seen much of it, by I already hate it... Maybe someone has already > gained some experience with it? I tried adding support for WAF to GAR > and made preliminary makefile for jack, everything is in GAR. Are you sure it's not using autotools? A quick look at the jack sources: http://subversion.jackaudio.org/jack/trunk/jack/ Looks autotools-ey to me. Maciej From dam at opencsw.org Mon Nov 2 15:59:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Nov 2009 15:59:45 +0100 Subject: [csw-maintainers] New library 'jack' wants to be build with 'waf' In-Reply-To: References: <47F4C2E7-7170-4DA0-B287-ED592FE6328C@opencsw.org> Message-ID: Hi Maciej, Am 02.11.2009 um 15:49 schrieb Maciej (Matchek) Blizinski: > On Thu, Oct 29, 2009 at 10:21 AM, Dagobert Michelsen > wrote: >> I just tried to build a dependency for libsndfile 'jack' which wants >> to be built with the waf build system: >> http://code.google.com/p/waf/ >> >> I haven't seen much of it, by I already hate it... Maybe someone >> has already >> gained some experience with it? I tried adding support for WAF to GAR >> and made preliminary makefile for jack, everything is in GAR. > > Are you sure it's not using autotools? A quick look at the jack > sources: > > http://subversion.jackaudio.org/jack/trunk/jack/ > > Looks autotools-ey to me. That is "Jack", while for Solaris "Jack2" is needed: http://jackaudio.org/download That code is here: http://subversion.jackaudio.org/jack/jack2/trunk/jackmp/ and no longer based on autotools :-( Best regards -- Dago From schwindt at dfki.uni-kl.de Mon Nov 2 17:31:51 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 02 Nov 2009 17:31:51 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: Your message of "Wed, 28 Oct 2009 18:04:08 +0100." <4AE87988.5070401@dogan.ch> Message-ID: <200911021631.nA2GVptx008068@dfki.uni-kl.de> [...] > It would be really great if you could take over this package. As the > others already mentioned, Gar is really not difficult and you can always > ask here on the maintainers list. Sorry for the late feedback - I've been offline for a week now. I'll try to work through the docs and give it a try. Nicolai From schwindt at dfki.uni-kl.de Mon Nov 2 17:33:27 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 02 Nov 2009 17:33:27 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: Your message of "Wed, 28 Oct 2009 10:59:34 +0100." <625385e30910280259y77676329u8fc476812b82e5dc@mail.gmail.com> Message-ID: <200911021633.nA2GXRIw008101@dfki.uni-kl.de> > Dago found that people having well patched servers ;-) could run into > this due to a new cool feature in Solaris 10 called turbo charged > packages. Writes to the contents file are being delayed and synced > regularly instead of written immediately which should give a > significant performance boost. This is included in Solaris 10 update 8 > (10/09) and you can also get it via patch 119254/199255. I am setting up an old x4200 with exact that DVD rightnow. I`ll let you know when installed ssh etc. Nicolai From dam at opencsw.org Mon Nov 2 21:56:15 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Nov 2009 21:56:15 +0100 Subject: [csw-maintainers] Update of fftw In-Reply-To: References: <608B825C-14C2-4F48-9AD6-749E5FE4E9DA@opencsw.org> Message-ID: <64BAD361-8556-4CF5-B6FD-F183D8C9A7D6@opencsw.org> Hi, as it seems of general interest here the repost on-list: Am 02.11.2009 um 17:51 schrieb Maciej (Matchek) Blizinski: > On Mon, Nov 2, 2009 at 4:39 PM, Dagobert Michelsen > wrote: >>> Von: Dagobert Michelsen >>> Datum: 2. November 2009 17:00:05 MEZ >>> An: Joshua Buysse , Josh Buysse >>> Kopie: Philip Brown >>> Betreff: Update of fftw >>> >>> Hi Joshua, >>> >>> I have been playing around with fftw and made an updated package >>> for fftw including the 3.2.2 version. Usually it is policy to >>> add older libraries to the main package, but we already have the >>> fftw2 package. So I guess it will be best to add an fftw3 package >>> or should we go integrating both versioned libs in a main CSWfftw >>> package? > > My first thought is that it's better to have one fftw package, > including all the versions. > > Gentoo has a nice was of going around this. They have something called > 'slots'. If multiple major versions of a package need to coexist, they > occupy numbered slots. For instance, fftw-1.x would be assigned to > slot 0, fftw-2.x to slot 1 and fftw-3.x to slot 2. We don't have the > notion of slots, but we can merge multiple library versions in one > package. I had to wrap my mind around version modulations in GAR, but > it looks fairly easy now. (Until I run into problems again, that is. > :-) ) > > I would be for providing one package with all the versions. > > Maciej > > P.S. Dago, you can loop this e-mail in with the rest of the discussion > participants. Best regards -- Dago From ihsan at opencsw.org Tue Nov 3 12:41:16 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Tue, 03 Nov 2009 12:41:16 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <200911021631.nA2GVptx008068@dfki.uni-kl.de> References: <200911021631.nA2GVptx008068@dfki.uni-kl.de> Message-ID: <4AF016DB.9030200@opencsw.org> Hello Nicolai, On 02.11.2009 17:31, Nicolai Schwindt wrote: >> It would be really great if you could take over this package. As the >> others already mentioned, Gar is really not difficult and you can always >> ask here on the maintainers list. > Sorry for the late feedback - I've been offline for a week now. No problem. > I'll try to work through the docs and give it a try. Thanks a lot. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Tue Nov 3 16:35:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Nov 2009 16:35:17 +0100 Subject: [csw-maintainers] X11 linkage problem strategy Message-ID: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> Hi, there is a problem related to linkage against the new OpenCSW X11 libraries. The error is seen as undefined symbol XSolarisIASetProcessInfo as in here: > configure:19228: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 - > xarch=v8 -I/opt/csw/X11/include -I/opt/csw/include -I/opt/csw/ > include/gtk-1.2 -I/opt/csw/include/glib-1.2 -I/opt/csw/lib/glib/ > include -I/opt/csw/X11/include -I/opt/csw/include -xarch=v8 -L/opt/ > csw/lib -L/opt/csw/X11/lib conftest.c -L/opt/csw/lib -lgtk -lgdk - > lgmodule -lglib -ldl -lXi -lXext -lX11 -lsocket -lnsl -lm >&5 > Undefined first referenced > symbol in file > XSolarisIASetProcessInfo /lib/libX11.so.4 > ld: fatal: Symbol referencing errors. No output written to conftest The problem is caused by programs linking to CSW libXext first and then later to Solaris libX11 which also needs libXext. As the provided dependency libXext.so.0 is already provided by CSW libXext the already bound one is used - unfortunately it does not have the needed symbol in it. The easy workaround of adding Solaris libXext explicitly by adding EXTRA_LINKER_FLAGS = /usr/openwin/lib/libXext.so to the Makefile may or may not work. It does explicitly not work if the CSW libXext is also pulled in: > configure:19228: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 - > xarch=v8 -I/opt/csw/X11/include -I/opt/csw/include -I/opt/csw/ > include/gtk-1.2 -I/opt/csw/include/glib-1.2 -I/opt/csw/lib/glib/ > include -I/opt/csw/X11/include -I/opt/csw/include -xarch=v8 -L/opt/ > csw/lib -L/opt/csw/X11/lib /usr/openwin/lib/libXext.so conftest.c -L/ > opt/csw/lib -lgtk -lgdk -lgmodule -lglib -ldl -lXi -lXext -lX11 - > lsocket -lnsl -lm >&5 > ld: fatal: recording name conflict: file `/usr/openwin/lib/ > libXext.so' and file `/opt/csw/X11/lib/libXext.so' provide identical > dependency names: libXext.so.0 (possible multiple inclusion of the > same file) Maybe someone has a good solution on how to cope this in the general case. Of course the trivial one would be to recompile everything needing x11 against the CSW libs, which would pull in loads of stuff even if the Solaris library would be sufficient. Best regards -- Dago From maciej at opencsw.org Tue Nov 3 17:02:32 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 3 Nov 2009 16:02:32 +0000 Subject: [csw-maintainers] zlibCompileFlags symbol missing on sparcv9 Message-ID: Before I invest larger chunks of time in debugging this issue, I'm going to ask here. I'm trying to compile MySQL 5 on build8s, and I'm getting an error during the configure phase. It only happens with the sparcv9 modulation. configure:21806: checking for zlib compression library configure:21974: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 -xarch=v9 -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ -I/opt/csw/include -I/opt/csw/mysql5/include -D_FILE_OFFSET_BITS=64 -I/opt/csw/include -I/opt/csw/include -I/opt/csw/mysql5/include -xarch=v9 -L/opt/csw/mysql5/lib/64 -L/opt/csw/mysql5/lib//mysql/64 conftest.c -lposix4 -lresolv -lgen -lsocket -lnsl -lm -L/opt/csw/lib -lz >&5 "conftest.c", line 147: warning: statement not reached Undefined first referenced symbol in file zlibCompileFlags conftest.o ld: fatal: Symbol referencing errors. No output written to conftest Has anyone run into this problem before? Any ideas why does it work fine on sparcv8, but not on sparcv9? If anyone wants to reproduce it: svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.0.x/ cd mysql-5.0.x gmake package Maciej From dam at opencsw.org Tue Nov 3 17:11:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Nov 2009 17:11:51 +0100 Subject: [csw-maintainers] zlibCompileFlags symbol missing on sparcv9 In-Reply-To: References: Message-ID: <1676DF44-9F4E-4F0A-B662-28D032C3CC12@opencsw.org> Hi Maciej, Am 03.11.2009 um 17:02 schrieb Maciej (Matchek) Blizinski: > Before I invest larger chunks of time in debugging this issue, I'm > going to ask here. I'm trying to compile MySQL 5 on build8s, and I'm > getting an error during the configure phase. It only happens with the > sparcv9 modulation. > > configure:21806: checking for zlib compression library > configure:21974: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 > -xarch=v9 -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ > -I/opt/csw/include -I/opt/csw/mysql5/include -D_FILE_OFFSET_BITS=64 > -I/opt/csw/include -I/opt/csw/include -I/opt/csw/mysql5/include > -xarch=v9 -L/opt/csw/mysql5/lib/64 -L/opt/csw/mysql5/lib//mysql/64 > conftest.c -lposix4 -lresolv -lgen -lsocket -lnsl -lm -L/opt/csw/lib > -lz >&5 > "conftest.c", line 147: warning: statement not reached > Undefined first referenced > symbol in file > zlibCompileFlags conftest.o > ld: fatal: Symbol referencing errors. No output written to conftest > > Has anyone run into this problem before? Any ideas why does it work > fine on sparcv8, but not on sparcv9? > > If anyone wants to reproduce it: > svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.0.x/ > cd mysql-5.0.x > gmake package You are using some pathes that are unsuitable for 64 bit compilation. I'll commit the fix and repost the delta/revision. Best regards -- Dago From dam at opencsw.org Tue Nov 3 17:39:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Nov 2009 17:39:18 +0100 Subject: [csw-maintainers] zlibCompileFlags symbol missing on sparcv9 In-Reply-To: <1676DF44-9F4E-4F0A-B662-28D032C3CC12@opencsw.org> References: <1676DF44-9F4E-4F0A-B662-28D032C3CC12@opencsw.org> Message-ID: <5F92AAA4-A709-4E23-B9C9-293E1805365F@opencsw.org> Hi Maciej, Am 03.11.2009 um 17:11 schrieb Dagobert Michelsen: > Am 03.11.2009 um 17:02 schrieb Maciej (Matchek) Blizinski: > >> Before I invest larger chunks of time in debugging this issue, I'm >> going to ask here. I'm trying to compile MySQL 5 on build8s, and I'm >> getting an error during the configure phase. It only happens with >> the >> sparcv9 modulation. >> >> configure:21806: checking for zlib compression library >> configure:21974: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 >> -xarch=v9 -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ >> -I/opt/csw/include -I/opt/csw/mysql5/include -D_FILE_OFFSET_BITS=64 >> -I/opt/csw/include -I/opt/csw/include -I/opt/csw/mysql5/include >> -xarch=v9 -L/opt/csw/mysql5/lib/64 -L/opt/csw/mysql5/lib//mysql/64 >> conftest.c -lposix4 -lresolv -lgen -lsocket -lnsl -lm -L/opt/csw/lib >> -lz >&5 >> "conftest.c", line 147: warning: statement not reached >> Undefined first referenced >> symbol in file >> zlibCompileFlags conftest.o >> ld: fatal: Symbol referencing errors. No output written to conftest >> >> Has anyone run into this problem before? Any ideas why does it work >> fine on sparcv8, but not on sparcv9? >> >> If anyone wants to reproduce it: >> svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.0.x/ >> cd mysql-5.0.x >> gmake package > > You are using some pathes that are unsuitable for 64 bit > compilation. I'll commit > the fix and repost the delta/revision. The build still runs, but I have some early comments: > Index: Makefile > =================================================================== > --- Makefile (revision 7091) > +++ Makefile (working copy) > @@ -51,8 +51,6 @@ > SPKG_DESC_CSWmysql5rt = MySQL 5 runtime files > SPKG_DESC_CSWmysql5test = MySQL 5 testing files > > -support64 = (/(amd64|i386))? > - While you can insert this conditionally there is a special function which expands to all buildable ISAs. You would use it as $(call baseisadirs,,) It expands to / // // and it works on all platforms. This is more important if you add more modulations for optimized libraries. > # Defining the client programs, which are going to pick up the 32- > and 64-bit > # binaries, symbolic links, isaexec stuff and man pages. > CSWmysql5client_programs = myisamlog > @@ -75,11 +73,11 @@ > > PKGFILES_CSWmysql5bench = $(prefix)/sql-bench.* > PKGFILES_CSWmysql5client = $(bindir) > -PKGFILES_CSWmysql5client += $(foreach bin_name,$ > (CSWmysql5client_programs),$(bindir)$(support64)/$(bin_name)) > +PKGFILES_CSWmysql5client += $(foreach bin_name,$ > (CSWmysql5client_programs),$(call baseisadirs,$(bindir),$(bin_name))) > PKGFILES_CSWmysql5client += $(foreach bin_name,$ > (CSWmysql5client_programs),$(mandir)/man1/$(bin_name)\.1) > PKGFILES_CSWmysql5client += $(foreach bin_name,$ > (CSWmysql5client_programs),/opt/csw/bin/$(bin_name)) > PKGFILES_CSWmysql5client += $(foreach bin_name,$ > (CSWmysql5client_programs),/opt/csw/sbin/$(bin_name)) > -PKGFILES_CSWmysql5devel += $(bindir)$(support64)/mysql_config > +PKGFILES_CSWmysql5devel += $(call baseisadirs,$ > (bindir),mysql_config) > PKGFILES_CSWmysql5devel += $(mandir)/man1/mysql_config\.1 > PKGFILES_CSWmysql5devel = $(prefix)/include.* > PKGFILES_CSWmysql5rt = $(prefix)/lib/.*\.so.* > @@ -105,8 +103,8 @@ > > # because we alter the prefix. this gets us proper linking as well > as > # LD_OPTIONS (RPATH) > -EXTRA_LIB = /opt/csw/lib > -EXTRA_INC = /opt/csw/include > +# EXTRA_LIB = /opt/csw/lib > +# EXTRA_INC = /opt/csw/include It should not be necessary to add these explicitly, even if you redefine "prefix". The BUILD_PREFIX defaults to /opt/csw and it is the base where everything goes. If you reset prefix to a subdir of BUILD_PREFIX the necessary library pathes and include dirs are adjusted automatically. This is all done in gar.conf.mk. If you must add additional library dirs always use something like $(abspath $(libdir)/$(MM_BINDIR)) for pathes to binaries $(abspath $(libdir)/$(MM_LIBDIR)) for libraries to honour bitwidth-specific directories. I'll verify that it really works with MySQL, please stand by. > @@ -130,14 +128,16 @@ > BUILD64 = 1 > > USERGROUP = /etc/opt/csw/pkg/CSWmysql5/cswusergroup > -PROTOTYPE_FILTER = awk ' \ > - $$$$3 ~ /\/var\/opt\/csw\/mysql5$$$$/ { $$$$2 = "ugfiles"; \ > - $$$$4 = "0700"; \ > - $$$$5 = "mysql"; \ > - $$$$6 = "mysql" } \ > - { print }' > -SPKG_CLASSES = none cswusergroup ugfiles > > +PROTOTYPE_MODIFIERS = ownmysql > +PROTOTYPE_FILES_ownmysql = /var/opt/csw/mysql5 > +PROTOTYPE_USER_ownmysql = mysql > +PROTOTYPE_GROUP_ownmysql = mysql > +PROTOTYPE_PERMS_ownmysql = 0700 > +PROTOTYPE_CLASS_ownmysql = ugfiles > + > +SPKG_CLASSES = none ugfiles > + > include gar/category.mk > > post-install-modulated: > Ok, as you suggested prototype tweaks yourself you probably know how they work and why they are better than prototype filters ;-) http://sourceforge.net/apps/trac/gar/wiki/Prototypes Best regards -- Dago From dam at opencsw.org Tue Nov 3 21:23:34 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Nov 2009 21:23:34 +0100 Subject: [csw-maintainers] zlibCompileFlags symbol missing on sparcv9 In-Reply-To: <5F92AAA4-A709-4E23-B9C9-293E1805365F@opencsw.org> References: <1676DF44-9F4E-4F0A-B662-28D032C3CC12@opencsw.org> <5F92AAA4-A709-4E23-B9C9-293E1805365F@opencsw.org> Message-ID: <28FFE8F4-F607-424A-9A5A-2352BCF63129@opencsw.org> Hi, the problem to the linker flags have been fixed in r7096. If a different prefix was used the additional pathes were only added to the runtime linker path, not the normal linker path. If you encounter any such issues don't hesitate to post the list! Best regards -- Dago From ihsan at opencsw.org Wed Nov 4 10:27:14 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 04 Nov 2009 10:27:14 +0100 Subject: [csw-maintainers] Unbound build error Message-ID: <4AF148F2.7050807@opencsw.org> Hello, Have been there any changes on the build system recently? While building unbound: ./libtool --tag=CC --mode=link /opt/csw/gcc4/bin/gcc ./linktest.c -I. -I. -I/opt/csw/include -I/opt/csw/include -DHAVE_CONFIG_H -I. -I. -Wwrite-strings -W -Wall -O2 -g -O2 -pipe -mcpu=v8 -I/opt/csw/include -std=c99 -D__EXTENSIONS__ -D_BSD_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE -lldns -lnsl -lsocket -lcrypto -o linktest libtool: link: /opt/csw/gcc4/bin/gcc ./linktest.c -I. -I. -I/opt/csw/include -I/opt/csw/include -DHAVE_CONFIG_H -I. -I. -Wwrite-strings -W -Wall -O2 -g -O2 -pipe -mcpu=v8 -I/opt/csw/include -std=c99 -D__EXTENSIONS__ -D_BSD_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE -o linktest -lldns -lnsl -lsocket -lcrypto ld: fatal: library -lldns: not found ld: fatal: library -lcrypto: not found ld: fatal: File processing errors. No output written to linktest Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From schwindt at dfki.uni-kl.de Wed Nov 4 10:49:01 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Wed, 04 Nov 2009 10:49:01 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: Your message of "Wed, 28 Oct 2009 10:59:34 +0100." <625385e30910280259y77676329u8fc476812b82e5dc@mail.gmail.com> Message-ID: <200911040949.nA49n15n006224@dfki.uni-kl.de> [...] > So please help test cswclassutils 1.27 in testing. Some packages to > test with are: CSWclamav, CSWossh and CSWcacertificates. If you > maintain packages that use cpsampleconf or preserveconf, please test > them. > > http://mirror.opencsw.org/testing/cswclassutils-1.27,REV=2009.10.28-SunOS5.8- all-CSW.pkg.gz Do you want this in mantis ? pkg-get -i trac ... Compiling py files to normal bytecode ... Traceback (most recent call last): File "/var/opt/csw/cswclassutils/pycomp.318.20091104102411.py", line 143, in except PyCompileError: NameError: name 'PyCompileError' is not defined Compiling py files to optimized bytecode ... Traceback (most recent call last): File "/var/opt/csw/cswclassutils/pycomp.318.20091104102411.py", line 143, in except PyCompileError: NameError: name 'PyCompileError' is not defined [ verifying class ] From bonivart at opencsw.org Wed Nov 4 11:17:35 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 4 Nov 2009 11:17:35 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: <200911040949.nA49n15n006224@dfki.uni-kl.de> References: <625385e30910280259y77676329u8fc476812b82e5dc@mail.gmail.com> <200911040949.nA49n15n006224@dfki.uni-kl.de> Message-ID: <625385e30911040217o753ad117hd160eedfe86fa955@mail.gmail.com> On Wed, Nov 4, 2009 at 10:49 AM, Nicolai Schwindt wrote: > [...] >> So please help test cswclassutils 1.27 in testing. Some packages to >> test with are: CSWclamav, CSWossh and CSWcacertificates. If you >> maintain packages that use cpsampleconf or preserveconf, please test >> them. >> >> http://mirror.opencsw.org/testing/cswclassutils-1.27,REV=2009.10.28-SunOS5.8- > all-CSW.pkg.gz > > Do you want this in mantis ? > > pkg-get -i trac > > ... > > Compiling py files to normal bytecode ... > Traceback (most recent call last): > ?File "/var/opt/csw/cswclassutils/pycomp.318.20091104102411.py", line 143, in > > ? ?except PyCompileError: > NameError: name 'PyCompileError' is not defined > Compiling py files to optimized bytecode ... > Traceback (most recent call last): > ?File "/var/opt/csw/cswclassutils/pycomp.318.20091104102411.py", line 143, in > > ? ?except PyCompileError: > NameError: name 'PyCompileError' is not defined > [ verifying class ] Please file a new bug, this is unrelated to what I wanted tested (cpsampleconf and preserveconf). This is about the pycompile script. -- /peter From dam at opencsw.org Wed Nov 4 12:11:27 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 12:11:27 +0100 Subject: [csw-maintainers] Unbound build error In-Reply-To: <4AF148F2.7050807@opencsw.org> References: <4AF148F2.7050807@opencsw.org> Message-ID: <9450D423-FC6B-4FBB-87F6-DE93A0AD2789@opencsw.org> Hi Ihsan, Am 04.11.2009 um 10:27 schrieb Ihsan Dogan: > Have been there any changes on the build system recently? > > While building unbound: > ./libtool --tag=CC --mode=link /opt/csw/gcc4/bin/gcc ./linktest.c -I. > -I. -I/opt/csw/include -I/opt/csw/include -DHAVE_CONFIG_H -I. -I. > -Wwrite-strings -W -Wall -O2 -g -O2 -pipe -mcpu=v8 -I/opt/csw/include > -std=c99 -D__EXTENSIONS__ -D_BSD_SOURCE -D_POSIX_C_SOURCE=200112 > -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE -lldns > -lnsl -lsocket -lcrypto -o linktest > libtool: link: /opt/csw/gcc4/bin/gcc ./linktest.c -I. -I. > -I/opt/csw/include -I/opt/csw/include -DHAVE_CONFIG_H -I. -I. > -Wwrite-strings -W -Wall -O2 -g -O2 -pipe -mcpu=v8 -I/opt/csw/include > -std=c99 -D__EXTENSIONS__ -D_BSD_SOURCE -D_POSIX_C_SOURCE=200112 > -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE -o > linktest > -lldns -lnsl -lsocket -lcrypto > ld: fatal: library -lldns: not found > ld: fatal: library -lcrypto: not found > ld: fatal: File processing errors. No output written to linktest Obviously -L/opt/csw/lib is missing here. When I try to reproduce it I cannot see this problem and I get a package. Some tests are failing though, which may or may not be related this issue. Additionally it looks like ldns_devel was not installed on the farm. Did you split off _devel lately? Anyway, I have installed CSWldnsdevel on all buildfarm servers. Best regards -- Dago From dam at opencsw.org Wed Nov 4 12:37:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 12:37:28 +0100 Subject: [csw-maintainers] Update of libevent and memcached In-Reply-To: References: Message-ID: <57C4220F-0C05-45AD-B025-305DE61331E4@opencsw.org> Hi Ben, Am 02.11.2009 um 14:09 schrieb Dagobert Michelsen: > Next thing I need is memcached. It needs stdbool and stdint which I > added from gnulib. However, the header files end up in lib/ and > are not added to the include path. Ben, would you please enlighten > me what is going wrong here? > > Additionally, I found these excellent Blog posts from Trond Norbye: > http://blogs.sun.com/trond/category/Memcached > regarding memcached on Solaris. Nice, but only starting from > OpenSolaris. I wonder if we can get the manifest and stuff for > our package. Trond fixed this upstream, so it will already be in the next version. Anyway, thanks Ben for your commitment :-) Best regards -- Dago From ihsan at dogan.ch Wed Nov 4 14:12:56 2009 From: ihsan at dogan.ch (Ihsan Dogan) Date: Wed, 04 Nov 2009 14:12:56 +0100 Subject: [csw-maintainers] Unbound build error In-Reply-To: <9450D423-FC6B-4FBB-87F6-DE93A0AD2789@opencsw.org> References: <4AF148F2.7050807@opencsw.org> <9450D423-FC6B-4FBB-87F6-DE93A0AD2789@opencsw.org> Message-ID: <4AF17DD8.1000302@dogan.ch> Hi Dago, On 04.11.2009 12:11, Dagobert Michelsen wrote: >> While building unbound: >> ./libtool --tag=CC --mode=link /opt/csw/gcc4/bin/gcc ./linktest.c -I. >> -I. -I/opt/csw/include -I/opt/csw/include -DHAVE_CONFIG_H -I. -I. >> -Wwrite-strings -W -Wall -O2 -g -O2 -pipe -mcpu=v8 -I/opt/csw/include >> -std=c99 -D__EXTENSIONS__ -D_BSD_SOURCE -D_POSIX_C_SOURCE=200112 >> -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE -lldns >> -lnsl -lsocket -lcrypto -o linktest >> libtool: link: /opt/csw/gcc4/bin/gcc ./linktest.c -I. -I. >> -I/opt/csw/include -I/opt/csw/include -DHAVE_CONFIG_H -I. -I. >> -Wwrite-strings -W -Wall -O2 -g -O2 -pipe -mcpu=v8 -I/opt/csw/include >> -std=c99 -D__EXTENSIONS__ -D_BSD_SOURCE -D_POSIX_C_SOURCE=200112 >> -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_ALL_SOURCE -o linktest >> -lldns -lnsl -lsocket -lcrypto >> ld: fatal: library -lldns: not found >> ld: fatal: library -lcrypto: not found >> ld: fatal: File processing errors. No output written to linktest > > Obviously -L/opt/csw/lib is missing here. When I try to reproduce it > I cannot see this problem and I get a package. Some tests are > failing though, which may or may not be related this issue. > > Additionally it looks like ldns_devel was not installed on the farm. > Did you split off _devel lately? Anyway, I have installed CSWldnsdevel > on all buildfarm servers. After you have installed ldns_devel as well, but in the first place I've tried to build it against the builtin ldns library. In theory, this should work as well. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Wed Nov 4 14:13:28 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 04 Nov 2009 08:13:28 -0500 Subject: [csw-maintainers] pkginstall question In-Reply-To: <625385e30911040217o753ad117hd160eedfe86fa955@mail.gmail.com> References: <625385e30910280259y77676329u8fc476812b82e5dc@mail.gmail.com> <200911040949.nA49n15n006224@dfki.uni-kl.de> <625385e30911040217o753ad117hd160eedfe86fa955@mail.gmail.com> Message-ID: <1257340379-sup-4770@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Wed Nov 04 05:17:35 -0500 2009: > > Compiling py files to normal bytecode ... > > Traceback (most recent call last): > > ?File "/var/opt/csw/cswclassutils/pycomp.318.20091104102411.py", line 143, in > > > > ? ?except PyCompileError: > > NameError: name 'PyCompileError' is not defined > > Compiling py files to optimized bytecode ... > > Traceback (most recent call last): > > ?File "/var/opt/csw/cswclassutils/pycomp.318.20091104102411.py", line 143, in > > > > ? ?except PyCompileError: > > NameError: name 'PyCompileError' is not defined Yes, a new bug please. Please provide the version of python on your system as well. 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 ihsan at opencsw.org Wed Nov 4 15:29:58 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 04 Nov 2009 15:29:58 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <7D96D3D3-FA0A-40E1-9549-9114E56174DC@opencsw.org> References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> <4AD1C002.1050409@opencsw.org> <7D96D3D3-FA0A-40E1-9549-9114E56174DC@opencsw.org> Message-ID: <4AF18FE6.9040703@opencsw.org> Hello Dago, On 11.10.2009 14:00, Dagobert Michelsen wrote: >>> Let me know if you encounter anything unusual or feel the docs >>> need some clarification :-) >> >> I have two packages, ldns and unbound, which are build with gcc on >> Solaris 8, while the Solaris 10 version is built with Studio 12. >> >> Does this change has any influence to this very specific case? > > Yes! Please add > PACKAGING_PLATFORMS = solaris8-sparc solaris8-i386 solaris10-sparc > solaris10-i386 > to you Makefile. This tells GAR about all platforms you want packages > built on. Ok. Thanks for the hint. > It may needs additional tweaking. Have you committed all your local > changes? No, not yet. > Than I'd love to take a look and allow > gmake platforms > to automatically build packages for all 4 platforms without intervention. Something does not work yet. The Solaris 8 x86 package was built, but the Solaris 10 package fails: gmake: warning: Clock skew detected. Your build may be incomplete. gmake: Leaving directory `/home/ihsan/gar/csw/mgar/pkg/unbound/trunk' Connection to build8x closed. bash: gmake: command not found Connection to build10s closed. gmake: *** [platforms] Error 127 Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Wed Nov 4 15:35:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 15:35:19 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <4AF18FE6.9040703@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> Message-ID: Hi Ihsan, Am 04.11.2009 um 15:29 schrieb Ihsan Dogan: > On 11.10.2009 14:00, Dagobert Michelsen wrote: > >>>> Let me know if you encounter anything unusual or feel the docs >>>> need some clarification :-) >>> >>> I have two packages, ldns and unbound, which are build with gcc on >>> Solaris 8, while the Solaris 10 version is built with Studio 12. >>> >>> Does this change has any influence to this very specific case? >> >> Yes! Please add >> PACKAGING_PLATFORMS = solaris8-sparc solaris8-i386 solaris10-sparc >> solaris10-i386 >> to you Makefile. This tells GAR about all platforms you want packages >> built on. > > Ok. Thanks for the hint. > >> It may needs additional tweaking. Have you committed all your local >> changes? > > No, not yet. Please do, so that I can reproduce the problems. >> Than I'd love to take a look and allow >> gmake platforms >> to automatically build packages for all 4 platforms without >> intervention. > > Something does not work yet. The Solaris 8 x86 package was built, but > the Solaris 10 package fails: > > gmake: warning: Clock skew detected. Your build may be incomplete. > gmake: Leaving directory `/home/ihsan/gar/csw/mgar/pkg/unbound/trunk' > Connection to build8x closed. > bash: gmake: command not found > Connection to build10s closed. > gmake: *** [platforms] Error 127 Ok, what command have you issued at what host? Best regards -- Dago From dam at opencsw.org Wed Nov 4 16:29:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 16:29:28 +0100 Subject: [csw-maintainers] Package update: libgmp Message-ID: <70385B8A-E54B-4D89-B9EA-AF90C18786FB@opencsw.org> Hi, I have just finished recompiling libgmp with at least that many optimizations as the previous one :-) -rw-r--r-- 1 dam csw 701750 Nov 4 16:25 libgmp-4.3.1,REV=2009.11.04-SunOS5.8-i386-CSW.pkg.gz -rw-r--r-- 1 dam csw 866243 Nov 4 16:24 libgmp-4.3.1,REV=2009.11.04-SunOS5.8-sparc-CSW.pkg.gz Unfortunately, the new libraries now have a dependency to the gcc4 runtime: dam at login [login]:/home/dam/mgar/pkg/libgmp/trunk/work/solaris8-sparc/ pkgroot/opt/csw/lib > ldd libgmp.so libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /opt/csw/gcc4/lib/libgcc_s.so.1 libm.so.2 => /lib/libm.so.2 As the library can be used to compile gcc itself this may be unhandy. Feedback welcome! Best regards -- Dago From dam at opencsw.org Wed Nov 4 16:43:29 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 16:43:29 +0100 Subject: [csw-maintainers] Update of fftw In-Reply-To: <64BAD361-8556-4CF5-B6FD-F183D8C9A7D6@opencsw.org> References: <608B825C-14C2-4F48-9AD6-749E5FE4E9DA@opencsw.org> <64BAD361-8556-4CF5-B6FD-F183D8C9A7D6@opencsw.org> Message-ID: <2D2A97DD-86CD-4E9B-BF90-61127253B6D5@opencsw.org> Hi, Am 02.11.2009 um 21:56 schrieb Dagobert Michelsen: > as it seems of general interest here the repost on-list: > > Am 02.11.2009 um 17:51 schrieb Maciej (Matchek) Blizinski: >> On Mon, Nov 2, 2009 at 4:39 PM, Dagobert Michelsen >> wrote: >>>> Von: Dagobert Michelsen >>>> Datum: 2. November 2009 17:00:05 MEZ >>>> An: Joshua Buysse , Josh Buysse >>>> >>>> Kopie: Philip Brown >>>> Betreff: Update of fftw >>>> >>>> Hi Joshua, >>>> >>>> I have been playing around with fftw and made an updated package >>>> for fftw including the 3.2.2 version. Usually it is policy to >>>> add older libraries to the main package, but we already have the >>>> fftw2 package. So I guess it will be best to add an fftw3 package >>>> or should we go integrating both versioned libs in a main CSWfftw >>>> package? >> >> My first thought is that it's better to have one fftw package, >> including all the versions. >> >> Gentoo has a nice was of going around this. They have something >> called >> 'slots'. If multiple major versions of a package need to coexist, >> they >> occupy numbered slots. For instance, fftw-1.x would be assigned to >> slot 0, fftw-2.x to slot 1 and fftw-3.x to slot 2. We don't have the >> notion of slots, but we can merge multiple library versions in one >> package. I had to wrap my mind around version modulations in GAR, but >> it looks fairly easy now. (Until I run into problems again, that is. >> :-) ) >> >> I would be for providing one package with all the versions. >> >> Maciej >> >> P.S. Dago, you can loop this e-mail in with the rest of the >> discussion >> participants. Humm, no feedback yet. So I guess I make a version modulation for 2.x, put everything in fftw, make fftw2 depend on fftw and then make fftw2 an emty stub. On the other hand there are **NO** packages depending on fftw2, so can I skip including the old version? Josh: Be invited to release the updated package at will, just let me know :-) Phil: Are you ok with this? I don't want to package everything up just to redo things on submission ;-) Best regards -- Dago From ihsan at opencsw.org Wed Nov 4 16:47:40 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 04 Nov 2009 16:47:40 +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> Message-ID: <4AF1A21C.4060201@opencsw.org> Hello Dago, On 04.11.2009 15:35, Dagobert Michelsen wrote: >>> It may needs additional tweaking. Have you committed all your local >>> changes? >> No, not yet. > Please do, so that I can reproduce the problems. I just committed revision 7108. >>> Than I'd love to take a look and allow >>> gmake platforms >>> to automatically build packages for all 4 platforms without >>> intervention. >> Something does not work yet. The Solaris 8 x86 package was built, but >> the Solaris 10 package fails: >> >> gmake: warning: Clock skew detected. Your build may be incomplete. >> gmake: Leaving directory `/home/ihsan/gar/csw/mgar/pkg/unbound/trunk' >> Connection to build8x closed. >> bash: gmake: command not found >> Connection to build10s closed. >> gmake: *** [platforms] Error 127 > Ok, what command have you issued at what host? "gmake platforms" on build8s. Same happens on build10s. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From phil at bolthole.com Wed Nov 4 18:44:39 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 4 Nov 2009 09:44:39 -0800 Subject: [csw-maintainers] Update of fftw In-Reply-To: <2D2A97DD-86CD-4E9B-BF90-61127253B6D5@opencsw.org> References: <608B825C-14C2-4F48-9AD6-749E5FE4E9DA@opencsw.org> <64BAD361-8556-4CF5-B6FD-F183D8C9A7D6@opencsw.org> <2D2A97DD-86CD-4E9B-BF90-61127253B6D5@opencsw.org> Message-ID: Huh. I didnt noticed that the usual reply-to thing didnt kick in. Seems that i replied in private email to Dagobert on this subject. On Wed, Nov 4, 2009 at 7:43 AM, Dagobert Michelsen wrote: > > Phil: Are you ok with this? I don't want to package everything up just > to redo things on submission ;-) > From maciej at opencsw.org Wed Nov 4 21:38:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 4 Nov 2009 20:38:47 +0000 Subject: [csw-maintainers] GAR: tweaking distribution file names Message-ID: I have the following problem: The purveyor of software distributes binaries. There are different binaries for x86, amd64, sparcv8 and sparcv9, but they are all named the same: http://www.example.com/download/x86/foo http://www.example.com/download/amd64/foo http://www.example.com/download/sparcv8/foo http://www.example.com/download/sparcv9/foo I can't just say DISTFILES = foo, because there is an assumption that different files have distinct file names. I want to do some sort of mapping: DISTFILES = foo-$(GARVERSION)-x86 DISTFILES += foo-$(GARVERSION)-amd64 DISTFILES += foo-$(GARVERSION)-sparcv8 DISTFILES += foo-$(GARVERSION)-sparcv9 It means that I want to download http://www.example.com/download/x86/foo and after downloading it, rename it to foo-$(GARVERSION)-x86, and associate the checksum with foo-$(GARVERSION)-x86, not just foo. What's the most elegant way of going about it? I tried defining targets such as: $(DOWNLOADDIR)/foo-$(GARVERSION)-x86 ...but it did not work. gmake seems to be ignoring these targets. Help? Maciej From dam at opencsw.org Wed Nov 4 22:14:25 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 22:14:25 +0100 Subject: [csw-maintainers] GAR: tweaking distribution file names In-Reply-To: References: Message-ID: <8752ACC6-2202-4B04-8C26-5A46BE19A31F@opencsw.org> Hi Maciej, Am 04.11.2009 um 21:38 schrieb Maciej (Matchek) Blizinski: > I have the following problem: The purveyor of software distributes > binaries. There are different binaries for x86, amd64, sparcv8 and > sparcv9, but they are all named the same: > > http://www.example.com/download/x86/foo > http://www.example.com/download/amd64/foo > http://www.example.com/download/sparcv8/foo > http://www.example.com/download/sparcv9/foo > > I can't just say DISTFILES = foo, because there is an assumption that > different files have distinct file names. I want to do some sort of > mapping: > > DISTFILES = foo-$(GARVERSION)-x86 > DISTFILES += foo-$(GARVERSION)-amd64 > DISTFILES += foo-$(GARVERSION)-sparcv8 > DISTFILES += foo-$(GARVERSION)-sparcv9 > > It means that I want to download > http://www.example.com/download/x86/foo and after downloading it, > rename it to foo-$(GARVERSION)-x86, and associate the checksum with > foo-$(GARVERSION)-x86, not just foo. > > What's the most elegant way of going about it? I tried defining > targets such as: > > $(DOWNLOADDIR)/foo-$(GARVERSION)-x86 > > ...but it did not work. gmake seems to be ignoring these targets. Mmhhh, looks like the download-section needs some more work. There are other issues also with the current scheme when you have 10 files from 10 different locations where GAR tries every file at every location taking forever when you don't prime /home/src. What is in the files? Would they unpack to different directories? Or do you want modulation-specific sources? Best regards -- Dago From dam at opencsw.org Wed Nov 4 22:16:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Nov 2009 22:16:55 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <4AF1A21C.4060201@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> Message-ID: <25FB7213-E65F-4115-8DC9-50D57113E275@opencsw.org> Hi Ihsan, Am 04.11.2009 um 16:47 schrieb Ihsan Dogan: >>>> Than I'd love to take a look and allow >>>> gmake platforms >>>> to automatically build packages for all 4 platforms without >>>> intervention. >>> Something does not work yet. The Solaris 8 x86 package was built, >>> but >>> the Solaris 10 package fails: >>> >>> gmake: warning: Clock skew detected. Your build may be incomplete. >>> gmake: Leaving directory `/home/ihsan/gar/csw/mgar/pkg/unbound/ >>> trunk' >>> Connection to build8x closed. >>> bash: gmake: command not found >>> Connection to build10s closed. >>> gmake: *** [platforms] Error 127 >> Ok, what command have you issued at what host? > > "gmake platforms" on build8s. Same happens on build10s. I can reproduce it: > gmake: Leaving directory `/home/dam/mgar/pkg/unbound/trunk' > Connection to build8x closed. > zsh: command not found: gmake > Connection to build10s closed. I'll have a closer look tomorrow. Best regards -- Dago From phil at bolthole.com Wed Nov 4 22:28:28 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 4 Nov 2009 13:28:28 -0800 Subject: [csw-maintainers] X11 linkage problem strategy In-Reply-To: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> Message-ID: On Tue, Nov 3, 2009 at 7:35 AM, Dagobert Michelsen wrote: > > Maybe someone has a good solution on how to cope this in the general case. > Of course the trivial one would be to recompile everything needing x11 > against the CSW libs, which would pull in loads of stuff even if the > Solaris library would be sufficient. This was the core of my original reluctance to have these new libs in. I described explicitly that this sort of thing would be inevitable :-( Recompiling certain things for the newer, csw-bundled X11 libs will then become required.. not because those things themselves need the newer stuff... but because yet other packages, depend on the first set of packages, and also require the newer X11 libs :-( Technically, we dont need to require *everything* of ours that uses X11. But pretty close. Pretty much anything of ours that touches gnome libs... or anything of ours that is touched BY something that touches gnome libs... will need to be relinked now, I think :-( From maciej at opencsw.org Thu Nov 5 09:19:38 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 5 Nov 2009 08:19:38 +0000 Subject: [csw-maintainers] GAR: tweaking distribution file names In-Reply-To: <8752ACC6-2202-4B04-8C26-5A46BE19A31F@opencsw.org> References: <8752ACC6-2202-4B04-8C26-5A46BE19A31F@opencsw.org> Message-ID: On Wed, Nov 4, 2009 at 9:14 PM, Dagobert Michelsen wrote: > Mmhhh, looks like the download-section needs some more work. There are > other issues also with the current scheme when you have 10 files from > 10 different locations where GAR tries every file at every location > taking forever when you don't prime /home/src. > > What is in the files? Would they unpack to different directories? Or do > you want modulation-specific sources? The files are just binaries, they just need to be put into the packages as they are. There's no unpacking. Modulation-specific directories would do it, if the file names were different for each modulation. This scenario would work: http://www.example.com/download/x86/foo-x86 http://www.example.com/download/amd64/foo-amd64 http://www.example.com/download/sparcv8/foo-sparcv8 http://www.example.com/download/sparcv9/foo-sparcv9 But in this case we have: http://www.example.com/download/x86/foo http://www.example.com/download/amd64/foo http://www.example.com/download/sparcv8/foo http://www.example.com/download/sparcv9/foo I think that file renames are necessary. Maciej From dam at opencsw.org Thu Nov 5 11:08:38 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 5 Nov 2009 11:08:38 +0100 Subject: [csw-maintainers] X11 linkage problem strategy In-Reply-To: References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> Message-ID: Hi Phil, Am 04.11.2009 um 22:28 schrieb Philip Brown: > On Tue, Nov 3, 2009 at 7:35 AM, Dagobert Michelsen > wrote: >> >> Maybe someone has a good solution on how to cope this in the >> general case. >> Of course the trivial one would be to recompile everything needing >> x11 >> against the CSW libs, which would pull in loads of stuff even if the >> Solaris library would be sufficient. > > This was the core of my original reluctance to have these new libs in. > I described explicitly that this sort of thing would be inevitable :-( The problem is that we didn't introduce the dependency just for the kicks. Without them most the stuff from William simply wouldn't work on Solaris 8. > Recompiling certain things for the newer, csw-bundled X11 libs will > then become required.. not because those things themselves need the > newer stuff... but because yet other packages, depend on the first set > of packages, and also require the newer X11 libs :-( > > Technically, we dont need to require *everything* of ours that uses > X11. But pretty close. > > Pretty much anything of ours that touches gnome libs... or anything of > ours that is touched BY something that touches gnome libs... will need > to be relinked now, I think :-( It may be worthwhile to avoid this X11 dependency when we start with OpenSolaris or even Solaris 10. William? Best regards -- Dago From dam at opencsw.org Thu Nov 5 16:02:53 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 5 Nov 2009 16:02:53 +0100 Subject: [csw-maintainers] Enhanced pkgcheck in GAR Message-ID: Hi, with the putback of r7123 all produced packages by a recipe will now be checked at once. Errors about missing libs from uninstalled packages residing in a dependent built package should now no longer occur. Thanks to Ben for updating checkpkg so that GAR can make use of it! The following packages disable ENABLE_CHECK. Please remove this line and see if no errors reported on pkgcheck: bind botnet cacti clamav clearsilver cswutils cyrus_imapd dante dhcp dovecot gail graphviz htmldoc icinga jdk5 munin nagios nagvis ndoutils openssl1 php4 php5 pnp pysetuptools python sendmail xchat Best regards -- Dago From maciej at opencsw.org Thu Nov 5 17:02:47 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 5 Nov 2009 16:02:47 +0000 Subject: [csw-maintainers] Missing my_attribute.h from CSWmysql5devel In-Reply-To: <1250707455-sup-5092@ntdws12.chass.utoronto.ca> References: <1250703965-sup-847@ntdws12.chass.utoronto.ca> <1250704892-sup-1276@ntdws12.chass.utoronto.ca> <1250707455-sup-5092@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Aug 19, 2009 at 6:45 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Wed Aug 19 14:40:13 -0400 2009: > >> What I thought of doing is taking your mysql5 gar Makefile, and >> compiling mysql-5.0.x with it. Whether the new packages roughly match >> the old ones, can be checked by comparing the prototype files. I've >> done that when rewriting cups. What do you think about this idea? > > If you've got the time and energy, go for it. ?At the very least, it > would fix this bug with the current version of the package. ?I'm > hoping to have time in September to dig into the 5.1 stuff again. I spent some time working on 5.0.x; I've copied the existing 5.1 build and worked in a branch. I got it to build for 5.8 with 64-bit support. The package is reworked from the ground up. It contains different binary layout, and different ISAs support. Previously, there were pentium-specific x86 binaries. The new packages conform to our x86 + amd64 standard. I tried the new packages to be similar to the old ones, but some differences were inevitable. I still have things on my TODO list before the package is complete, but I decided to release it at its current state so that people could provide feedback. Maciej From dam at opencsw.org Thu Nov 5 17:16:42 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 5 Nov 2009 17:16:42 +0100 Subject: [csw-maintainers] Preview of the new mirror structure available Message-ID: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> Hi, I did some work towards the enhanced directory structure for the mirror we talked about. Goals: - subscription of master mirror layout should be kept unchanged - additional subscriptions should be cheap - mirroring allpkgs/ and experimental/ should be optional - Skripts to show deltas between catalogs - especially experimental- vs. testing vs. current - also between current freezes - put that information in README There are still some things to be done but I could also use some feedback now, so here it is :-) ** The intended layout looks like this: opencsw/ experimental/ / pkgs/ (confined to this directory) mytest.pkg.gz sparc/ 5.8/ mytest.pkg.gz (hardlinked to pkgs/mytest.pkg.gz) testing/ pkgs/ sparc/ 5.8/ distribution/ allcatalogs/ catalog-sparc-5.8-20091002 allpkgs/ mypkg.tar.gz stable/ sparc/ 5.8/ current/ sparc/ 5.8/ pkg.tar.gz (also hardlinked from allpkgs) freeze/ current-20091002/ README.20091002 sparc/ 5.8/ catalog pkg.tar.gz (hardlinked from allpkgs) 5.9/ pkg.tar.gz (symlinked to 5.8, same as in current/) current-20091003/ sparc/ ... current-20091004/ -> symlinked to current-20091003 if no change in catalog stable-20091004/ ... ** TBD: experimental/ should be filled with the subdirectories from what is now in testing/. Subdirectories can be created by each maintainer and for each folder a subproject is created in experimental which can be synced to separately. ** TBD: packages/ can the go from experimental/ to testing/ when no open issues persist. This can be used to drive servers. Only packages proven there can go to current/. See http://wiki.opencsw.org/automated-release-process for details. ** The repository is browsable via http://mirror.opencsw.org/opencsw/distribution/ Of course you can subscribe with pkg-get/pkgutil to it, but please be careful as the bandwith it limited to 2 MBit. ** rsync is available. Make sure you don't forget the -H to ** keep hardlinks when syncing! dam at shell [shell]:/home/dam > rsync rsync://mirror.opencsw.org/opencsw- withfreeze drwxr-xr-x 7 2009/10/30 15:34:22 . drwxr-xr-x 416 2009/10/30 13:28:29 allcatalogs drwxrwxr-x 6483 2009/10/28 23:54:53 allpkgs drwxrwxr-x 4 2009/10/28 23:54:46 current drwxr-xr-x 66 2009/10/30 16:57:31 freeze drwxr-xr-x 4 2008/10/24 21:10:13 stable ** TBD: There should be a readme in each freeze stating the changes: Layout README 20091003 ---------------------- Changes 20091003: Added packages: - mypkg-1.0.tar.gz Updated packages: - yourpkg 1.1 replace 1.0 Removed packages: - oldpkg 1.1 Changes 20091002: ... From maciej at opencsw.org Thu Nov 5 18:30:03 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 5 Nov 2009 17:30:03 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) Message-ID: I'm working on the MySQL-5.0.x package. I've reached a stage at which it can be installed and runs, as far as my testing has shown. It still has some rough edges, but it's usable. The package is reworked from the ground up. It contains different binary layout, and different ISAs support. Previously, there were pentium-specific x86 binaries. The new packages conform to our x86 + amd64 standard. I tried the new packages to be similar to the old ones, but some differences were inevitable. I still have things on my TODO list before the package is complete, but I decided to release it at its current state, so that feedback could be provided. Maciej From yann at pleiades.fr.eu.org Thu Nov 5 19:36:14 2009 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 05 Nov 2009 19:36:14 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> Message-ID: <4AF31B1E.80508@pleiades.fr.eu.org> Hi Dago, I successfully used your new system to build distinct packages for different architecture on multiple host and it works perfectly, thanks for your work. However I would like to use it for openssl to build the 64 libs (and not the whole package) on build10x, but I am not sure I understand how to do it. Could you explain me how to do it ? Yann Dagobert Michelsen a ?crit : > Hi, > > I just activated the new Platform build feature ("v2-pbuild") > in GAR. It is available under the regular name gar/v2 in the > repository, the old experimental branch gar/v2-build has been > deleted. A simple > svn update --ignore externals > should be sufficient to update your tree. The new features have > been documented at > > > (see "Prototype Modifiers"). > > Let me know if you encounter anything unusual or feel the docs > need some clarification :-) > > > Best regards > > -- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers From dam at opencsw.org Thu Nov 5 20:41:36 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 5 Nov 2009 20:41:36 +0100 Subject: [csw-maintainers] GAR Tutorial: Building OpenSSL with multiple ISAs In-Reply-To: <4AF31B1E.80508@pleiades.fr.eu.org> References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> <4AF31B1E.80508@pleiades.fr.eu.org> Message-ID: <68E829EC-A951-4D6D-A653-0E472786D6D7@opencsw.org> Hi Yann, Am 05.11.2009 um 19:36 schrieb Yann Rouillard: > I successfully used your new system to build distinct packages for > different architecture on multiple host and it works perfectly, > thanks for your work. > > However I would like to use it for openssl to build the 64 libs (and > not the whole package) on build10x, but I am not sure I understand > how to do it. Could you explain me how to do it ? Sure. I take the liberty of commenting some techniques on your Makefile: > ##################################################################### > # OpenCSW build recipe for OpenSSL > # > # Copyright 2009 Yann Rouillard > # All rights reserved. Use is subject to license terms. > # > # Redistribution and/or use, with or without modification, is > # permitted. This software is without warranty of any kind. The > # author(s) shall not be liable in the event that use of the > # software causes damage. > ##################################################################### > > ###### Package information ####### > > GARNAME = openssl > GARVERSION = 0.9.8k > OPENSSL_VERSION := $(shell echo $(GARVERSION) | sed -e 's/[a-z]//g') > OPENSSL_RELEASE := $(shell echo $(GARVERSION) | sed -e 's/[^a-z]//g') Why not OPENSSL_VESION = 0.9.8 OPENSSL_RELEASE = k GARVERSION = $(OPENSSL_VERSION)$(OPENSSL_RELEASE) But the used version is equally good. > CATEGORIES = lib > > DESCRIPTION = The Open Source toolkit for SSL and TLS > define BLURB > The OpenSSL Project is a collaborative effort to develop a robust, > commercial-grade, fully featured, and Open Source toolkit > implementing the > Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS > v1) as well > as a full-strength general-purpose cryptography library. > endef > > PACKAGES = CSWossl CSWosslrt CSWossldevel CSWosslutils > > SPKG_DESC_CSWossl = Openssl meta package > CATALOGNAME_CSWossl = openssl > REQUIRED_PKGS_CSWossl = CSWossldevel CSWosslutils CSWosslrt > > SPKG_DESC_CSWosslrt = Openssl runtime libraries > CATALOGNAME_CSWosslrt = openssl_rt > REQUIRED_PKGS_CSWosslrt = CSWcacertificates > > SPKG_DESC_CSWossldevel = Openssl development files > CATALOGNAME_CSWossldevel = openssl_devel > REQUIRED_PKGS_CSWossldevel = CSWosslrt > > SPKG_DESC_CSWosslutils = Openssl binaries and related tools > CATALOGNAME_CSWosslutils = openssl_utils > REQUIRED_PKGS_CSWosslutils = CSWosslrt > SPKG_CLASSES_CSWosslutils = none cswpreserveconf > > > ###### Upstream and opencsw files information ####### > > MASTER_SITES = http://www.openssl.org/source/ http://openssl.org/news/ > > # We define upstream file regex so we can be notifed of new upstream > software release > UFILES_REGEX = $(GARNAME)-(\d+(?:\.\d+)*[a-z]?).tar.gz > > DISTNAME = $(GARNAME)-$(GARVERSION) This is default, no need to redefine it. > DISTFILES = $(GARNAME)-$(GARVERSION).tar.gz > DISTFILES += CSWossl.prototype For this there is a more elegant way: dynamic prototypes where you specify the files for a package with regular expressions. This is more robust on version updates. Details can be found at or as practical examples at cd mgar/pkg grep PKGFILES */trunk/Makefile > DISTFILES += CSWosslrt.checkinstall CSWosslrt.preinstall > CSWosslrt.postinstall CSWosslrt.prototype-i386 CSWosslrt.prototype- > sparc > DISTFILES += CSWossldevel.prototype-i386 CSWossldevel.prototype-sparc > DISTFILES += CSWosslutils.prototype > DISTFILES += changelog.CSW README.CSW > > DOCFILES = CHANGES CHANGES.SSLeay PROBLEMS README FAQ README.ASN1 > INSTALL NEWS README.ENGINE > > PATCHFILES = openssl.$(OPENSSL_VERSION).patch > > > ##### Build and installation information ##### > > GARCOMPILER = SOS11 > > # The list of instructions set for which we will > # provide optimized libraries and binaries > EXTRA_BUILD_ISAS_i386 = pentium_pro amd64 > EXTRA_BUILD_ISAS_sparc = sparcv8plus+vis sparcv9 > > # we don't yet use isaexec support so we disable > # isa relocation for default isa > NO_ISAEXEC = 1 > # GAR wants and puts sparcv9 in lib/64 but openssl build system > # isn't the standard autoconf/automake one so we disable this > # relocation for now > ISALIBDIR_sparcv9 = . > libdir = /opt/csw/lib > > # we redefine the default merge exclude so *.a files are not excluded > MERGE_EXCLUDE_DEFAULT = $(MERGE_EXCLUDE_INFODIR) In gar.conf.mk the MERGE_EXCLUDE_DEFAULT is assembled from a list of items excluded by default. If you don't want a specific thing to be excluded it is easier to just clean the specific item you don't want excluded. In your cases this is MERGE_EXCLUDE_STATICLIBS = This way there is no need to adjust the definition when the default changes to exclude other things depending on the general packaging policy. > # The corresponding os/compiler to pass to the > # openssl Configure script > i386_OS_COMPILER = solaris-386-cc > pentium_OS_COMPILER = solaris-pentium-cc > pentium_pro_OS_COMPILER = solaris-pentium_pro-cc > amd64_OS_COMPILER = solaris64-x86_64-cc > > sparcv8_OS_COMPILER = solaris-sparcv8-cc > sparcv8plus_OS_COMPILER = solaris-sparcv9-cc > sparcv8plus+vis_OS_COMPILER = solaris-sparcv9+vis-cc > sparcv9_OS_COMPILER = solaris64-sparcv9-cc > > CONFIGURE_ARGS = --prefix=$(prefix) shared $($(ISA)_OS_COMPILER) -- > install_prefix=$(DESTDIR) > > # We want the csw perl to be used > #CONFIGURE_ENV += PERL="/opt/csw/bin/perl" > # For now we want the sun perl to be used > CONFIGURE_ENV += PERL="/usr/bin/perl" > > # Some optimization > EXT_CFLAGS += -mt -xstrconst > EXT_CXXFLAGS += -noex -mt > > # By default, the install target put man pages under > # /opt/csw/ssl/man, but we want them under /opt/csw/share/man > INSTALL_ARGS += MANDIR=$(mandir) > > # we include previous release of libraries file for comptability > purpose > OLDLIBS = 0.9.7m This can be done with version modulations. You can take a look at some package already implementing this: grep EXTRA_MODULATORS */trunk/Makefile | grep GARVERSION However, you must do a couple of things in different stages right, so I would really consider this an advanced topic. But feel free to take a look and ask if there are any problems :-) > SKIPTEST = 1 I would highly disregard turning tests on OpenSSL off. There were multiple instances where missing Sun Studio patches and too high optimization levels caused errors which were detected by the testsuite. If you don't want to wait for tests please do something like SKIPTEST=1 gmake package If we switch to automatic builds some time in the future running the testsuite will a good thing. If there are no tests define TEST_SCRIPTS = do indicate that there are no tests but the test-phase should be run. > # support for pkcs11 engine http://blogs.sun.com/chichang1/entry/how_to_integrate_pkcs11_engine > ifdef PKCS11 > PATCHFILES += pkcs11_engine-0.9.8h.patch.2008-07-29 > ifeq ($(GARCH),sparc) > ifeq ($(ISA),sparcv9) > CONFIGURE_ARGS += --pk11-libname=/usr/lib/ > sparcv9/libpkcs11.so > else > CONFIGURE_ARGS += --pk11-libname=/usr/lib/ > libpkcs11.so > endif > else > ifeq ($(ISA),amd64) > CONFIGURE_ARGS += --pk11-libname=/usr/lib/ > sparcv9/libpkcs11.so > else > CONFIGURE_ARGS += --pk11-libname=/usr/lib/ > libpkcs11.so > endif > endif Instead of this nested ifeqs you could simple write CONFIGURE_ARGS += --pk11-libname=$(abspath /usr/lib/$(MM_LIBDIR)) This expands to either '.' for 32 bit or '64' for 64 bit which is guaranteed to be linked to the arch-specific 64 bit dir sparcv9/ or amd64/. > endif > > include gar/category.mk > > > pre-configure-modulated: > echo " ==> Creating configure script" > cd $(WORKSRC) && ln -nf Configure configure > @$(MAKECOOKIE) > > # we remove every debug information except symbol table > # (should rather be done in the gar scripts) > post-install-modulated: > echo " ==> Stripping libraries" > chmod -R u+w $(DESTDIR)$(libdir) > find $(DESTDIR)$(libdir) -name "*.so*" -exec strip -x '{}' ';' > > install-changelog: > ginstall -D $(WORKROOTDIR)/build-$(firstword $(MODULATIONS))/ > changelog.CSW $(SPKG_PKGBASE)/changelog.CSW > @$(MAKECOOKIE) > > install-doc: > cd $(WORKSRC_FIRSTMOD)/ && ginstall $(DOCFILES) $ > (SPKG_PKGBASE)/ > ginstall -D $(WORKROOTDIR)/build-$(firstword $(MODULATIONS))/ > README.CSW $(SPKG_PKGBASE)/README.CSW > @$(MAKECOOKIE) > > install-certs: > [ -f $(PKGROOT)$(prefix)/ssl/openssl.cnf ] && \ > ginstall -D $(PKGROOT)$(prefix)/ssl/openssl.cnf $ > (PKGROOT)$(sysconfdir)/ssl/openssl.cnf.CSW > > install-oldlibs: $(addprefix install-oldlibs-,$(OLDLIBS)) > install-oldlibs-%: > @echo " ==> Installing old libraries $* from archive oldlibs. > $*-$(GARCH).tar.gz" > cd $(PKGROOT) && gunzip -c $(CURDIR)/$(FILEDIR)/oldlibs.$*-$ > (GARCH).tar.gz | tar xvf - > @$(MAKECOOKIE) > > post-merge: install-certs install-oldlibs install-changelog install- > doc Now your question again: > However I would like to use it for openssl to build the 64 libs (and > not the whole package) on build10x, but I am not sure I understand > how to do it. Could you explain me how to do it ? The manual process is build8x: gmake merge (builds 32 bit ISAs) build10x: gmake merge (builds 64 bit ISA) build8x: gmake package (assembles the package) With the new platform support you can just say build8x> gmake package and GAR automatically hops over to the server capable of building the ISA. All ISAs build in work//build-isa- and install to work//install-isa- These directories contain everything from 'make install' from each build. Now during the merge-phase an image of all packages to be built is assembled in work//pkgroot This is done during the merge phase. I talked about this in Oslo, slides linked from here: https://sourceforge.net/apps/trac/gar/wiki/Learning%20the%20details If you only want the libs you restrict the directories to be merged to the libdir: MERGE_DIRS_isa-extra = $(libdir) For examples see fftw or glpk or grep isa-extra */trunk/Makefile Don't hesitate to ask if you have further questions :-) Best regards -- Dago From ihsan at opencsw.org Thu Nov 5 20:51:11 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Thu, 05 Nov 2009 20:51:11 +0100 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: Message-ID: <4AF32CAF.1030805@opencsw.org> Hello Maciej, Am 5.11.2009 18:30 Uhr, Maciej (Matchek) Blizinski schrieb: > I'm working on the MySQL-5.0.x package. I've reached a stage at which > it can be installed and runs, as far as my testing has shown. It > still has some rough edges, but it's usable. Thank you very much for the updated packages. I'm installing them now in the new Database zone for the mail and web server. Is there any reason not to upgrade to 5.1? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Thu Nov 5 22:12:00 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 5 Nov 2009 21:12:00 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <4AF32CAF.1030805@opencsw.org> References: <4AF32CAF.1030805@opencsw.org> Message-ID: On Thu, Nov 5, 2009 at 7:51 PM, Ihsan Dogan wrote: > Hello Maciej, > > Am 5.11.2009 18:30 Uhr, Maciej (Matchek) Blizinski schrieb: > >> I'm working on the MySQL-5.0.x package. ?I've reached a stage at which >> it can be installed and runs, as far as my testing has shown. ?It >> still has some rough edges, but it's usable. > > Thank you very much for the updated packages. I'm installing them now in > the new Database zone for the mail and web server. > > Is there any reason not to upgrade to 5.1? There's no fundamental problem with it; the reason to work with 5.0 for now is that I want to focus on packaging alone at the moment. Once the packaging for 5.0.x is done, we'll move on and build 5.1. Maciej From ihsan at opencsw.org Thu Nov 5 22:25:50 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Thu, 05 Nov 2009 22:25:50 +0100 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: Message-ID: <4AF342DE.2020604@opencsw.org> Hello Maciej, Am 5.11.2009 18:30 Uhr, Maciej (Matchek) Blizinski schrieb: > I still have things on my TODO list before the package is complete, > but I decided to release it at its current state, so that feedback > could be provided. The script /opt/csw/mysql5/share/mysql/quick_start-csw should mention OpenCSW instead Denis' company. Same applies for /opt/csw/mysql5/share/mysql/doc/README.CSW . The init script tries to create the pid file in /opt/csw/mysql5/var. I think this should be either changed to $MYSQLD_DATADIR/mysql.pid. But besides that, it seems to work fine. :-) I'm wondering if it makes sense to build an optimized Solaris 10 binary with the optimisations mentioned on http://developers.sun.com/solaris/articles/mysql_perf_tune.html . Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Thu Nov 5 22:31:07 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Thu, 05 Nov 2009 22:31:07 +0100 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF32CAF.1030805@opencsw.org> Message-ID: <4AF3441B.6030006@opencsw.org> Am 5.11.2009 22:12 Uhr, Maciej (Matchek) Blizinski schrieb: >>> I'm working on the MySQL-5.0.x package. I've reached a stage at which >>> it can be installed and runs, as far as my testing has shown. It >>> still has some rough edges, but it's usable. >> Thank you very much for the updated packages. I'm installing them now in >> the new Database zone for the mail and web server. >> >> Is there any reason not to upgrade to 5.1? > There's no fundamental problem with it; the reason to work with 5.0 > for now is that I want to focus on packaging alone at the moment. Once > the packaging for 5.0.x is done, we'll move on and build 5.1. I see. Makes sense. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From phil at bolthole.com Fri Nov 6 00:55:03 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 5 Nov 2009 15:55:03 -0800 Subject: [csw-maintainers] comment/warning about sun studio 12.1 Message-ID: FYI, I read the following on a sun mailing list,and thought I should share the horror: ---------- What is "Sun Studio 12 update 1" and where did it come from? Sun Studio 12 update 1 is the latest major release of Sun Studio. The previous major release was Sun Studio 12. It is a completely different compiler from Sun Studio 12. SS12u1 has it's own patch stream that is disjoint from the patch stream for SS12. It took two years of effort by a large team of people to produce it. By all logic it should have been called Sun Studio 13, but management and marketing made a different choice. If SS12 was also available in the repo, users would need to be able to install both SS12 and SS12u1 at the same time to migrate their code gracefully. -------------- So... just be aware, and cautious, when the issue comes up. and as a final comment from that author: "The C compiler [itself, as in "cc -V"...] does have a sensible numeric-only version number that is monotonically increasing. (5.9 for SS12, 5.10 for SS12u1, and 5.11 for whatever is in SSnext.)" From phil at bolthole.com Fri Nov 6 00:58:38 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 5 Nov 2009 15:58:38 -0800 Subject: [csw-maintainers] Preview of the new mirror structure available In-Reply-To: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> References: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> Message-ID: On Thu, Nov 5, 2009 at 8:16 AM, Dagobert Michelsen wrote: > Hi, > > I did some work towards the enhanced directory structure for the mirror > we talked about. ... Hmm.. that was a bit difficult to follow. might be nice if you wrote it up somewhere online (yeah, that thing you hate doing, "mr. secretary" ;-) and perhaps described/summarized the directories with a condensed format, such as opencsw/experimental -- blahblah opencsw/testing -- blahaaaahh opencsw/distribution -- blah blah Maybe if you like, have that as the initial summary, then dig down more, lower down in the document? From phil at bolthole.com Fri Nov 6 01:00:35 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 5 Nov 2009 16:00:35 -0800 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <4AF342DE.2020604@opencsw.org> References: <4AF342DE.2020604@opencsw.org> Message-ID: On Thu, Nov 5, 2009 at 1:25 PM, Ihsan Dogan wrote: > > > I'm wondering if it makes sense to build an optimized Solaris 10 binary > with the optimisations mentioned on > http://developers.sun.com/solaris/articles/mysql_perf_tune.html . > > I would accept a multi-OS release set, if this effort were made (grmblegrumble) that is to say, like openssh, if you offered a sol [8/9] compiled package, and in addition, a separate sol10 compiled and optimized package. From trygvis at opencsw.org Fri Nov 6 07:54:38 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Fri, 06 Nov 2009 07:54:38 +0100 Subject: [csw-maintainers] comment/warning about sun studio 12.1 In-Reply-To: References: Message-ID: <4AF3C82E.5040303@opencsw.org> Philip Brown wrote: > FYI, I read the following on a sun mailing list,and thought I should > share the horror: > > > ---------- > > What is "Sun Studio 12 update 1" and where did it come from? > > Sun Studio 12 update 1 is the latest major release of Sun Studio. > The previous major release was Sun Studio 12. It is a completely > different compiler from Sun Studio 12. SS12u1 has it's own patch > stream that is disjoint from the patch stream for SS12. > It took two years of effort by a large team of people to produce it. > By all logic it should have been called Sun Studio 13, but management > and marketing made a different choice. If SS12 was also available > in the repo, users would need to be able to install both SS12 and SS12u1 > at the same time to migrate their code gracefully. > > -------------- Hey, that's just like Java! :D [snip} -- Trygve From dam at opencsw.org Fri Nov 6 09:37:04 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 6 Nov 2009 09:37:04 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <25FB7213-E65F-4115-8DC9-50D57113E275@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> Message-ID: <8853603E-D4FD-4534-8D3C-5781B3FC4286@opencsw.org> Hi Ihsan, Am 04.11.2009 um 22:16 schrieb Dagobert Michelsen: > Am 04.11.2009 um 16:47 schrieb Ihsan Dogan: >>>>> Than I'd love to take a look and allow >>>>> gmake platforms >>>>> to automatically build packages for all 4 platforms without >>>>> intervention. >>>> Something does not work yet. The Solaris 8 x86 package was built, >>>> but >>>> the Solaris 10 package fails: >>>> >>>> gmake: warning: Clock skew detected. Your build may be >>>> incomplete. >>>> gmake: Leaving directory `/home/ihsan/gar/csw/mgar/pkg/unbound/ >>>> trunk' >>>> Connection to build8x closed. >>>> bash: gmake: command not found >>>> Connection to build10s closed. >>>> gmake: *** [platforms] Error 127 >>> Ok, what command have you issued at what host? >> >> "gmake platforms" on build8s. Same happens on build10s. > > I can reproduce it: > >> gmake: Leaving directory `/home/dam/mgar/pkg/unbound/trunk' >> Connection to build8x closed. >> zsh: command not found: gmake >> Connection to build10s closed. > > I'll have a closer look tomorrow. The problem lies in the different configuration files for the shells. You use a bash, I use a zsh. As there is no real global configuration file that works with all shells I now appended /opt/csw/bin to the PATH when hopping over to another server. I just verified and commited as r7139 with your account :-) Best regards -- Dago From maciej at opencsw.org Fri Nov 6 11:43:59 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 6 Nov 2009 10:43:59 +0000 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: Message-ID: On Tue, Sep 15, 2009 at 6:14 PM, Maciej (Matchek) Blizinski wrote: > On Fri, Sep 11, 2009 at 5:04 PM, Philip Brown wrote: >> well,, there are multiple potential "issues" at play here. >> on the one hand, I understand your frustration at not having it >> normally in the path. >> But what would be the side effects of having a symlink >> /opt/csw/bin/mysql -> /opt/csw/mysql5/bin/mysql ? > > I was thinking about this... what if someone has mysql4 also > installed? I would like to rant a bit more about the nonstandard prefix. Yes, one might want to have both mysql4 and mysql5 installed. I don't know about mysql4, but the mysql5 package currently installs following symlinks: /opt/csw/lib/mysql --> ../mysql5/lib/mysql /opt/csw/include/mysql --> ../mysql5/include/mysql If mysql4 does the same, the two packages can't peacefully coexist. If mysql4 does not install the /opt/csw/lib/mysql symlink, why has mysql5 to? My way of thinking would be: There should be one canonical MySQL version for OpenCSW, which is being installed in /opt/csw. If there are other versions, say, legacy versions, they can be installed in different prefixes, but they are not allowed to install anything that conflicts with the canonical package. Having said that, I am going to continue to use /opt/csw/mysql5 for the mysql5 package. > Perhaps some sort of "switch" app, which would change the > symlinks, would be good. I need to think about it some more. Yes, it would be a nice thing to have. We could review existing solutions. I know that some Linux distributions already have implementations for such switches. Perhaps it's a good idea to look at them? Maciej From maciej at opencsw.org Fri Nov 6 11:51:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 6 Nov 2009 10:51:58 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> Message-ID: On Fri, Nov 6, 2009 at 12:00 AM, Philip Brown wrote: > On Thu, Nov 5, 2009 at 1:25 PM, Ihsan Dogan wrote: >> >> >> I'm wondering if it makes sense to build an optimized Solaris 10 binary >> with the optimisations mentioned on >> http://developers.sun.com/solaris/articles/mysql_perf_tune.html . >> >> > > I would accept a multi-OS release set, if this effort were made (grmblegrumble) > > that is to say, like openssh, if you offered a sol [8/9] compiled > package, and in addition, a separate sol10 compiled and optimized > package. Yes, it makes sense. Once the package is satisfactory in the basic form, we can go ahead and try add the optimization flags. Meanwhile, I started looking at the included unit tests. I don't know if the package was passing the tests previously, but I think it's a good idea to have all the unit tests pass. I suspect that the tests will need some porting or adjusting to Solaris. The first problem I'm seeing is: binlog_start_comment [ fail ] mysqltest: At line 13: query 'load data infile '../std_data_ln/words.dat' into table t1 -- load data to t1' failed: 1085: The file '/export/home/blizinski/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/build-isa-i386/mysql-5.0.84/mysql-test/var/std_data_ln/words' must be in the database directory or be readable by all The result from queries just before the failure was: reset master; drop table if exists t1,t2; create table t1 (word varchar(20)) -- create table t1; create table t2 (word varchar(20)) -- create table t2; load data infile '../std_data_ln/words.dat' into table t1 -- load data to t1; More results from queries before failure can be found in /export/home/blizinski/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/build-isa-i386/mysql-5.0.84/mysql-test/var/log/binlog_start_comment.log Aborting: binlog_start_comment failed in default mode. To continue, re-run with '--force'. Stopping All Servers gmake: *** [test-ns] Error 1 gmake: Leaving directory `/export/home/blizinski/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/build-isa-i386/mysql-5.0.84' Do people know if those tests were passing before and what has been done to make them pass? Maciej From maciej at opencsw.org Fri Nov 6 16:43:51 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 6 Nov 2009 15:43:51 +0000 Subject: [csw-maintainers] svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums' Message-ID: I have problems checking out the current svn tree: $ cd pkg $ svn up --ignore-externals (...) U pkg/openssl/trunk/Makefile svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums'; expected: 'd41d8cd98f00b204e9800998ecf8427e', actual: '176e3d3f8ba8154305a5c9628b05db03' Has anyone else encounter this problem? From dam at opencsw.org Fri Nov 6 16:53:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 6 Nov 2009 16:53:02 +0100 Subject: [csw-maintainers] svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums' In-Reply-To: References: Message-ID: Hi Maciej, Am 06.11.2009 um 16:43 schrieb Maciej (Matchek) Blizinski: > I have problems checking out the current svn tree: > > $ cd pkg > $ svn up --ignore-externals > (...) > U pkg/openssl/trunk/Makefile > svn: Checksum mismatch for > 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums'; expected: > 'd41d8cd98f00b204e9800998ecf8427e', actual: > '176e3d3f8ba8154305a5c9628b05db03' > > Has anyone else encounter this problem? Yes: > A bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED > svn: Checksum mismatch for 'bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/ > checksums'; expected: 'd41d8cd98f00b204e9800998ecf8427e', actual: > '176e3d3f8ba8154305a5c9628b05db03' This sucks. I guess it is time to open a ticket at SourceForge. Maciej, would you be so kind? I have to hurry to get my train back home. Best regards -- Dago From phil at bolthole.com Fri Nov 6 19:21:56 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 6 Nov 2009 10:21:56 -0800 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> Message-ID: On Fri, Nov 6, 2009 at 2:51 AM, Maciej (Matchek) Blizinski wrote: > > > Do people know if those tests were passing before and what has been > done to make them pass? when in doubt of facts.. verify them! :-) I think you should be able to run the tests on the old binaries if you install the old packages. and in fact, some of the packages might even include the tests. but not 100% sure. From phil at bolthole.com Fri Nov 6 19:25:58 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 6 Nov 2009 10:25:58 -0800 Subject: [csw-maintainers] X11 linkage problem strategy In-Reply-To: References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> Message-ID: On Thu, Nov 5, 2009 at 2:08 AM, Dagobert Michelsen wrote: > Hi Phil, > *wave* > Am 04.11.2009 um 22:28 schrieb Philip Brown: >>... >> Technically, we dont need to require *everything* of ours that uses >> X11. But pretty close. >> >> Pretty much anything of ours that touches gnome libs... or anything of >> ours that is touched BY something that touches gnome libs... will need >> to be relinked now, I think :-( > > It may be worthwhile to avoid this X11 dependency when we start with > OpenSolaris > or even Solaris 10. > I didnt quite understand what you meant here? From bwalton at opencsw.org Fri Nov 6 19:33:50 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 06 Nov 2009 13:33:50 -0500 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> Message-ID: <1257532118-sup-3145@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Nov 06 05:51:58 -0500 2009: > Meanwhile, I started looking at the included unit tests. I don't know > if the package was passing the tests previously, but I think it's a The set of failing tests is likely different, but I was finding issues with the 5.1 stuff when I looked at it. I do remember that the tests failing on i386 were different than those on sparc. > good idea to have all the unit tests pass. I suspect that the tests > will need some porting or adjusting to Solaris. The first problem I'm > seeing is: ...which is sad since this is a sun product. That is unless one of the opencsw libs it links against is causing the problems, anyway. > Do people know if those tests were passing before and what has been > done to make them pass? I don't know what the previous state of affairs was wrt this...Phil is right that it might be verifiable. Alternately, the old build could be redone without the packaging to see if the test suite was passing or not. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Nov 6 19:52:44 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 6 Nov 2009 10:52:44 -0800 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <1257532118-sup-3145@ntdws12.chass.utoronto.ca> References: <4AF342DE.2020604@opencsw.org> <1257532118-sup-3145@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 6, 2009 at 10:33 AM, Ben Walton wrote: > > I don't know what the previous state of affairs was wrt this...Phil is > right that it might be verifiable. ?Alternately, the old build could > be redone without the packaging to see if the test suite was passing > or not. > I'll also mention that mysql has historically been very picky about compiler optimization choices. When in serious doubt, compile with -xO0, and see if it mysteriously passes the tests. From bwalton at opencsw.org Fri Nov 6 19:58:53 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 06 Nov 2009 13:58:53 -0500 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> <1257532118-sup-3145@ntdws12.chass.utoronto.ca> Message-ID: <1257533883-sup-9466@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Nov 06 13:52:44 -0500 2009: > I'll also mention that mysql has historically been very picky about > compiler optimization choices. That's interesting. Thanks for sharing. If I get a few minutes tonight I'll try that with the 5.1 branch. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Nov 6 20:18:57 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 6 Nov 2009 11:18:57 -0800 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: Message-ID: On Fri, Nov 6, 2009 at 2:43 AM, Maciej (Matchek) Blizinski wrote: > ... > > I would like to rant a bit more about the nonstandard prefix. ?.. > > /opt/csw/lib/mysql --> ../mysql5/lib/mysql > /opt/csw/include/mysql --> ../mysql5/include/mysql > > If mysql4 does the same, the two packages can't peacefully coexist. If > mysql4 does not install the /opt/csw/lib/mysql symlink, why has mysql5 > to? > I think the idea there was that mysql5 was officially the "default mysql". That being said... we should probably discuss further, possibilities of more default mysql "presence" in the top level $PREFIX=/opt/csw style. And how to implement that. For example, while the back end DATABASE ENGINE, probably is best off in separate prefixland, client-side things are relatively binary compatible (or are they?) at the very least, having /opt/csw/bin/mysql (the client) -> /opt/csw/mysql5/bin/mysql is probably pretty safe. There can then be questions about whether symlinks for libraries in /opt/csw/lib would be appropriate. And then the question of whether to implement the links in the mysql5(_client/_rt) packages, or whether to have a "metapackage". > My way of thinking would be: There should be one canonical MySQL > version for OpenCSW, which is being installed in /opt/csw. If there > are other versions, say, legacy versions, they can be installed in > different prefixes, but they are not allowed to install anything that > conflicts with the canonical package. > > Having said that, I am going to continue to use /opt/csw/mysql5 for > the mysql5 package. Good :) Because handling renames/relocations, when things are not properly binary compatible, is a nightmare. From dam at opencsw.org Fri Nov 6 21:22:54 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 6 Nov 2009 21:22:54 +0100 Subject: [csw-maintainers] X11 linkage problem strategy In-Reply-To: References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> Message-ID: <7E0C2B9F-55DF-466D-B02B-ABAD4D340ECD@opencsw.org> Hi Phil, Am 06.11.2009 um 19:25 schrieb Philip Brown: > On Thu, Nov 5, 2009 at 2:08 AM, Dagobert Michelsen > wrote: >> Hi Phil, >> > > *wave* > >> Am 04.11.2009 um 22:28 schrieb Philip Brown: >>> ... >>> Technically, we dont need to require *everything* of ours that uses >>> X11. But pretty close. >>> >>> Pretty much anything of ours that touches gnome libs... or >>> anything of >>> ours that is touched BY something that touches gnome libs... will >>> need >>> to be relinked now, I think :-( >> >> It may be worthwhile to avoid this X11 dependency when we start with >> OpenSolaris >> or even Solaris 10. >> > > I didnt quite understand what you meant here? I mean that we may not need our own X11 when building packages for OpenSolaris in the future. Best regards -- Dago From ihsan at opencsw.org Fri Nov 6 21:34:56 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Fri, 06 Nov 2009 21:34:56 +0100 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <8853603E-D4FD-4534-8D3C-5781B3FC4286@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> Message-ID: <4AF48870.2040308@opencsw.org> Hello Dago, Am 6.11.2009 9:37 Uhr, Dagobert Michelsen schrieb: >>> gmake: Leaving directory `/home/dam/mgar/pkg/unbound/trunk' >>> Connection to build8x closed. >>> zsh: command not found: gmake >>> Connection to build10s closed. >> I'll have a closer look tomorrow. > The problem lies in the different configuration files for the shells. > You use > a bash, I use a zsh. As there is no real global configuration file that > works > with all shells I now appended /opt/csw/bin to the PATH when hopping > over to > another server. I just verified and commited as r7139 with your account :-) Thank you very much for fixing it. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Fri Nov 6 21:44:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 6 Nov 2009 20:44:01 +0000 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: Message-ID: On Fri, Nov 6, 2009 at 7:18 PM, Philip Brown wrote: > For example, while the back end DATABASE ENGINE, probably is best off > in separate prefixland, client-side things are relatively binary > compatible (or are they?) > > at the very least, having /opt/csw/bin/mysql (the client) ?-> > /opt/csw/mysql5/bin/mysql is probably pretty safe. That's what my new mysql5 package does. > There can then be questions about whether symlinks for libraries in > /opt/csw/lib would be appropriate. There is such symlink in the current mysql5 package, but I think that the database can do perfectly fine without it. Perhaps it was about compiling other, mysql-dependent software. Do you think it's better to keep the symlink or to remove it? I'm inclined to do the latter. Maciej From bwalton at opencsw.org Fri Nov 6 21:53:18 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 06 Nov 2009 15:53:18 -0500 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: Message-ID: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Nov 06 15:44:01 -0500 2009: > Do you think it's better to keep the symlink or to remove it? I'm > inclined to do the latter. I'd keep it. Somebody, somewhere, has a script that doesn't include /opt/csw/mysql5/bin in the PATH and relies on finding those symlinks. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Nov 6 22:33:24 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 6 Nov 2009 13:33:24 -0800 Subject: [csw-maintainers] X11 linkage problem strategy In-Reply-To: <7E0C2B9F-55DF-466D-B02B-ABAD4D340ECD@opencsw.org> References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> <7E0C2B9F-55DF-466D-B02B-ABAD4D340ECD@opencsw.org> Message-ID: On Fri, Nov 6, 2009 at 12:22 PM, Dagobert Michelsen wrote: >>... >> I didnt quite understand what you meant here? > > I mean that we may not need our own X11 when building packages for > OpenSolaris in the future. > > ah. well that goes back to the old, foundational issue of, "is it sane to attempt to support two codebases, via the same support system?" The answer I always found, was "no". due to supportability issues. and then it gets back to what Dennis was SUPPOSEDLY going to do, and split off a mirror tree dedicated to opensolaris based packages. Which does actually make sense. If people want to put in the split effort. Too bad Dennis decided he wanted to try to take everyone with him to the new one, rather than do a fair split of effort. From maciej at opencsw.org Sat Nov 7 00:43:26 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 6 Nov 2009 23:43:26 +0000 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 6, 2009 at 8:53 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Fri Nov 06 15:44:01 -0500 2009: > >> Do you think it's better to keep the symlink or to remove it? I'm >> inclined to do the latter. > > I'd keep it. ?Somebody, somewhere, has a script that doesn't include > /opt/csw/mysql5/bin in the PATH and relies on finding those symlinks. I think we are talking about different symlinks. The symlinks I'm thinking of removing is: /opt/csw/lib/mysql --> /opt/csw/mysql5/lib/mysql I can hardly see any use for it. It's not a symlink for binaries, only libraries. The symlinks to binaries, such as /opt/csw/bin/mysql --> /opt/csw/mysql5/bin/mysql, don't exist in the current package. I'm planning on including them in the new version of the package. Maciej From jeff at cjsa.com Sat Nov 7 05:51:08 2009 From: jeff at cjsa.com (Jeffery Small) Date: Sat, 7 Nov 2009 04:51:08 GMT Subject: [csw-maintainers] Library problems with gnome apps Message-ID: Hi: I was away for two and a half weeks. When I returned there were many new packages released. I have not installed everything, but I did upgrade some of the stand-alone applications and a few libraries upon which they relied. Now, I am finding that my firefox 3.5.3 and 3.5.5 browsers will not operate properly. These are the releases from the mozilla contrib website and were working fine previously. The browers now hang completely at any number of operations, the brower's pull-down menus will not display and most buttons do not operate. This is running on the native Solaris 10 gnome desktop on a SPARC system. I seem to remember a similar problem developing along these lines in the recent past, so I have some suspicion that it is related to the CSW upgrade. Here is a list of the packages I currently have NOT yet upgraded: ------------------------------------------------------------------------------- berkeleydb 4.7.25,REV=2009.07.01 4.7.25,REV=2009.10.18 berkeleydb3 3.3.11,REV=2009.07.22 3.3.11,REV=2009.10.18_rev=p2 berkeleydb4 4.2.52,REV=2005.04.28_rev=p4 4.2.52,REV=2009.10.18 berkeleydb44 4.4.20,REV=2009.07.28 4.4.20,REV=2009.10.18_rev=p4 curlrt 7.19.6,REV=2009.08.13 7.19.7,REV=2009.11.05 dbus 1.2.12,REV=2009.03.25 1.2.12,REV=2009.08.10 freetype2 2.3.8,REV=2009.02.16 2.3.9,REV=2009.09.11 fribidi 0.10.7 0.19.2,REV=2009.10.07 gdome2 0.8.1 0.8.1,REV=2009.09.11 jbig2dec 0.10,REV=2009.06.28 0.10,REV=2009.09.13 libcairo 1.8.6,REV=2009.06.25 1.8.8,REV=2009.09.15 libcroco 0.6.1 0.6.2,REV=2009.10.09 libdbus 1.2.12,REV=2009.03.25 1.2.12,REV=2009.08.10 libflac 1.2.1,REV=2009.04.09 1.2.1,REV=2009.09.05 libmad 0.15.1,REV=2005.03.26_rev=b 0.15.1b,REV=2009.10.29 libpango 1.24.3,REV=2009.07.09 1.24.5,REV=2009.09.04 libpcap 0.9.4,REV=2006.02.24sparconly 1.0.0,REV=2009.10.01 libpopt 1.14,REV=2009.02.24 1.15,REV=2009.10.29 libtasn1 2.1,REV=2009.04.17 2.2,REV=2009.11.05 libtheora 1.0,REV=2009.04.15 1.1.1,REV=2009.10.29 libtool 2.2.6,REV=2009.03.23_rev=a 2.2.6,REV=2009.09.04_rev=a libtool_rt 2.2.6,REV=2009.03.23_rev=a 2.2.6,REV=2009.09.04_rev=a libungif 4.1.4,REV=2007.02.05 4.1.6,REV=2009.09.24 sqlite3 3.6.10,REV=2009.03.28 3.6.19,REV=2009.10.29 sqlite3_rt 3.6.10,REV=2009.03.28 3.6.19,REV=2009.10.29 ------------------------------------------------------------------------------- Also, I still see the berkeleydb packages here, but there is STILL no updated sendmail package. I broke my sendmail the last time I tried to update the database packages and am still wondering if this compatibility issue has been addressed. I also see the dbus package. There has been an outstanding issue that keeps Solaris from properly shutting down as the dbus service cannot be stopped. Has that issue been addressed with this dbus release? These are both long-standing issues and I am wondering why I have not heard about their successful resolution. Did I miss some important discussions during the past few weeks? Thanks for any light you can shed on these issues. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From rupert at opencsw.org Sat Nov 7 10:36:01 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 7 Nov 2009 10:36:01 +0100 Subject: [csw-maintainers] svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums' In-Reply-To: References: Message-ID: <6af4270911070136j7b49d0c6wa2e50c4b2ae53f56@mail.gmail.com> On Fri, Nov 6, 2009 at 16:53, Dagobert Michelsen wrote: > Hi Maciej, > > Am 06.11.2009 um 16:43 schrieb Maciej (Matchek) Blizinski: > > I have problems checking out the current svn tree: >> >> $ cd pkg >> $ svn up --ignore-externals >> (...) >> U pkg/openssl/trunk/Makefile >> svn: Checksum mismatch for >> 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums'; expected: >> 'd41d8cd98f00b204e9800998ecf8427e', actual: >> '176e3d3f8ba8154305a5c9628b05db03' >> >> Has anyone else encounter this problem? >> > > Yes: > > A bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED >> svn: Checksum mismatch for >> 'bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums'; expected: >> 'd41d8cd98f00b204e9800998ecf8427e', actual: >> '176e3d3f8ba8154305a5c9628b05db03' >> > > This sucks. I guess it is time to open a ticket at SourceForge. Maciej, > would you be so kind? I have to hurry to get my train back home. > > > can we delete the tag in the repository itself by doing something like "svn rm https://.../bdb3/tags/..." ? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at opencsw.org Sat Nov 7 12:45:04 2009 From: james at opencsw.org (James Lee) Date: Sat, 07 Nov 2009 11:45:04 GMT Subject: [csw-maintainers] Preview of the new mirror structure available In-Reply-To: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> References: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> Message-ID: <20091107.11450400.3207873259@gyor.oxdrove.co.uk> On 05/11/09, 16:16:42, Dagobert Michelsen wrote regarding [csw-maintainers] Preview of the new mirror structure available: Is this a preview or a proposal? > opencsw/ > experimental/ > / > pkgs/ (confined to this directory) > mytest.pkg.gz > sparc/ > 5.8/ > mytest.pkg.gz (hardlinked to pkgs/mytest.pkg.gz) > testing/ > pkgs/ > sparc/ > 5.8/ Too complex and risky to be of any use to *users*. > distribution/ > allcatalogs/ > catalog-sparc-5.8-20091002 > allpkgs/ > mypkg.tar.gz This looks as if your proposal is to formalise the retention of all packages and catalogues (a collection's state). At first this seems like a good idea but think deeper and you will see that if all catalogues are kept there is no way of knowing which are erroneous, hence they all become useless. Actually there is a way of knowing because we keep the known good sets as stable releases which is already handled. > stable/ > sparc/ > 5.8/ > current/ > sparc/ > 5.8/ > pkg.tar.gz (also hardlinked from allpkgs) > freeze/ > current-20091002/ > README.20091002 > sparc/ > 5.8/ > catalog > pkg.tar.gz (hardlinked from allpkgs) > 5.9/ > pkg.tar.gz (symlinked to 5.8, same as in current/) This misunderstands the WIP nature of the snapshot process. The freeze is on unstable, it's not an entity it's unstable itself that is frozen. > ** TBD: experimental/ should be filled with the subdirectories from > what is now in testing/. > Subdirectories can be created by each maintainer and for each > folder a subproject > is created in experimental which can be synced to separately. > ** TBD: packages/ can the go from experimental/ to testing/ when no > open issues persist. How will you define "no open issues persist"? > This can be used to drive servers. Only packages proven there can > go to current/. See > http://wiki.opencsw.org/automated-release-process > for details. Here you draw parity to the Debian system. Previous discussion concluded the levels you show are not correct. "How stuff gets in there", conceptually and practically it doesn't because stable is a modified clone of another state done as an atomic operation. I feel we've lost sight of the aims of the proposal. James. From bwalton at opencsw.org Sat Nov 7 14:26:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 07 Nov 2009 08:26:12 -0500 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: <1257600163-sup-9626@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Nov 06 18:43:26 -0500 2009: > I think we are talking about different symlinks. The symlinks I'm > thinking of removing is: > > /opt/csw/lib/mysql --> /opt/csw/mysql5/lib/mysql Yes, sorry. I was talking about the bin/ symlinks. 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 Sat Nov 7 17:47:57 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 7 Nov 2009 16:47:57 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <4AF342DE.2020604@opencsw.org> References: <4AF342DE.2020604@opencsw.org> Message-ID: On Thu, Nov 5, 2009 at 9:25 PM, Ihsan Dogan wrote: > The script /opt/csw/mysql5/share/mysql/quick_start-csw should mention > OpenCSW instead Denis' company. Same applies for > /opt/csw/mysql5/share/mysql/doc/README.CSW . I split this document into a README.CSW and ChangeLog. I didn't want to change the existing text from Alex Moore. I added my own updates. > The init script tries to create the pid file in /opt/csw/mysql5/var. I > think this should be either changed to $MYSQLD_DATADIR/mysql.pid. I think I fixed it. Can you check? Updates packages are in testing/. Maciej From ihsan at opencsw.org Sat Nov 7 18:40:20 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sat, 07 Nov 2009 18:40:20 +0100 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> Message-ID: <4AF5B104.90307@opencsw.org> Hello Maciej, Am 7.11.2009 17:47 Uhr, Maciej (Matchek) Blizinski schrieb: >> The init script tries to create the pid file in /opt/csw/mysql5/var. I >> think this should be either changed to $MYSQLD_DATADIR/mysql.pid. > I think I fixed it. Can you check? Updates packages are in testing/. I just installed it and it works out of the box. mysql5test requires Perl, but it's not a dependency of mysql5test. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Sun Nov 8 11:04:36 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 8 Nov 2009 11:04:36 +0100 Subject: [csw-maintainers] Library problems with gnome apps In-Reply-To: References: Message-ID: Hi Jeffery, Am 07.11.2009 um 05:51 schrieb Jeffery Small: > I was away for two and a half weeks. When I returned there were > many new > packages released. I have not installed everything, but I did > upgrade some > of the stand-alone applications and a few libraries upon which they > relied. > Now, I am finding that my firefox 3.5.3 and 3.5.5 browsers will not > operate > properly. These are the releases from the mozilla contrib website > and were > working fine previously. The browers now hang completely at any > number of > operations, the brower's pull-down menus will not display and most > buttons > do not operate. This is running on the native Solaris 10 gnome > desktop on > a SPARC system. > > I seem to remember a similar problem developing along these lines in > the recent past, so I have some suspicion that it is related to the > CSW > upgrade. I also remember this, but only found this post in my mailbox. It may or may not be related to your problem, but you should check the bound libraries with ldd on the running process that no /opt/csw stuff is bound. > Anfang der weitergeleiteten E-Mail: > >> Von: "wrcarithers" >> Datum: 28. Juli 2009 17:52:53 MESZ >> An: solarisx86 at yahoogroups.com >> Betreff: [solarisx86] Re: Firefox 3.5.1 on Solaris 10? >> Antwort an: solarisx86 at yahoogroups.com >> >> I've been running 3.5.1 for over a week on Solaris 10 11/06, >> installed from the tarball version (not the package). The only >> issue that I ran into was with the Pango RC file (found in >> ~/.mozilla/firefox/etc/pango/pangorc on my system); for the past >> few releases of Firefox 3, the RC file has been clobbered the first >> time I start up a new release. I have to run the new release once, >> which overwrites the RC file; I then copy a backup version into the >> file, and the new release runs fine from then onward. My guess is >> that there's a library version conflict at the root of this >> problem, but I haven't taken the time to track it down. >> >> In some recent releases (3.0.10, 3.0.11, and 3.5), I've also had to >> modify the firefox startup script because of library version >> conflicts. I added moz_libdir (the install directory) to the front >> of LD_LIBRARY_PATH, and that took care of the conflicts. I did not >> have to do this for 3.5.1, however. >> >> - Warren > Also, I still see the berkeleydb packages here, but there is STILL no > updated sendmail package. I broke my sendmail the last time I tried > to > update the database packages and am still wondering if this > compatibility > issue has been addressed. Yes. Basically as the scheme we intended of unifying didn't work out we went the other way round: Splitting bdb as separate as possible by confining each release to a specific subdir and only linking stuff to /opt/csw/lib when required by old apps not yet updated. If you update bdb it should do no harm to your old sendmail. Apart from that Mike and Benny are still working on the updated sendmail to the best of my knowledge. Mike? Benny? > I also see the dbus package. There has been > an outstanding issue that keeps Solaris from properly shutting down > as the > dbus service cannot be stopped. Has that issue been addressed with > this > dbus release? These are both long-standing issues and I am > wondering why > I have not heard about their successful resolution. Did I miss some > important discussions during the past few weeks? Yes, you missed that one, it was fixed by William two month ago: Anfang der weitergeleiteten E-Mail: > Von: William Bonnet > Datum: 3. September 2009 23:01:27 MESZ > An: questions and discussions , internal > list for the CSW maintainers > Betreff: [csw-users] Important ! DBus update and bug fix > Antwort an: Questions and discussions > > Hi, > > A new version of the dbus packages will be pushed to current catalog > in the next hours. This version fixes the fllowing bug > > 0003626: dbus daemon will not stop on reboot/init 6 blocking the > shutdown ( http://opencsw.org/bugtrack/view.php?id=3626 ). > > > This bugs prevents dbus from stop correctly. If dbus is running, it > will be stop during update, thus update may freeze. In order to > avoid this situation, you have to be sure that you don't have dbus > running, or if it is running, you will have to kill it by hand > before the upgrade. You can retrieve the pid to kill with the > following command : > > bash-3.00# cat /opt/csw/var/run/dbus/pid > 1592 > > or > > bash-3.00# ps -elf | grep dbus-daemon > 0 S messageb 1592 1 0 40 20 ? 634 ? > 22:55:25 ? 0:00 /opt/csw/bin/dbus-daemon --system > > Please "kill -9" the dbus process before running package upgrade. > > Kind regards > W. Best regards -- Dago From dam at opencsw.org Sun Nov 8 11:23:56 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 8 Nov 2009 11:23:56 +0100 Subject: [csw-maintainers] Preview of the new mirror structure available In-Reply-To: <20091107.11450400.3207873259@gyor.oxdrove.co.uk> References: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> <20091107.11450400.3207873259@gyor.oxdrove.co.uk> Message-ID: <875DC6B7-42D7-4E97-B5E3-E2850AF371B6@opencsw.org> Hi James, Am 07.11.2009 um 12:45 schrieb James Lee: > On 05/11/09, 16:16:42, Dagobert Michelsen wrote regarding > [csw-maintainers] Preview of the new mirror structure available: > > Is this a preview or a proposal? A preview of the proposal ;-) > opencsw/ >> experimental/ >> / >> pkgs/ (confined to this directory) >> mytest.pkg.gz >> sparc/ >> 5.8/ >> mytest.pkg.gz (hardlinked to pkgs/mytest.pkg.gz) > >> testing/ >> pkgs/ >> sparc/ >> 5.8/ > > Too complex and risky to be of any use to *users*. Why "too complex"? The users just subscribe to a URL. The structure doesn't matter as long as they use pkg-get or pkgutil. Apart from that I think it easier than the current layout as it puts testing/ closed to current/. > distribution/ >> allcatalogs/ >> catalog-sparc-5.8-20091002 >> allpkgs/ >> mypkg.tar.gz > > This looks as if your proposal is to formalise the retention of all > packages and catalogues (a collection's state). At first this seems > like a good idea but think deeper and you will see that if all > catalogues are kept there is no way of knowing which are erroneous, > hence they all become useless. Actually there is a way of knowing > because we keep the known good sets as stable releases which is > already handled. My intentions are different. I want to solve two problems with it: 1. There is no official archive for all released package versions This is currently handled by http://csw.informatik.uni-erlangen.de/oldpkgs/ . While I think that Michael is doing a great job I would prefer that the project itself would keep an archive. allpkgs/ is my proposal to handle this. 2. When you install a package you are forced to upgrade other packages The larger customers of ours have own mirrors from where they install. However, the smaller installation just subscribe to current/. When an inexperienced admin just wants to add a package and by error updates the catalog there is no way other then to update the dependencies of the package to be installed as there is neither an unchanged location for scubscription nor the old archived catalog. The freezes are not meant as replacement for stable, but as substitute to subscribe to in addition to current/. >> stable/ >> sparc/ >> 5.8/ >> current/ >> sparc/ >> 5.8/ >> pkg.tar.gz (also hardlinked from allpkgs) >> freeze/ >> current-20091002/ >> README.20091002 >> sparc/ >> 5.8/ >> catalog >> pkg.tar.gz (hardlinked from allpkgs) >> 5.9/ >> pkg.tar.gz (symlinked to 5.8, same as in current/) > > This misunderstands the WIP nature of the snapshot process. The > freeze > is on unstable, it's not an entity it's unstable itself that is > frozen. Again: This has nothing to do with freezes needed to build stable. This whole rework of the layout is the result of the discussion we had on the founding meeting a year ago. I am just a bit slow... > ** TBD: experimental/ should be filled with the subdirectories from >> what is now in testing/. >> Subdirectories can be created by each maintainer and for each >> folder a subproject >> is created in experimental which can be synced to separately. > >> ** TBD: packages/ can the go from experimental/ to testing/ when no >> open issues persist. > > How will you define "no open issues persist"? That the maintainer of the packages doesn't know of any. Currently testing/ contains packages for which the maintainers _know_ that some things doesn't work but wants to test other things anyway. While it is useful to pkg- get from the testing-catalog it may not be useful for general testing. That's why I want to confine these specific-things-only testing to subdirs of experimental/ the maintainers can create at will and use whatever they think is good but restrict testing/ to packages that are good for testing by anyone who wants to help testing and every encountered issue is an unknown, actual bug. >> This can be used to drive servers. Only packages proven there can >> go to current/. See >> http://wiki.opencsw.org/automated-release-process >> for details. > > Here you draw parity to the Debian system. Previous discussion > concluded > the levels you show are not correct. > > "How stuff gets in there", conceptually and practically it doesn't > because stable is a modified clone of another state done as an atomic > operation. > > I feel we've lost sight of the aims of the proposal. It is a writedown of the discussion of Oslo. If you actually use cswrepo or another tool to moves packages there is up to you. If they are released atomically as a whole this is independent of the tool to move packages between catalogs. The core of the discussion was to formalize the moving of packages between catalogs, being the one from current to stable just an example. The important point is to have an API for tools to deliver to experimental/ and to move from experimental/ to testing/. Best regards -- Dago From james at opencsw.org Sun Nov 8 12:53:36 2009 From: james at opencsw.org (James Lee) Date: Sun, 08 Nov 2009 11:53:36 GMT Subject: [csw-maintainers] Preview of the new mirror structure available In-Reply-To: <875DC6B7-42D7-4E97-B5E3-E2850AF371B6@opencsw.org> References: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> <20091107.11450400.3207873259@gyor.oxdrove.co.uk> <875DC6B7-42D7-4E97-B5E3-E2850AF371B6@opencsw.org> Message-ID: <20091108.11533600.3521195917@gyor.oxdrove.co.uk> On 08/11/09, 10:23:56, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Preview of the new mirror structure available: > > opencsw/ > >> experimental/ > >> / > >> pkgs/ (confined to this directory) > >> mytest.pkg.gz > >> sparc/ > >> 5.8/ > >> mytest.pkg.gz (hardlinked to pkgs/mytest.pkg.gz) > > > >> testing/ > >> pkgs/ > >> sparc/ > >> 5.8/ > > > > Too complex and risky to be of any use to *users*. > Why "too complex"? The users just subscribe to a URL. The structure > doesn't > matter as long as they use pkg-get or pkgutil. Apart from that I think > it easier than the current layout as it puts testing/ closed to > current/. In overview, why would *users* want to and why would we do anything to encourage *users* to subscribe to these? We should *hide* these from *users* not distribute via mirrors. In overview, define the user's profiles and decide what type of package you think they should be using. > > distribution/ > >> allcatalogs/ > >> catalog-sparc-5.8-20091002 > >> allpkgs/ > >> mypkg.tar.gz > > > > This looks as if your proposal is to formalise the retention of all > > packages and catalogues (a collection's state). At first this seems > > like a good idea but think deeper and you will see that if all > > catalogues are kept there is no way of knowing which are erroneous, > > hence they all become useless. Actually there is a way of knowing > > because we keep the known good sets as stable releases which is > > already handled. > My intentions are different. I want to solve two problems with it: > 1. There is no official archive for all released package versions > This is currently handled by http://csw.informatik.uni-erlangen.de/oldpkgs/ > . > While I think that Michael is doing a great job I would prefer that the > project itself would keep an archive. allpkgs/ is my proposal to handle > this. So that intention is the same. > 2. When you install a package you are forced to upgrade other packages It's a feature, much thought about. > The larger customers of ours have own mirrors from where they install. > However, the smaller installation just subscribe to current/. That's their mistake. What are we doing to educate? > When an > inexperienced admin just wants to add a package and by error updates > the catalog there is no way other then to update the dependencies of > the package to be installed as there is neither an unchanged location > for scubscription nor the old archived catalog. The freezes are not > meant as replacement for stable, but as substitute to subscribe to > in addition to current/. So whatever state they first install they can continue to use for additions. It needs a state for every catalog issued. It would be better to designate landmark catalogs and keep just those - oh we do that already. Better to make the installer use a named catalogue then it can use a single bulk archive - or educate inexperienced admins. > > ** TBD: experimental/ should be filled with the subdirectories from > >> what is now in testing/. > >> Subdirectories can be created by each maintainer and for each > >> folder a subproject > >> is created in experimental which can be synced to separately. > > > >> ** TBD: packages/ can the go from experimental/ to testing/ when no > >> open issues persist. > > > > How will you define "no open issues persist"? > That the maintainer of the packages doesn't know of any. Currently > testing/ > contains packages for which the maintainers _know_ that some things > doesn't > work but wants to test other things anyway. While it is useful to pkg- > get > from the testing-catalog it may not be useful for general testing. > That's why I want to confine these specific-things-only testing to > subdirs of experimental/ the maintainers can create at will and use > whatever > they think is good but restrict testing/ to packages that are good for > testing by anyone who wants to help testing and every encountered issue > is an unknown, actual bug. I thought that's what testing was, and repeating myself it shouldn't have a catalogue, or if it does needs a health warning explaining that it's a sure way to shoot yourself in the foot. > >> This can be used to drive servers. Only packages proven there can > >> go to current/. See > >> http://wiki.opencsw.org/automated-release-process > >> for details. > > > > Here you draw parity to the Debian system. Previous discussion > > concluded > > the levels you show are not correct. > > > > "How stuff gets in there", conceptually and practically it doesn't > > because stable is a modified clone of another state done as an atomic > > operation. > > > > I feel we've lost sight of the aims of the proposal. > It is a writedown of the discussion of Oslo. Ah the Oslo Treaty, this must be like the Lisbon Treaty. > If you actually use > cswrepo or > another tool to moves packages there is up to you. If they are > released atomically as a whole this is independent of the tool to move > packages between catalogs. The core of the discussion was to formalize > the moving of packages between catalogs, We've only had one. "A catalog" represents a collection that should be integrated, there should be no concept of isolated additions and movements. OK that's what happens but don't formalise it as a concept. > being the one from current to > stable just an example. The important point is to have an API for tools > to deliver to experimental/ and to move from experimental/ to testing/. Important for what? Sorry I've lost track of how this is an aim of providing a service to users. (How one choses to implement a standard is one's choice, blah, blah, as agreed above.) Step 1: define the problem. James. From trygvis at opencsw.org Sun Nov 8 15:52:18 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 08 Nov 2009 15:52:18 +0100 Subject: [csw-maintainers] tofrodos in newpkgs/ Message-ID: <4AF6DB22.2090008@opencsw.org> Hi I've packages tofrodos which include a sorely missing dos2unix/unix2dos commands. tofrodos-1.7.8\,REV\=2009.11.08-SunOS5.8-* -- Trygve From james at opencsw.org Sun Nov 8 16:07:36 2009 From: james at opencsw.org (James Lee) Date: Sun, 08 Nov 2009 15:07:36 GMT Subject: [csw-maintainers] tofrodos in newpkgs/ In-Reply-To: <4AF6DB22.2090008@opencsw.org> References: <4AF6DB22.2090008@opencsw.org> Message-ID: <20091108.15073600.3743634814@gyor.oxdrove.co.uk> On 08/11/09, 14:52:18, "Trygve Laugst?l" wrote regarding [csw-maintainers] tofrodos in newpkgs/: > I've packages tofrodos which include a sorely missing dos2unix/unix2dos > commands. Just curious, sorely missing from what? $ which unix2dos /usr/bin/unix2dos $ which dos2unix /usr/bin/dos2unix $ man unix2dos Reformatting page. Please Wait... done User Commands unix2dos(1) NAME unix2dos - convert text file from ISO format to DOS format ... James. From trygvis at opencsw.org Sun Nov 8 17:10:00 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 08 Nov 2009 17:10:00 +0100 Subject: [csw-maintainers] tofrodos in newpkgs/ In-Reply-To: <20091108.15073600.3743634814@gyor.oxdrove.co.uk> References: <4AF6DB22.2090008@opencsw.org> <20091108.15073600.3743634814@gyor.oxdrove.co.uk> Message-ID: <4AF6ED58.5030204@opencsw.org> James Lee wrote: > On 08/11/09, 14:52:18, "Trygve Laugst?l" wrote > regarding [csw-maintainers] tofrodos in newpkgs/: > >> I've packages tofrodos which include a sorely missing dos2unix/unix2dos >> commands. > > Just curious, sorely missing from what? I'm always bitten by the shipped dos2unix can't replace the converted file. I guess you can say sorely missed by me :) -- Trygve From trygvis at opencsw.org Sun Nov 8 17:24:04 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 08 Nov 2009 17:24:04 +0100 Subject: [csw-maintainers] Undefined symbol __sync_fetch_and_add_4. Message-ID: <4AF6F0A4.60205@opencsw.org> 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 -- Trygve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: build.log URL: From james at opencsw.org Sun Nov 8 17:30:32 2009 From: james at opencsw.org (James Lee) Date: Sun, 08 Nov 2009 16:30:32 GMT Subject: [csw-maintainers] tofrodos in newpkgs/ In-Reply-To: <4AF6ED58.5030204@opencsw.org> References: <4AF6DB22.2090008@opencsw.org> <20091108.15073600.3743634814@gyor.oxdrove.co.uk> <4AF6ED58.5030204@opencsw.org> Message-ID: <20091108.16303200.2957062777@gyor.oxdrove.co.uk> On 08/11/09, 16:10:00, "Trygve Laugst?l" wrote regarding Re: [csw-maintainers] tofrodos in newpkgs/: > >> I've packages tofrodos which include a sorely missing dos2unix/unix2dos > >> commands. > > > > Just curious, sorely missing from what? > I'm always bitten by the shipped dos2unix can't replace the converted > file. I guess you can say sorely missed by me :) Thanks, so to clarify it's missing functionality and options rather than actually missing dos2unix/unix2dos commands. James. From rupert at opencsw.org Sun Nov 8 18:03:39 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 8 Nov 2009 18:03:39 +0100 Subject: [csw-maintainers] hg-1.4 tests fed back to mercurial Message-ID: <6af4270911080903o7e02d2d4w7141892115120b93@mail.gmail.com> hi, we gave the mercurial test feedback for the next version hg-1.4 to their mailing list, see: http://groups.google.com/group/mercurial_devel/browse_thread/thread/7916314a91431028 . rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Nov 8 19:23:06 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 8 Nov 2009 18:23:06 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <4AF5B104.90307@opencsw.org> References: <4AF342DE.2020604@opencsw.org> <4AF5B104.90307@opencsw.org> Message-ID: On Sat, Nov 7, 2009 at 5:40 PM, Ihsan Dogan wrote: > Hello Maciej, > > Am 7.11.2009 17:47 Uhr, Maciej (Matchek) Blizinski schrieb: > >>> The init script tries to create the pid file in /opt/csw/mysql5/var. I >>> think this should be either changed to $MYSQLD_DATADIR/mysql.pid. >> I think I fixed it. ?Can you check? ?Updates packages are in testing/. > > I just installed it and it works out of the box. > > mysql5test requires Perl, but it's not a dependency of mysql5test. Added: http://sourceforge.net/apps/trac/gar/changeset/7159 I'll wait a day or two before I update the packages in case there are more changes to make. Are there any other comments? Sebastian mentioned someone who was interested in collaborating on the MySQL package. I got us up to the point where we get something which passes the smoke test: we can install the package and it doesn't blow right after installation. That's a nice start, but it might still be a long way to go. I think the main current issue is getting the tests to pass. Do you think that it's worth working on the 5.0.x tests, or should we skip releasing 5.0.x and move on to 5.1 already? Maciej From dam at opencsw.org Sun Nov 8 21:27:59 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 8 Nov 2009 21:27:59 +0100 Subject: [csw-maintainers] hg-1.4 tests fed back to mercurial In-Reply-To: <6af4270911080903o7e02d2d4w7141892115120b93@mail.gmail.com> References: <6af4270911080903o7e02d2d4w7141892115120b93@mail.gmail.com> Message-ID: <1F161E3A-6756-4BFA-BE07-C54D1C536A1B@opencsw.org> Hi Rupert, Am 08.11.2009 um 18:03 schrieb rupert THURNER: > we gave the mercurial test feedback for the next version hg-1.4 to > their mailing list, see: http://groups.google.com/group/mercurial_devel/browse_thread/thread/7916314a91431028 > . Thanks for being a "good" maintainer :-) Please note the we offer upstream maintainer accounts for people who are only enhancing Solaris support upstream and don't intend to packge - just in case there is anyone in the project needing access to a Solaris machine. Best regards -- Dago -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at cjsa.com Sun Nov 8 23:09:01 2009 From: jeff at cjsa.com (Jeffery Small) Date: Sun, 8 Nov 2009 22:09:01 GMT Subject: [csw-maintainers] Library problems with gnome apps References: Message-ID: Dagobert Michelsen writes: >I also remember this [firefox problem], but only found this post in my >mailbox. It may or may not be related to your problem, but you should >check the bound libraries with ldd on the running process that no /opt/csw >stuff is bound. > [...] >Yes. Basically as the scheme we intended of unifying didn't work out >we went the other way round: Splitting bdb as separate as possible by >confining each release to a specific subdir and only linking stuff >to /opt/csw/lib when required by old apps not yet updated. If you update >bdb it should do no harm to your old sendmail. > [...] >Yes, you missed that one, it [dbus] was fixed by William two month ago: > [...] Dago: Thanks you very much for all the great information. I will take a closer look at the firefox problem and see if I can come up with any more specific answers regarding the libraries. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From ihsan at opencsw.org Sun Nov 8 23:47:11 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 08 Nov 2009 23:47:11 +0100 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: References: <4AF342DE.2020604@opencsw.org> <4AF5B104.90307@opencsw.org> Message-ID: <4AF74A6F.6010004@opencsw.org> Am 8.11.2009 19:23 Uhr, Maciej (Matchek) Blizinski schrieb: >>>> The init script tries to create the pid file in /opt/csw/mysql5/var. I >>>> think this should be either changed to $MYSQLD_DATADIR/mysql.pid. >>> I think I fixed it. Can you check? Updates packages are in testing/. >> I just installed it and it works out of the box. >> >> mysql5test requires Perl, but it's not a dependency of mysql5test. > > Added: http://sourceforge.net/apps/trac/gar/changeset/7159 Thanks. > I'll wait a day or two before I update the packages in case there are > more changes to make. > > Are there any other comments? So far not. The package seems to work very well. > Sebastian mentioned someone who was interested in collaborating on the > MySQL package. I got us up to the point where we get something which > passes the smoke test: we can install the package and it doesn't blow > right after installation. That's a nice start, but it might still be > a long way to go. I think the main current issue is getting the tests > to pass. What do you mean with "it doesn't blow right after installation"? > Do you think that it's worth working on the 5.0.x tests, or should we > skip releasing 5.0.x and move on to 5.1 already? This package is an updated version of that, what we have already in our repository. I would release it and then concentrate on 5.1. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Sun Nov 8 23:58:56 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 8 Nov 2009 22:58:56 +0000 Subject: [csw-maintainers] mysql-5.0.84 in testing (a garified package) In-Reply-To: <4AF74A6F.6010004@opencsw.org> References: <4AF342DE.2020604@opencsw.org> <4AF5B104.90307@opencsw.org> <4AF74A6F.6010004@opencsw.org> Message-ID: On Sun, Nov 8, 2009 at 10:47 PM, Ihsan Dogan wrote: > Am 8.11.2009 19:23 Uhr, Maciej (Matchek) Blizinski schrieb: >> Sebastian mentioned someone who was interested in collaborating on the >> MySQL package. ?I got us up to the point where we get something which >> passes the smoke test: we can install the package and it doesn't blow >> right after installation. ?That's a nice start, but it might still be >> a long way to go. ?I think the main current issue is getting the tests >> to pass. > > What do you mean with "it doesn't blow right after installation"? Um, I meant "blow up". I meant that the package works after you install it and start up the database. >> Do you think that it's worth working on the 5.0.x tests, or should we >> skip releasing 5.0.x and move on to 5.1 already? > > This package is an updated version of that, what we have already in our > repository. I would release it and then concentrate on 5.1. We didn't make the tests pass with the 5.0.x. We don't know if the 5.0.51,REV=2008.01.20 was passing the tests. If it wasn't, releasing my 5.0.84 would not mean any degradation in the QA of the package. If it was, it would be nice to know what was done to make the tests pass. I don't know if it makes sense to invest time in 5.0.x. tests if we're going to move on to 5.1 soon. Maciej From maciej at opencsw.org Mon Nov 9 10:18:35 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 09:18:35 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: <1255994929-sup-3@ntdws12.chass.utoronto.ca> References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: I worked on submitpkg some more, to give more comprehensive information. It started with Phil asking for notifying which packages were new. I implemented that, and then thought that if there are whole groups of packages updated together, they should also be grouped in the e-mail. It also tells about the kinds of upgrades: is it major version upgrade (e.g. 1.2 to 2.0) or minor version upgrade (1.2 to 1.3), or only a revision change. Here's current example output: ------------8<----------------- * WARNING: no version change + bender:/home/newpkgs/autoproject-0.20,REV=2009.11.05-SunOS5.8-all-CSW.pkg.gz * minor version upgrade - from: 1.3.9,REV=2008.11.08 - to: 1.4.1,REV=2009.11.02 + bender:/home/newpkgs/cupsdev-1.4.1,REV=2009.11.02-SunOS5.8-all-CSW.pkg.gz + bender:/home/newpkgs/cupsdoc-1.4.1,REV=2009.11.02-SunOS5.8-all-CSW.pkg.gz * new package: /dev/null -> 2.4.0,REV=2009.11.09 + bender:/home/newpkgs/py_cheetah-2.4.0,REV=2009.11.09-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/py_cheetah-2.4.0,REV=2009.11.09-SunOS5.8-sparc-CSW.pkg.gz ------------8<----------------- I also added unit tests. To test submitpkg from login.opencsw.org: svn co https://opencsw.svn.sourceforge.net/svnroot/opencsw/utilities cd utilities ./submit_to_newpkgs.py -h ./submit_to_newpkgs.py -p catalogname1,catalogname2,... Maciej From maciej at opencsw.org Mon Nov 9 10:46:07 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 09:46:07 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: <1255994929-sup-3@ntdws12.chass.utoronto.ca> References: <4ADCBA79.7050005@opencsw.org> <1255994929-sup-3@ntdws12.chass.utoronto.ca> Message-ID: I worked on submitpkg some more, to give more comprehensive information. It started with Phil asking for notifying which packages were new. I implemented that, and then thought that if there are whole groups of packages updated together, they should also be grouped in the e-mail. It also tells about the kinds of upgrades: is it major version upgrade (e.g. 1.2 to 2.0) or minor version upgrade (1.2 to 1.3), or only a revision change. Here's current example output: ------------8<----------------- * WARNING: no version change + bender:/home/newpkgs/autoproject-0.20,REV=2009.11.05-SunOS5.8-all-CSW.pkg.gz * minor version upgrade - from: 1.3.9,REV=2008.11.08 - to: 1.4.1,REV=2009.11.02 + bender:/home/newpkgs/cupsdev-1.4.1,REV=2009.11.02-SunOS5.8-all-CSW.pkg.gz + bender:/home/newpkgs/cupsdoc-1.4.1,REV=2009.11.02-SunOS5.8-all-CSW.pkg.gz * new package: /dev/null -> 2.4.0,REV=2009.11.09 + bender:/home/newpkgs/py_cheetah-2.4.0,REV=2009.11.09-SunOS5.8-i386-CSW.pkg.gz + bender:/home/newpkgs/py_cheetah-2.4.0,REV=2009.11.09-SunOS5.8-sparc-CSW.pkg.gz ------------8<----------------- I also added unit tests. To test submitpkg: svn co https://opencsw.svn.sourceforge.net/svnroot/opencsw/utilities cd utilities ./submit_to_newpkgs.py -h ./submit_to_newpkgs.py -p catalogname1,catalogname2,... Maciej From maciej at opencsw.org Mon Nov 9 14:52:43 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 13:52:43 +0000 Subject: [csw-maintainers] py_cheetah: Python template engine in testing/ Message-ID: Cheetah is an Python templates engine. It allows to embed minimal flow control, so that things such as generating a list can be handled inside templates. http://mirror.opencsw.org/testing/py_cheetah-2.4.0,REV=2009.11.09-SunOS5.8-i386-CSW.pkg.gz http://mirror.opencsw.org/testing/py_cheetah-2.4.0,REV=2009.11.09-SunOS5.8-sparc-CSW.pkg.gz Maciej From dam at opencsw.org Mon Nov 9 17:09:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Nov 2009 17:09:19 +0100 Subject: [csw-maintainers] RFD: X11 linkage problem strategy In-Reply-To: References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> Message-ID: <6BA24589-C2D1-48E7-9B97-98C5FC8FFD65@opencsw.org> Hi, Am 04.11.2009 um 22:28 schrieb Philip Brown: > On Tue, Nov 3, 2009 at 7:35 AM, Dagobert Michelsen > wrote: >> Maybe someone has a good solution on how to cope this in the >> general case. >> Of course the trivial one would be to recompile everything needing >> x11 >> against the CSW libs, which would pull in loads of stuff even if the >> Solaris library would be sufficient. > > This was the core of my original reluctance to have these new libs in. > I described explicitly that this sort of thing would be inevitable :-( > > Recompiling certain things for the newer, csw-bundled X11 libs will > then become required.. not because those things themselves need the > newer stuff... but because yet other packages, depend on the first set > of packages, and also require the newer X11 libs :-( > > Technically, we dont need to require *everything* of ours that uses > X11. But pretty close. > > Pretty much anything of ours that touches gnome libs... or anything of > ours that is touched BY something that touches gnome libs... will need > to be relinked now, I think :-( How about distribution two sets of libraries for intermediate-libraries that may be linked against either x11 library like giflib? One like CSWcsw11_libgif bound against CSW X11 and located in /opt/csw/X11/lib, and CSWlibgif bound against Sun X11 as before. This would allow a clean separation between the two forms of libs. Best regards -- Dago From maciej at opencsw.org Mon Nov 9 17:11:06 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 16:11:06 +0000 Subject: [csw-maintainers] svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums' In-Reply-To: <6af4270911070136j7b49d0c6wa2e50c4b2ae53f56@mail.gmail.com> References: <6af4270911070136j7b49d0c6wa2e50c4b2ae53f56@mail.gmail.com> Message-ID: On Sat, Nov 7, 2009 at 9:36 AM, rupert THURNER wrote: > can we delete the tag in the repository itself by doing something like "svn > rm https://.../bdb3/tags/..." ? I tried something different: I cd'd into the bdb3-stub-to-bdb33-UNRELEASED directory, ran "svn up" -- it completed without errors. I went one level up, ran "svn up" again, it worked. Back to the 'pkg' level, svn up --ignore-externals -- it worked. I'm wondering it it would also work for other people. From maciej at opencsw.org Mon Nov 9 18:14:44 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 17:14:44 +0000 Subject: [csw-maintainers] Problems building CSWgar Message-ID: When building CSWgar, I'm getting this error message: Transferring package instance mkp: exec( gzip -9 -f /tmp/gar-7184,REV=2009.11.09-SunOS5.8-all-CSW.pkg ) mkp: exec( mv /tmp/gar-7184,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz /home/maciej/staging/build-2009-11-09 ) mkp: exec( rm -rf /home/maciej/spool.5.8-i386/CSWgar ) Examining /home/maciej/staging/build-2009-11-09/gar-7184,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz Looking for bad strings... for badpath in /export/medusa /opt/build ; do for badpath in /export/medusa /opt/build ; do ERROR: build-machine paths found in file /home/maciej/staging/build-2009-11-09/gar-7184,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz ($badpath) gmake: *** [pkgcheck] Error 2 Dago, I'm guessing you'll have an idea what's happening here. Maciej From bwalton at opencsw.org Mon Nov 9 18:20:11 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 09 Nov 2009 12:20:11 -0500 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: References: Message-ID: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Nov 09 12:14:44 -0500 2009: > When building CSWgar, I'm getting this error message: > Looking for bad strings... > for badpath in /export/medusa /opt/build ; do > for badpath in /export/medusa /opt/build ; do > > ERROR: build-machine paths found in file GAR contains checkpkg which contains those strings. Self fulfilling prophecy. Special case exemption would be in order, me thinks. -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 Mon Nov 9 18:30:00 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 9 Nov 2009 09:30:00 -0800 Subject: [csw-maintainers] RFD: X11 linkage problem strategy In-Reply-To: <6BA24589-C2D1-48E7-9B97-98C5FC8FFD65@opencsw.org> References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> <6BA24589-C2D1-48E7-9B97-98C5FC8FFD65@opencsw.org> Message-ID: On Mon, Nov 9, 2009 at 8:09 AM, Dagobert Michelsen wrote: > >> Pretty much anything of ours that touches gnome libs... or anything of >> ours that is touched BY something that touches gnome libs... will need >> to be relinked now, I think :-( > > How about distribution two sets of libraries for intermediate-libraries > that may be linked against either x11 library like giflib? One like > ?CSWcsw11_libgif > bound against CSW X11 and located in /opt/csw/X11/lib, and > ?CSWlibgif > bound against Sun X11 as before. This would allow a clean separation > between the two forms of libs. > oh yikes. you're talking about distributing two libgifs, two libjpegs, etc? Sounds like it ma be a headache, and possibly more headache than it is worth. I think it would be best if you did some research, and laid out just how many "intermediate libraries" we are talking about, and just how many packages would USE these retro-compiled packages. Depending on the number of affected packages, other options for affected packages might be: a) use solaris-shipped libs entirely (arent they available for sol8?) b) use static compiled versions of small libs, if number of affected packages is only a handful. OR, possibly still have the old way. but there is an issue of which version of libgif "belongs" in /opt/csw/lib. Probably the normal one I suppose, if we mandate that anything using /opt/csw/X11/lib must have that FIRST in its RPATH. From maciej at opencsw.org Mon Nov 9 18:49:16 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 17:49:16 +0000 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> References: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Nov 9, 2009 at 5:20 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Mon Nov 09 12:14:44 -0500 2009: >> When building CSWgar, I'm getting this error message: >> Looking for bad strings... >> ? ? ? ? for badpath in /export/medusa /opt/build ; do >> ? ? ? ? for badpath in /export/medusa /opt/build ; do >> >> ERROR: build-machine paths found in file > > GAR contains checkpkg which contains those strings. ?Self fulfilling > prophecy. ?Special case exemption would be in order, me thinks. Perhaps a little obfuscation, say, rot13 could help? for badpath in $(echo /rkcbeg/zrqhfn /bcg/ohvyq | gtr a-mn-z n-za-m); do ... Maciej From phil at bolthole.com Mon Nov 9 19:43:18 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 9 Nov 2009 10:43:18 -0800 Subject: [csw-maintainers] Preview of the new mirror structure available In-Reply-To: <875DC6B7-42D7-4E97-B5E3-E2850AF371B6@opencsw.org> References: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> <20091107.11450400.3207873259@gyor.oxdrove.co.uk> <875DC6B7-42D7-4E97-B5E3-E2850AF371B6@opencsw.org> Message-ID: On Sun, Nov 8, 2009 at 2:23 AM, Dagobert Michelsen wrote: > > The larger customers of ours have own mirrors from where they install. > However, the smaller installation just subscribe to current/. When an > inexperienced admin just wants to add a package and by error updates > the catalog there is no way other then to update the dependencies of > the package to be installed as there is neither an unchanged location > for scubscription nor the old archived catalog. and for the vast majority of customers, this is a GOOD THING! This is a "feature", not a bug! It is detrimental to have out of date, older versions of things. It is only at sites where they have to be really really careful about upgrades and changes, that this behaviour is a problem. We should make sure that we optimize for the common best case. We should also give mechanisms for the "picky sites" to accomplish what they need to do from our packages. However, if we just had regular "stable" releases again, we would accomplish this pretty well. > The freezes are not > meant as replacement for stable, but as substitute to subscribe to > in addition to current/. Perhaps you meant "as an alternative choice to current". From phil at bolthole.com Mon Nov 9 19:57:21 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 9 Nov 2009 10:57:21 -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> Message-ID: On Sun, Nov 8, 2009 at 2:58 PM, Maciej (Matchek) Blizinski wrote: > > We didn't make the tests pass with the 5.0.x. ?We don't know if the > 5.0.51,REV=2008.01.20 was passing the tests. ?If it wasn't, releasing > my 5.0.84 would not mean any degradation in the QA of the package. ?If > it was, it would be nice to know what was done to make the tests pass. > ?I don't know if it makes sense to invest time in 5.0.x. tests if > we're going to move on to 5.1 soon. i agree that so long as your 5.0.x version passes *at least the same tests as our existing package*, it is fine to release,and then focus efforts on 5.1 the only remaining question is, which tests does our existing pass? From maciej at opencsw.org Mon Nov 9 20:43:43 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 19:43:43 +0000 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: References: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Nov 9, 2009 at 5:49 PM, Maciej (Matchek) Blizinski wrote: > On Mon, Nov 9, 2009 at 5:20 PM, Ben Walton wrote: >> Excerpts from Maciej (Matchek) Blizinski's message of Mon Nov 09 12:14:44 -0500 2009: >>> When building CSWgar, I'm getting this error message: >>> Looking for bad strings... >>> ? ? ? ? for badpath in /export/medusa /opt/build ; do >>> ? ? ? ? for badpath in /export/medusa /opt/build ; do >>> >>> ERROR: build-machine paths found in file >> >> GAR contains checkpkg which contains those strings. ?Self fulfilling >> prophecy. ?Special case exemption would be in order, me thinks. > > Perhaps a little obfuscation, say, rot13 could help? > > for badpath in $(echo /rkcbeg/zrqhfn /bcg/ohvyq | gtr a-mn-z n-za-m); do ... I've found out that there are two checkpkg instances, one in CSWcswutils, and one in gar/v2/bin. Is it intended? Anyway, I updated both of them and bumped the version of CSWcswutils. I think I'll have to wait until the updated package (>=cswutils-1.14.6) is installed on the buildfarm. Maciej From dam at opencsw.org Mon Nov 9 21:47:40 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Nov 2009 21:47:40 +0100 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: References: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> Message-ID: Hi Maciej, Am 09.11.2009 um 20:43 schrieb Maciej (Matchek) Blizinski: > On Mon, Nov 9, 2009 at 5:49 PM, Maciej (Matchek) Blizinski > wrote: >> On Mon, Nov 9, 2009 at 5:20 PM, Ben Walton >> wrote: >>> Excerpts from Maciej (Matchek) Blizinski's message of Mon Nov 09 >>> 12:14:44 -0500 2009: >>>> When building CSWgar, I'm getting this error message: >>>> Looking for bad strings... >>>> for badpath in /export/medusa /opt/build ; do >>>> for badpath in /export/medusa /opt/build ; do >>>> >>>> ERROR: build-machine paths found in file >>> >>> GAR contains checkpkg which contains those strings. Self fulfilling >>> prophecy. Special case exemption would be in order, me thinks. >> >> Perhaps a little obfuscation, say, rot13 could help? >> >> for badpath in $(echo /rkcbeg/zrqhfn /bcg/ohvyq | gtr a-mn-z n-za- >> m); do ... > > I've found out that there are two checkpkg instances, one in > CSWcswutils, and one in gar/v2/bin. Is it intended? Let me put it this way: I am aware of it :-) It was already this way when I took over GAR. It may be better to rely on CSWcswutils and let GAR depend on the package. > Anyway, I updated both of them and bumped the version of CSWcswutils. > I think I'll have to wait until the updated package > (>=cswutils-1.14.6) is installed on the buildfarm. Um, no, as GAR depends on the checkpkg inside the repository. Thanks! -- Dago From dam at opencsw.org Mon Nov 9 21:51:44 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Nov 2009 21:51:44 +0100 Subject: [csw-maintainers] svn: Checksum mismatch for 'pkg/bdb3/tags/bdb3-stub-to-bdb33-UNRELEASED/checksums' In-Reply-To: References: <6af4270911070136j7b49d0c6wa2e50c4b2ae53f56@mail.gmail.com> Message-ID: Hi Maciej, Am 09.11.2009 um 17:11 schrieb Maciej (Matchek) Blizinski: > On Sat, Nov 7, 2009 at 9:36 AM, rupert THURNER > wrote: >> can we delete the tag in the repository itself by doing something >> like "svn >> rm https://.../bdb3/tags/..." ? > > I tried something different: I cd'd into the > bdb3-stub-to-bdb33-UNRELEASED directory, ran "svn up" -- it completed > without errors. I went one level up, ran "svn up" again, it worked. > Back to the 'pkg' level, svn up --ignore-externals -- it worked. > > I'm wondering it it would also work for other people. Yes, it does. SVN does feel strange from time to time. I do keep a backup of the tree around, have to check some time... Best regards -- Dago From maciej at opencsw.org Mon Nov 9 21:52:02 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 9 Nov 2009 20:52:02 +0000 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: References: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Nov 9, 2009 at 8:47 PM, Dagobert Michelsen wrote: >> Anyway, I updated both of them and bumped the version of CSWcswutils. >> I think I'll have to wait until the updated package >> (>=cswutils-1.14.6) is installed on the buildfarm. > > Um, no, as GAR depends on the checkpkg inside the repository. After updating the checkpkg inside GAR, I tried to build the package and it failed, I think it was running the one in /opt/csw/bin. This time there were no two lines with "for badpath in /export/medusa /opt/build ; do", but only one: Examining /home/maciej/staging/build-2009-11-09/gar-7186,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz Looking for bad strings... for badpath in /export/medusa /opt/build ; do ERROR: build-machine paths found in file /home/maciej/staging/build-2009-11-09/gar-7186,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz ($badpath) gmake: *** [pkgcheck] Error 2 Maciej From dam at opencsw.org Mon Nov 9 21:57:21 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Nov 2009 21:57:21 +0100 Subject: [csw-maintainers] Preview of the new mirror structure available In-Reply-To: References: <038C96FB-739B-4DDE-8F1D-BA14558AC1E4@opencsw.org> <20091107.11450400.3207873259@gyor.oxdrove.co.uk> <875DC6B7-42D7-4E97-B5E3-E2850AF371B6@opencsw.org> Message-ID: <9D9463F3-59F8-4B58-BDAE-8CA5299CCDA3@opencsw.org> Hi Phil, Am 09.11.2009 um 19:43 schrieb Philip Brown: > On Sun, Nov 8, 2009 at 2:23 AM, Dagobert Michelsen > wrote: >> >> The larger customers of ours have own mirrors from where they >> install. >> However, the smaller installation just subscribe to current/. When an >> inexperienced admin just wants to add a package and by error updates >> the catalog there is no way other then to update the dependencies of >> the package to be installed as there is neither an unchanged location >> for scubscription nor the old archived catalog. > > and for the vast majority of customers, this is a GOOD THING! This is > a "feature", not a bug! > It is detrimental to have out of date, older versions of things. > > It is only at sites where they have to be really really careful about > upgrades and changes, that this behaviour is a problem. > > We should make sure that we optimize for the common best case. > > We should also give mechanisms for the "picky sites" to accomplish > what they need to do from our packages. However, if we just had > regular "stable" releases again, we would accomplish this pretty well. Now that we talk about it I remember that I wanted to do this initially for stable: Keep released versions so that shops can upgrade at the pace they want instead of the release cycle. Apart from that: There are troubled waters ahead. Most server packages need updating, we have no build recipes for the existing ones, the directory layout will change away from /opt/csw to /etc and /var, version upgrades may be incompatible. There are at least SASL, OpenLDAP, Kerberos and Postgres that will likely break on upgrade. But this only slightly related to the freezes. I'll open another thread when I'm ready for this. >> The freezes are not >> meant as replacement for stable, but as substitute to subscribe to >> in addition to current/. > > Perhaps you meant "as an alternative choice to current". ?h, yes. Didn't I say that? Anyway, that's what I meant. Best regards -- Dago From dam at opencsw.org Mon Nov 9 22:09:39 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Nov 2009 22:09:39 +0100 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: References: Message-ID: Hi Maciej, Am 09.11.2009 um 18:14 schrieb Maciej (Matchek) Blizinski: > When building CSWgar, I'm getting this error message: > > Transferring package instance > mkp: exec( gzip -9 -f /tmp/gar-7184,REV=2009.11.09-SunOS5.8-all- > CSW.pkg ) > mkp: exec( mv /tmp/gar-7184,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz > /home/maciej/staging/build-2009-11-09 ) > mkp: exec( rm -rf /home/maciej/spool.5.8-i386/CSWgar ) > Examining /home/maciej/staging/build-2009-11-09/ > gar-7184,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz > Looking for bad strings... > for badpath in /export/medusa /opt/build ; do > for badpath in /export/medusa /opt/build ; do > > ERROR: build-machine paths found in file > /home/maciej/staging/build-2009-11-09/gar-7184,REV=2009.11.09- > SunOS5.8-all-CSW.pkg.gz > ($badpath) > gmake: *** [pkgcheck] Error 2 > > Dago, I'm guessing you'll have an idea what's happening here. Yes. I. Why the built broke When I changed to a single invocation of checkpkg I needed to change the logic and evaluation of the ENABLE_CHECK variable. In the past there was a check if it was "0" or not. I changed this to "TRUE" (meaning not-empty) to conform to the other variables which I forgot to change hear. It shouldn't harm to check anyway. This means that everywere where ENABLE_CHECK=0 was written there should be now ENABLE_CHECK= II. The Makefile of the GAR package As I was aware of the problem I chose to disable checking. This is already done in the Makefile as it contains the lines > # Because the bad pathes are in the bad pathes check we cannot check > ourselves > ENABLE_CHECK = 0 This stopped working with the change I. and I took this out now with your fix. III. The check The check for bad pathes must be reworked completely as the pathes were made to fit the previous project. As OpenCSW has other pathes the existing ones must be replaced. Best regards -- Dago From dam at opencsw.org Mon Nov 9 22:10:20 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Nov 2009 22:10:20 +0100 Subject: [csw-maintainers] Problems building CSWgar In-Reply-To: References: <1257787142-sup-1611@ntdws12.chass.utoronto.ca> Message-ID: Hi Maciej, Am 09.11.2009 um 21:52 schrieb Maciej (Matchek) Blizinski: > On Mon, Nov 9, 2009 at 8:47 PM, Dagobert Michelsen > wrote: >>> Anyway, I updated both of them and bumped the version of >>> CSWcswutils. >>> I think I'll have to wait until the updated package >>> (>=cswutils-1.14.6) is installed on the buildfarm. >> >> Um, no, as GAR depends on the checkpkg inside the repository. > > After updating the checkpkg inside GAR, I tried to build the package > and it failed, I think it was running the one in /opt/csw/bin. This > time there were no two lines with "for badpath in /export/medusa > /opt/build ; do", but only one: > > Examining /home/maciej/staging/build-2009-11-09/ > gar-7186,REV=2009.11.09-SunOS5.8-all-CSW.pkg.gz > Looking for bad strings... > for badpath in /export/medusa /opt/build ; do > > ERROR: build-machine paths found in file > /home/maciej/staging/build-2009-11-09/gar-7186,REV=2009.11.09- > SunOS5.8-all-CSW.pkg.gz > ($badpath) > gmake: *** [pkgcheck] Error 2 He he: build8s% find . | xargs grep medusa ./src/gar/v1/bin/checkpkg: for badpath in /export/medusa /opt/ build ; do I merged r7186 over to v1 as r7189. The gar package build works now and checks itself :-) Best regards -- Dago From maciej at opencsw.org Tue Nov 10 01:49:05 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 10 Nov 2009 00:49:05 +0000 Subject: [csw-maintainers] Double depends problem Message-ID: It happens quite often that packages I build with GAR end up having double depends. Can we have automation around that? We could have checkpkg verify that there are no double depends. We could also have some mechanism in GAR that would force the depends list to be unique. Ideally, we would have both those things. Maciej From maciej at opencsw.org Tue Nov 10 01:58:21 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 10 Nov 2009 00:58:21 +0000 Subject: [csw-maintainers] Double depends problem In-Reply-To: References: Message-ID: On Tue, Nov 10, 2009 at 12:49 AM, Maciej (Matchek) Blizinski wrote: > It happens quite often that packages I build with GAR end up having > double depends. ?Can we have automation around that? ?We could have > checkpkg verify that there are no double depends. ?We could also have > some mechanism in GAR that would force the depends list to be unique. > Ideally, we would have both those things. Adding a check to checkpkg was easy, done with one incomprehensible shell pipeline: http://sourceforge.net/apps/trac/gar/changeset/7191 Maciej From bwalton at opencsw.org Tue Nov 10 03:51:16 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 09 Nov 2009 21:51:16 -0500 Subject: [csw-maintainers] proposed small gar modification In-Reply-To: <3036B5F2-81F0-40F1-9F58-279DFB7AE052@opencsw.org> References: <1254936461-sup-6146@ntdws12.chass.utoronto.ca> <3036B5F2-81F0-40F1-9F58-279DFB7AE052@opencsw.org> Message-ID: <1257821157-sup-3986@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Oct 07 15:17:52 -0400 2009: Hi Dago, I just checked in the change we discussed that allows a maintainer to optionally disable CSWcommon as a dependency (primary use: pkgutil). Any maintainer that doesn't want a package to depend on CSWcommon should set: COMMON_PKG_DEPENDS = Gar build descriptions that generate multiple packages where only some packages should use CSWcommon would do: COMMON_PKG_DEPENDS = REQUIRED_PKGS_CSWsomepkg = CSWcommon ... 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 Tue Nov 10 04:04:30 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 09 Nov 2009 22:04:30 -0500 Subject: [csw-maintainers] git.opencsw.org Message-ID: <1257822095-sup-9151@ntdws12.chass.utoronto.ca> Hi All, We've had a gitosis server on git.opencsw.org (mirror) for a while now, but I updated it tonight to the latest version of the package that provides inetd support. This means that projects marked as public can be reached via urls like: git://git.opencsw.org/someproject.git Trygve is working on cgit, which is a nice web front end for repositories too. Dago, if you're ok with it, we can open ssh on that box to allow for gitosis at git.opencsw.org:someproject.git write access, which is currently limited to connections from inside the farm only (gitosis at mirror:someproject.git). Currently, Dago, Trygve and myself have access to the gitosis configuration to add projects, so please ping one of us if you'd like a project added[1]. The idea is that we can use this for projects that don't belong on sourceforge.net. Thanks -Ben [1] This list can certainly be amended if required/desired. -- 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 Nov 10 09:52:26 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 10 Nov 2009 08:52:26 +0000 Subject: [csw-maintainers] git.opencsw.org In-Reply-To: <1257822095-sup-9151@ntdws12.chass.utoronto.ca> References: <1257822095-sup-9151@ntdws12.chass.utoronto.ca> Message-ID: On Tue, Nov 10, 2009 at 3:04 AM, Ben Walton wrote: > Currently, Dago, Trygve and myself have access to the gitosis > configuration to add projects, so please ping one of us if you'd like > a project added[1]. ?The idea is that we can use this for projects > that don't belong on sourceforge.net. What would be an example of a project that doesn't belong on sourceforge.net? Maciej From ihsan at opencsw.org Tue Nov 10 10:46:38 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Tue, 10 Nov 2009 10:46:38 +0100 Subject: [csw-maintainers] EU objects Oracle's Sun takeover Message-ID: <4AF9367E.7010607@opencsw.org> Just saw that news this morning: http://www.vpbank.com/download/htm/1940/de/Daily-Morning-Coffee-News.pdf PS: Sorry, only in German. -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Tue Nov 10 11:14:00 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 10 Nov 2009 11:14:00 +0100 Subject: [csw-maintainers] RFD: X11 linkage problem strategy In-Reply-To: References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> <6BA24589-C2D1-48E7-9B97-98C5FC8FFD65@opencsw.org> Message-ID: <81CA8DC0-DF56-4BCB-81FB-3585FA6C5834@opencsw.org> Hi Phil, Am 09.11.2009 um 18:30 schrieb Philip Brown: > I think it would be best if you did some research, and laid out just > how many "intermediate libraries" we are talking about, and just how > many packages would USE these retro-compiled packages. > > Depending on the number of affected packages, other options for > affected packages might be: > > a) use solaris-shipped libs entirely (arent they available for sol8?) > b) use static compiled versions of small libs, if number of affected > packages is only a handful. > > OR, possibly still have the old way. but there is an issue of which > version of libgif "belongs" in /opt/csw/lib. > > Probably the normal one I suppose, if we mandate that anything using > /opt/csw/X11/lib must have that FIRST in its RPATH. That may be the ultimate solution: Just make sure that /opt/csw/X11/lib is in front of RPATH. That way the CSW x11 libs get always linked first, thus solving the mixed openwin/libX11 + csw/libXext issue. Doing more testing now... If it works I can easily add a permanent switch in GAR. Best regards -- Dago From maciej at opencsw.org Tue Nov 10 11:14:20 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 10 Nov 2009 10:14:20 +0000 Subject: [csw-maintainers] EU objects Oracle's Sun takeover In-Reply-To: <4AF9367E.7010607@opencsw.org> References: <4AF9367E.7010607@opencsw.org> Message-ID: On Tue, Nov 10, 2009 at 9:46 AM, Ihsan Dogan wrote: > Just saw that news this morning: > http://www.vpbank.com/download/htm/1940/de/Daily-Morning-Coffee-News.pdf http://www.denverpost.com/business/ci_13750606 They say the objection is over MySQL and database competition. "Oracle's acquisition of Sun's MySQL database software causes competition concerns." From dam at opencsw.org Tue Nov 10 11:21:42 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 10 Nov 2009 11:21:42 +0100 Subject: [csw-maintainers] proposed small gar modification In-Reply-To: <1257821157-sup-3986@ntdws12.chass.utoronto.ca> References: <1254936461-sup-6146@ntdws12.chass.utoronto.ca> <3036B5F2-81F0-40F1-9F58-279DFB7AE052@opencsw.org> <1257821157-sup-3986@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 10.11.2009 um 03:51 schrieb Ben Walton: > I just checked in the change we discussed that allows a maintainer to > optionally disable CSWcommon as a dependency (primary use: pkgutil). > Any maintainer that doesn't want a package to depend on CSWcommon > should set: > > COMMON_PKG_DEPENDS = > > Gar build descriptions that generate multiple packages where only some > packages should use CSWcommon would do: > > COMMON_PKG_DEPENDS = > > REQUIRED_PKGS_CSWsomepkg = CSWcommon ... Great! However: Am 10.11.2009 um 03:42 schrieb bdwalton at users.sourceforge.net: > Removed Paths: > ------------- > csw/mgar/gar/v2/pkglib/csw/depend lcsw% grep csw/depend * csw_cpan.gspec:%depend:merge url file://%{PKGLIB}/csw/depend.perl csw_dyndepend.gspec:%depend:merge url file://%{PKGLIB}/csw/depend csw_standard.gspec:%depend:merge url file://%{PKGLIB}/csw/depend Packages which still use static gspec will break when csw/depend is not there anymore. I re-added it in r7200. Apart from that it looks good and is definitely a step in the right direction :-) Best regards -- Dago From skayser at opencsw.org Tue Nov 10 14:49:33 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 10 Nov 2009 14:49:33 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: <20091110134933.GC30301@sebastiankayser.de> * Maciej (Matchek) Blizinski wrote: > On Tue, Oct 20, 2009 at 8:07 PM, Philip Brown wrote: > > On Tue, Oct 20, 2009 at 9:23 AM, Maciej (Matchek) Blizinski > > wrote: > >> > >> An idea for the change... from the perspective of the operating > >> system, it won't be really a rename, there is still going to be a > >> CSWpysvn package, only with a different content. > > > > > > you say "only", but that is what makes it WORSE! :-/ > > Not necessarily. We ship library packages with multiple libraries in > them. We potentially could ship both subversion-core and pysvn > libraries in the same package. No renaming, but merging > python-subversion libraries. It's a problem equivalent to the shared > library problem, which is solved already. > > > I have said the order and timeline of what I think is the best path to take. > > That still stands. > > Your timeline means that submitpkg won't be able to generate > changelists for $time_to_build_new_subversion_packages + one month. > I'd like to operate quicker than that. Any problems with this > approach? Any progress on the "new subversion/trac packages" front? I have had internal requests for 1.6.6 (quite a bit of bugfixes [1] from our current/ 1.6.2) and saw that a 1.6.5 build recipe with the adjusted python bindings package name is already in GAR. Sebastian [1] http://svn.collab.net/repos/svn/trunk/CHANGES From bwalton at opencsw.org Tue Nov 10 15:03:55 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 10 Nov 2009 09:03:55 -0500 Subject: [csw-maintainers] git.opencsw.org In-Reply-To: References: <1257822095-sup-9151@ntdws12.chass.utoronto.ca> Message-ID: <1257861780-sup-9707@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Tue Nov 10 03:52:26 -0500 2009: > What would be an example of a project that doesn't belong on sourceforge.net? Things that have no public value outside of opencsw? I don't think there are very many things that absolutely shouldn't be on sourceforge.net, but anything where 'security' is a concern might fit the bill. 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 bwalton at opencsw.org Tue Nov 10 15:06:07 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 10 Nov 2009 09:06:07 -0500 Subject: [csw-maintainers] proposed small gar modification In-Reply-To: References: <1254936461-sup-6146@ntdws12.chass.utoronto.ca> <3036B5F2-81F0-40F1-9F58-279DFB7AE052@opencsw.org> <1257821157-sup-3986@ntdws12.chass.utoronto.ca> Message-ID: <1257861936-sup-7751@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Nov 10 05:21:42 -0500 2009: Hi Dago, > Packages which still use static gspec will break when csw/depend is > not there anymore. I re-added it in r7200. Apart from that it looks > good and is definitely a step in the right direction :-) Doh! Thanks for catching that. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Tue Nov 10 17:39:54 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 10 Nov 2009 08:39:54 -0800 Subject: [csw-maintainers] RFD: X11 linkage problem strategy In-Reply-To: <81CA8DC0-DF56-4BCB-81FB-3585FA6C5834@opencsw.org> References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> <6BA24589-C2D1-48E7-9B97-98C5FC8FFD65@opencsw.org> <81CA8DC0-DF56-4BCB-81FB-3585FA6C5834@opencsw.org> Message-ID: On Tue, Nov 10, 2009 at 2:14 AM, Dagobert Michelsen wrote: >> Probably the normal one I suppose, if we mandate that anything using >> /opt/csw/X11/lib must have that FIRST in its RPATH. > > That may be the ultimate solution: Just make sure that > ?/opt/csw/X11/lib > is in front of RPATH. That way the CSW x11 libs get always linked first, > thus solving the mixed openwin/libX11 + csw/libXext issue. Doing more > testing now... If it works I can easily add a permanent switch in GAR. > Errr.. but it needs to only be for things that definately need "our" x11 libs. it cant be the "always default" ! From dam at opencsw.org Tue Nov 10 17:42:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 10 Nov 2009 17:42:13 +0100 Subject: [csw-maintainers] RFD: X11 linkage problem strategy In-Reply-To: References: <9692AA49-00DD-412C-B1EB-042E597321B7@opencsw.org> <6BA24589-C2D1-48E7-9B97-98C5FC8FFD65@opencsw.org> <81CA8DC0-DF56-4BCB-81FB-3585FA6C5834@opencsw.org> Message-ID: Hi Phil, Am 10.11.2009 um 17:39 schrieb Philip Brown: > On Tue, Nov 10, 2009 at 2:14 AM, Dagobert Michelsen > wrote: > >>> Probably the normal one I suppose, if we mandate that anything using >>> /opt/csw/X11/lib must have that FIRST in its RPATH. >> >> That may be the ultimate solution: Just make sure that >> /opt/csw/X11/lib >> is in front of RPATH. That way the CSW x11 libs get always linked >> first, >> thus solving the mixed openwin/libX11 + csw/libXext issue. Doing more >> testing now... If it works I can easily add a permanent switch in >> GAR. >> > > Errr.. but it needs to only be for things that definately need "our" > x11 libs. it cant be the "always default" ! I meant specifically for application that now bail out with linkage problems described before as mixed X11 usage from intermediate libs. Best regards -- Dago From bwalton at opencsw.org Tue Nov 10 21:14:14 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 10 Nov 2009 15:14:14 -0500 Subject: [csw-maintainers] hooks in pkg-get Message-ID: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> Hi Phil, Are you planning to implement hook support in pkg-get? There is already growing use of and demand for hooks, so not having it in pkg-get will present us with some problems... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Tue Nov 10 22:00:50 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 10 Nov 2009 13:00:50 -0800 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> Message-ID: On Tue, Nov 10, 2009 at 12:14 PM, Ben Walton wrote: > > Hi Phil, > > Are you planning to implement hook support in pkg-get? yes, I am "planning to". however, my time is limited, so it may not get done "soon". There is some small chance it may get done this weekend :-} However, there are other code changes that pkg-get is needing too, that have higher priority. > There is > already growing use of and demand for hooks, so not having it in > pkg-get will present us with some problems... problems? hooks are supposed to be *optional* things. If people are using hooks for package-mandatory things, there is a problem in packaging. I will remind you, that our packages should be installable by ANY SVR4 valid method. including "wget blah.pkg ; pkgadd -d blah.pkg". If the package does not function when added like that, then the package is improperly put together. From bwalton at opencsw.org Wed Nov 11 02:33:46 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 10 Nov 2009 20:33:46 -0500 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> Message-ID: <1257903067-sup-8643@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Nov 10 16:00:50 -0500 2009: > yes, I am "planning to". Ok. > however, my time is limited, so it may not get done "soon". There > is some small chance it may get done this weekend :-} However, there > are other code changes that pkg-get is needing too, that have higher > priority. Understandable. I'd offer to submit patches, but in this case, I think having the standard implemented by two separate people would provide some value. Anyone else interested? > > There is already growing use of and demand for hooks, so not > > having it in pkg-get will present us with some problems... > > problems? Call them like annoyances, I guess. If William's popularity contest hooks generate interest, their value will be crippled by only getting triggered at sites using pkgutil. It would be of more value to us to limit our participants like that. > hooks are supposed to be *optional* things. If people are using > hooks for package-mandatory things, there is a problem in packaging. Yes, they are. 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 Wed Nov 11 09:12:29 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 11 Nov 2009 09:12:29 +0100 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> Message-ID: <1E24A070-7F38-4B29-A9D4-39753F8C84FF@opencsw.org> Hi Phil, Am 10.11.2009 um 22:00 schrieb Philip Brown: >> There is >> already growing use of and demand for hooks, so not having it in >> pkg-get will present us with some problems... > > problems? > > hooks are supposed to be *optional* things. If people are using hooks > for package-mandatory things, there is a problem in packaging. > > I will remind you, that our packages should be installable by ANY SVR4 > valid method. > including "wget blah.pkg ; pkgadd -d blah.pkg". We have massive inconsistencies in the catalog for package names which could easily be cleaned up with an upgrade-script detecting old names and mapping them to new names. Additionally, these hooks would have solved easily - the XML migration where Ben put out that script - the esound-removal problem where I provided the snippet for you > If the package does not function when added like that, then the > package is improperly put together. Yes. And if the package has already been released like the old esound? Than what? Without hooks your doomed. Best regards -- Dago From bwalton at opencsw.org Wed Nov 11 13:30:46 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 11 Nov 2009 07:30:46 -0500 Subject: [csw-maintainers] Fwd: git.opencsw.org In-Reply-To: <871F5833-A77C-47EA-8637-A39010F652FB@baltic-online.de> References: <357F703B-8DC8-4CD8-9726-B19B8B6B299E@baltic-online.de> <871F5833-A77C-47EA-8637-A39010F652FB@baltic-online.de> Message-ID: <1257942609-sup-1516@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Nov 11 04:45:43 -0500 2009: Hi Dago, > Should be working now. It works like a charm. For anyone interested, in order to use this (with write access), we'll need ssh public keys from the locations you'd want to connect from. These could be submitted by your or pulled from your authorized keys files on the buildfarm. Multiple keys are fine. We'll create a group that represents the collection of all of your keys and then assign rights based on that group instead of individual keys. 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 Wed Nov 11 15:58:24 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 11 Nov 2009 15:58:24 +0100 Subject: [csw-maintainers] New cswclassutils: cswcron, cswtexinfo, cswmigrateconf and GAR integration Message-ID: <0691F15A-1BF5-4817-968F-449FC848E2D7@opencsw.org> Hi, as of r7226 and cswclassutils 1.28 there is support for three new classes: - cswcron allows modifying of the crontab - cswtexinfo allows automatic addition of .info files to the texinfo dir - cswmigrateconf allows easy migration of config files from /opt/csw/etc to /etc/opt/csw The usage has been documented at Best regards -- Dago From phil at bolthole.com Thu Nov 12 19:06:09 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 12 Nov 2009 10:06:09 -0800 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: <1E24A070-7F38-4B29-A9D4-39753F8C84FF@opencsw.org> References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> <1E24A070-7F38-4B29-A9D4-39753F8C84FF@opencsw.org> Message-ID: On Wed, Nov 11, 2009 at 12:12 AM, Dagobert Michelsen wrote: > Am 10.11.2009 um 22:00 schrieb Philip Brown: >> If the package does not function when [pkgadd'd directly], then the >> package is improperly put together. > > Yes. And if the package has already been released like the old esound? > Than what? Without hooks your doomed. > doomed, is a strong word :) If one chooses to not use automated package management tools, then by definition, one will be stuck doing more things manually. However that does point out, that if a maintainer is tempted to try to do "clever" things in a hook for mistake cleanup purposes, said maintainer should instead implement this "cleverness" in normal preinstall type scripts, so that it will work with straight pkgadd. So.. if this applies to you, Mr. Michelsen, please RE-fix your esound package ;-) From dam at opencsw.org Thu Nov 12 20:11:39 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 12 Nov 2009 20:11:39 +0100 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> <1E24A070-7F38-4B29-A9D4-39753F8C84FF@opencsw.org> Message-ID: <6A933C5E-433C-4130-B704-6DE96079AA7B@opencsw.org> Hi Phil, Am 12.11.2009 um 19:06 schrieb Philip Brown: > On Wed, Nov 11, 2009 at 12:12 AM, Dagobert Michelsen > wrote: >> Am 10.11.2009 um 22:00 schrieb Philip Brown: >>> If the package does not function when [pkgadd'd directly], then the >>> package is improperly put together. >> >> Yes. And if the package has already been released like the old >> esound? >> Than what? Without hooks your doomed. > > doomed, is a strong word :) > If one chooses to not use automated package management tools, then by > definition, one will be stuck doing more things manually. > > However that does point out, that if a maintainer is tempted to try to > do "clever" things in a hook for mistake cleanup purposes, said > maintainer should instead implement this "cleverness" in normal > preinstall type scripts, so that it will work with straight pkgadd. > > So.. if this applies to you, Mr. Michelsen, please RE-fix your esound > package ;-) If a package erranously removes a modified config-file on removal I obviously cannot fix that in the new package and the old package is already out. But I could put a copy aside in a postremove-hook and copy it back-in before the new package is installed :) Best regards -- Dago From phil at bolthole.com Thu Nov 12 20:17:35 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 12 Nov 2009 11:17:35 -0800 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: <6A933C5E-433C-4130-B704-6DE96079AA7B@opencsw.org> References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> <1E24A070-7F38-4B29-A9D4-39753F8C84FF@opencsw.org> <6A933C5E-433C-4130-B704-6DE96079AA7B@opencsw.org> Message-ID: On Thu, Nov 12, 2009 at 11:11 AM, Dagobert Michelsen wrote: > > If a package erranously removes a modified config-file on removal > I obviously cannot fix that in the new package and the old package > is already out. But I could put a copy aside in a postremove-hook > and copy it back-in before the new package is installed :) wait, what? you can modify behaviour of the former package, by newer packages, with this stuff? yikes. and what about the potential of old package hooks conflicting with new package hooks? This sounds like a very hairy capability. From dam at opencsw.org Thu Nov 12 20:28:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 12 Nov 2009 20:28:17 +0100 Subject: [csw-maintainers] hooks in pkg-get In-Reply-To: References: <1257883983-sup-2474@ntdws12.chass.utoronto.ca> <1E24A070-7F38-4B29-A9D4-39753F8C84FF@opencsw.org> <6A933C5E-433C-4130-B704-6DE96079AA7B@opencsw.org> Message-ID: <05819A4E-2511-4516-A1B1-7BA8295CEBA3@opencsw.org> Hi Phil, Am 12.11.2009 um 20:17 schrieb Philip Brown: > On Thu, Nov 12, 2009 at 11:11 AM, Dagobert Michelsen > wrote: >> >> If a package erranously removes a modified config-file on removal >> I obviously cannot fix that in the new package and the old package >> is already out. But I could put a copy aside in a postremove-hook >> and copy it back-in before the new package is installed :) > > wait, what? > you can modify behaviour of the former package, by newer packages, > with this stuff? The hook can be called if one package is upgraded with another, before a package is removed and before a package is installed, etc. > yikes. > and what about the potential of old package hooks conflicting with new > package hooks? > This sounds like a very hairy capability. I guess the hooks will be distributed in a package CSWpkghooks or something. It should be updated before any other package on each update invocation and allows fixing these ugly things by calling scripts before malicous actions can take place. As I wrote before this would have allowed for the complicated XML-transition from Ben, the esound-problem, package renames and all other weird stuff. It is *the* chance to clean up once and for all. Best regards -- Dago From maciej at opencsw.org Fri Nov 13 19:09:11 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 13 Nov 2009 18:09:11 +0000 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> Message-ID: On Wed, Oct 14, 2009 at 5:27 PM, Maciej (Matchek) Blizinski wrote: > One more problem: It doesn't compile it on build8s, while it does on > my local machine at work. Here's what happens on build8s: > > checking for GTK+ - version >= 2.0.0... no > (...) Dago fixed this -- thanks! There's one more problem with this library. The existing Solaris 8 wxwidgets is compiled with unicode support. If it was compiled with Unicode on Solaris, there has to be a way of doing that, I just don't know what it is. I haven't been able to compile unicode-enabled version on Solaris 8 due to missing wide characters function. I don't know how it was compiled on Solaris 8, but it sure required some patching of the code, or copying files from Solaris 9, or something similar. The current build file disables unicode on Solaris 8: # Unicode-enabled build on Solaris 8 fails with: # "./src/common/wxchar.cpp", line 1693: Error: The function "vswscanf" must have # a prototype. # Building Unicode support for Solaris 9 and 10 only. CONFIGURE_ARGS_5.8 = --disable-unicode CONFIGURE_ARGS_5.9 = --enable-unicode CONFIGURE_ARGS_5.10 = --enable-unicode To refresh the state on this, there is gnulib, which provides this function, but on their website they're saying: http://www.gnu.org/software/gnulib/manual/html_node/vswscanf.html """Portability problems not fixed by Gnulib: * This function is missing on some platforms: NetBSD 3.0, OpenBSD 3.8, AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 8, Cygwin 1.5.x, Interix 3.5, BeOS. """ However, Dago thinks that GNUlib can fix the problem. I don't have a lot of spare cycles right now, so if anyone wants to pick up the work, everything is in the repository. Maciej From phil at bolthole.com Fri Nov 13 19:33:58 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 13 Nov 2009 10:33:58 -0800 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> Message-ID: On Fri, Nov 13, 2009 at 10:09 AM, Maciej (Matchek) Blizinski wrote: > > To refresh the state on this, there is gnulib, which provides this > function, but on their website they're saying: > http://www.gnu.org/software/gnulib/manual/html_node/vswscanf.html > > """Portability problems not fixed by Gnulib: > > ? ?* This function is missing on some platforms: NetBSD 3.0, OpenBSD > 3.8, AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 8, Cygwin 1.5.x, > Interix 3.5, BeOS. """ > > However, Dago thinks that GNUlib can fix the problem. I do seem to recall that the original maintainer fixed it with some gnulib code hacking/inclusion. From maciej at opencsw.org Fri Nov 13 20:06:07 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 13 Nov 2009 19:06:07 +0000 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <4ABD1B60.5060700@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> Message-ID: 2009/9/25 Trygve Laugst?l : > Ben Walton wrote: >> Excerpts from Sebastian Kayser's message of Thu Sep 24 17:38:12 -0400 2009: >>> So how about >>> 1) If it's a pure module, py_. >>> 2) If it's main use is as application, . >>> 3) In case of doubt, cross-check with other distributions?. >> >> Logical and concise. ?+1. > > Ditto. +1. There's also the question of pkgnames, is it CSWpyfoo or CSWpy-foo? If one follows the rule that "each _ becomes a -", we sometimes end up with CSWpy-foo and sometimes CSWpyfoo. I wrote down what I thought is the outcome of this policy (except for the point 3). Here's the table: http://wiki.opencsw.org/python-packages-naming Maciej From dam at opencsw.org Fri Nov 13 20:49:47 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 13 Nov 2009 20:49:47 +0100 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> Message-ID: <9BC48749-BD2C-442A-AB38-ECFC78D04EF5@opencsw.org> Hi, Am 13.11.2009 um 19:09 schrieb Maciej (Matchek) Blizinski: > There's one more problem with this library. The existing Solaris 8 > wxwidgets is compiled with unicode support. If it was compiled with > Unicode on Solaris, there has to be a way of doing that, I just don't > know what it is. I haven't been able to compile unicode-enabled > version on Solaris 8 due to missing wide characters function. I don't > know how it was compiled on Solaris 8, but it sure required some > patching of the code, or copying files from Solaris 9, or something > similar. This focus on Solaris 8 leads in the wrong direction as we officially deprecated it. If it is hard to do on Solaris 8 than we shouldn't spend effort in it and start releasing with Solaris 9 full features. In addition to this there are only 4 packages depending on wxwidgets: - xchm (Windows CHM Help Browser) - rapidsvn (SVN GUI Frontend) - kicad (Electronic Layout Software) - boincmanager (successor of SETI at home) The only application I would consider important here is kicad, which is actively maintained by Dominique. xchm was maintained by Alessio and I have successfully rebuilt it in GAR. rapidsvn is also from Alessio and may be as easy to redo. boinc is actively maintained by Eric. What I am saying is that we should concentrate on updating the dependent packages starting with Solaris 9 full featured, maybe without legacy libs, and leave Solaris 8 as is. > However, Dago thinks that GNUlib can fix the problem. I don't have a > lot of spare cycles right now, so if anyone wants to pick up the work, > everything is in the repository. I don't think this anymore, it will certainly take a day to do this right which would better be spend with other things moving forward. Best regards -- Dago From dam at opencsw.org Fri Nov 13 20:52:24 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 13 Nov 2009 20:52:24 +0100 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> Message-ID: <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> Hi Maciej, Am 13.11.2009 um 20:06 schrieb Maciej (Matchek) Blizinski: > 2009/9/25 Trygve Laugst?l : >> Ben Walton wrote: >>> Excerpts from Sebastian Kayser's message of Thu Sep 24 17:38:12 >>> -0400 2009: >>>> So how about >>>> 1) If it's a pure module, py_. >>>> 2) If it's main use is as application, . >>>> 3) In case of doubt, cross-check with other distributions?. >>> >>> Logical and concise. +1. >> >> Ditto. +1. > > There's also the question of pkgnames, is it CSWpyfoo or CSWpy-foo? If > one follows the rule that "each _ becomes a -", we sometimes end up > with CSWpy-foo and sometimes CSWpyfoo. > > I wrote down what I thought is the outcome of this policy (except for > the point 3). Here's the table: > http://wiki.opencsw.org/python-packages-naming This is a good writeup! I would have wished we had this for other packages a long time ago. The current standard however discourages the use of '-' in package names for *devel, *rt, etc. Don't get me wrong: I don't like the way it is, but there is at least some consistency in not having hyphens at all and converting the packages would require hooks to clean up. Having a consistent mapping between catalogname and packagenames is a Very Good Thing(tm), but I don't see how we can achieve it with the technology we have right now. Best regards -- Dago From rupert at opencsw.org Sat Nov 14 20:03:59 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 14 Nov 2009 20:03:59 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <20091110134933.GC30301@sebastiankayser.de> References: <4ADA85FA.7090506@opencsw.org> <20091110134933.GC30301@sebastiankayser.de> Message-ID: <6af4270911141103p550e49ebr208a62ae9cdf3836@mail.gmail.com> On Tue, Nov 10, 2009 at 14:49, Sebastian Kayser wrote: > * Maciej (Matchek) Blizinski wrote: > > On Tue, Oct 20, 2009 at 8:07 PM, Philip Brown wrote: > > > On Tue, Oct 20, 2009 at 9:23 AM, Maciej (Matchek) Blizinski > > > wrote: > > >> > > >> An idea for the change... from the perspective of the operating > > >> system, it won't be really a rename, there is still going to be a > > >> CSWpysvn package, only with a different content. > > > > > > > > > you say "only", but that is what makes it WORSE! :-/ > > > > Not necessarily. We ship library packages with multiple libraries in > > them. We potentially could ship both subversion-core and pysvn > > libraries in the same package. No renaming, but merging > > python-subversion libraries. It's a problem equivalent to the shared > > library problem, which is solved already. > > > > > I have said the order and timeline of what I think is the best path to > take. > > > That still stands. > > > > Your timeline means that submitpkg won't be able to generate > > changelists for $time_to_build_new_subversion_packages + one month. > > I'd like to operate quicker than that. Any problems with this > > approach? > > Any progress on the "new subversion/trac packages" front? I have had > internal requests for 1.6.6 (quite a bit of bugfixes [1] from our > current/ 1.6.2) and saw that a 1.6.5 build recipe with the adjusted > python bindings package name is already in GAR. > > Sebastian > > [1] http://svn.collab.net/repos/svn/trunk/CHANGES > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > i compiled it and put it in testing - as we want to do that upgrade as well soon. i made it world writeable so anybody can overwrite it in case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Nov 15 14:03:02 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 15 Nov 2009 13:03:02 +0000 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> Message-ID: On Mon, Nov 9, 2009 at 6:57 PM, Philip Brown wrote: > On Sun, Nov 8, 2009 at 2:58 PM, Maciej (Matchek) Blizinski > wrote: >> >> We didn't make the tests pass with the 5.0.x. ?We don't know if the >> 5.0.51,REV=2008.01.20 was passing the tests. ?If it wasn't, releasing >> my 5.0.84 would not mean any degradation in the QA of the package. ?If >> it was, it would be nice to know what was done to make the tests pass. >> ?I don't know if it makes sense to invest time in 5.0.x. tests if >> we're going to move on to 5.1 soon. > > i agree that so long as your 5.0.x version passes *at least the same > tests as our existing package*, it is fine to release,and then focus > efforts on 5.1 > > the only remaining question is, which tests does our existing pass? I know that Phil ran the tests and most of them passed. I've built 5.0.87 on Friday, I think this package is at least as good as the existing one. The concern might be the migration from the older package which uses /opt/csw/var and /opt/csw/etc. Perhaps it's a good thing to first release a package which doesn't do much changes to MySQL version (only a patchlevel upgrade), migrate the configuration files, and after some time, when the updated 5.0.x will have been in current/ for ~1 month, release the version 5.1. Maciej From maciej at opencsw.org Sun Nov 15 14:15:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 15 Nov 2009 13:15:01 +0000 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> Message-ID: On Fri, Nov 13, 2009 at 7:52 PM, Dagobert Michelsen wrote: > This is a good writeup! I would have wished we had this for > other packages a long time ago. The current standard however > discourages the use of '-' in package names for *devel, *rt, > etc. Is this guideline documented? > Don't get me wrong: I don't like the way it is, but there > is at least some consistency in not having hyphens at all > and converting the packages would require hooks to clean up. > Having a consistent mapping between catalogname and > packagenames is a Very Good Thing(tm), but I don't see > how we can achieve it with the technology we have right now. Suppose we use hyphens for new packages, and leave the existing ones without hyphens. It will make the new package names suck less^W^W be more readable, and won't cause any technical problems. Perhaps some day we'll have technology which allows us to migrate the package names, if we care enough. If you think we should create new packages without hyphens, let's make sure it's documented and findable. Maciej From trygvis at opencsw.org Sun Nov 15 18:35:41 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 15 Nov 2009 18:35:41 +0100 Subject: [csw-maintainers] Issues with generated prototype+spaces in paths Message-ID: <4B003BED.5080302@opencsw.org> Howdy Is there any magic in GAR to handle paths with spaces? [1]. I have a package (pcb) that I'm trying to complete that include a library of components that have spaces in them. pkgmk actually core dumped on these lines: f none /opt/csw/share/pcb/pcblib-newlib/connector/single-ended SCSI.fp=/home/trygvis/dev/org.opencsw/mgar/pkg/pcb/trunk/work/pkgroot/opt/csw/share/pcb/pcblib-newlib/connector/single-ended root bin trygvis other f none /opt/csw/share/pcb/pcblib-newlib/connector/single-ended SCSI.png=/home/trygvis/dev/org.opencsw/mgar/pkg/pcb/trunk/work/pkgroot/opt/csw/share/pcb/pcblib-newlib/connector/single-ended root bin trygvis other When I excluded those paths with EXTRA_MERGE_EXCLUDE_FILES, it choked on these: f none /opt/csw/share/pcb/pcblib-newlib/generic/1 MHz root bin OSC.fp 0644 trygvis other So, I wonder. Why does the prototype generator include a real path to some of the files, and is it a bug that it doesn't escape the paths with spaces? I'll try to build it with with an exclusion on all paths with spaces to see if that'll fix it. [1]: Is this at all possible with the pkg* tools? -- Trygve From dam at opencsw.org Sun Nov 15 21:54:25 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 15 Nov 2009 21:54:25 +0100 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> Message-ID: <432EECCE-5EA4-4464-8254-F9E6CB38D840@opencsw.org> Hi Maciej, Am 15.11.2009 um 14:15 schrieb Maciej (Matchek) Blizinski: > On Fri, Nov 13, 2009 at 7:52 PM, Dagobert Michelsen > wrote: >> This is a good writeup! I would have wished we had this for >> other packages a long time ago. The current standard however >> discourages the use of '-' in package names for *devel, *rt, >> etc. > > Is this guideline documented? Yes, here: http://www.opencsw.org/standards/pkgcreation >> Don't get me wrong: I don't like the way it is, but there >> is at least some consistency in not having hyphens at all >> and converting the packages would require hooks to clean up. >> Having a consistent mapping between catalogname and >> packagenames is a Very Good Thing(tm), but I don't see >> how we can achieve it with the technology we have right now. > > Suppose we use hyphens for new packages, and leave the existing ones > without hyphens. It will make the new package names suck less^W^W be > more readable, and won't cause any technical problems. Perhaps some > day we'll have technology which allows us to migrate the package > names, if we care enough. > > If you think we should create new packages without hyphens, let's make > sure it's documented and findable. It is documented. Please review http://www-mockup.opencsw.org/ that it is at a decent location. Best regards -- Dago From dam at opencsw.org Sun Nov 15 21:59:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 15 Nov 2009 21:59:32 +0100 Subject: [csw-maintainers] Issues with generated prototype+spaces in paths In-Reply-To: <4B003BED.5080302@opencsw.org> References: <4B003BED.5080302@opencsw.org> Message-ID: <6E0ECA76-3A40-4341-854A-BBC780BCB753@opencsw.org> Hi Trygve, Am 15.11.2009 um 18:35 schrieb Trygve Laugst?l: > Is there any magic in GAR to handle paths with spaces? [1]. I have a > package (pcb) that I'm trying to complete that include a library of > components that have spaces in them. Exactly this thing has been discussed in March, where Roger also tried to package up pcb: Best regards -- Dago From maciej at opencsw.org Mon Nov 16 09:13:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 16 Nov 2009 08:13:54 +0000 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) Message-ID: On Fri, Nov 13, 2009 at 7:49 PM, Dagobert Michelsen wrote: > Hi, > > Am 13.11.2009 um 19:09 schrieb Maciej (Matchek) Blizinski: > >> However, Dago thinks that GNUlib can fix the problem. ?I don't have a >> lot of spare cycles right now, so if anyone wants to pick up the work, >> everything is in the repository. > > I don't think this anymore, it will certainly take a day to do > this right which would better be spend with other things > moving forward. Not that I disagree, but I've decided to give it another go. I'm a bit criss-cross, I know. I just thought that if it has been built before, there must be a way and I wanted to know what was it. Here are my findings: gnulib in fact does not have any code that implements vswscanf, its documentation tells the truth. After adding -D__EXTENSIONS__ another function started being a problem: vsscanf. A grep through /opt/csw/include revealed that ncursesw provides an implementation of this function, so I added a patch including the ncursesw include and it started compiling. There was one more problem with linking where the monolithic version Makefile was missing an object file and was missing symbols. As a side note, patching old versions of libraries is a bit frustrating, as the patches won't get accepted upstream, yet must be written. The next hoop was a missing symbol (on x86 only): __sincos. Fixed by throwing in -lsunmath. It finally built fine: we now have unicode-enabled wxwidgets for Solaris 8, both sparc and x86. Yey! For the curious, here's the overview of the update. Most importantly, /opt/csw/lib/libwx_gtk2u-2.8.so.0.2.0 stays in to preserve backward compatibility. Since the newly built wxwidgets have the contrib module turned on, there's a bunch of 0.2.0 files that aren't in the current/ (wxwidgets_gtk2-2.8.5) package. The new package has been built as a modular library, because it's the upstream default. wxwidgets_common gained some new files. They make the package architecture dependent, wxwidgets_common-2.8.5-SunOS5.8-all-CSW becomes wxwidgets_common-2.8.10,REV=2009.11.16-SunOS5.8-sparc-CSW. The devel package gained some new files too. Notably, there's /opt/csw/include/wx-2.8/wx/stc/stc.h which is required for the once requested pgadmin3. The comparepkg diffs: wxwidgets_gtk2 http://dpaste.com/120986/ wxwidgets_common http://dpaste.com/120990/ wxwidgets_devel: http://dpaste.com/120992/ New packages are now available for testing. Maciej From james at opencsw.org Mon Nov 16 10:57:37 2009 From: james at opencsw.org (James Lee) Date: Mon, 16 Nov 2009 09:57:37 GMT Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> Message-ID: <20091116.9573700.2235360213@gyor.oxdrove.co.uk> On 13/11/09, 19:52:24, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)?: > Having a consistent mapping between catalogname and > packagenames is a Very Good Thing(tm), but I don't see > how we can achieve it with the technology we have right now. It's completely achievable and always has been. People have simply chosen not to. Don't put restricted characters in the names, e.g. no '-' and '_'. James. From maciej at opencsw.org Mon Nov 16 12:34:36 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 16 Nov 2009 11:34:36 +0000 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: Message-ID: I tried to run rapidsvn in a vnc server. No joy: maciej at vsol01 pkg $ rapidsvn Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". Segmentation Fault (core dumped) Perhaps it was because of the vnc server? Is rapidsvn running with wxwidgets 2.8.10 for you? Maciej From maciej at opencsw.org Mon Nov 16 12:40:34 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 16 Nov 2009 11:40:34 +0000 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: Message-ID: On Mon, Nov 16, 2009 at 11:34 AM, Maciej (Matchek) Blizinski wrote: > I tried to run rapidsvn in a vnc server. ?No joy: > > maciej at vsol01 pkg $ rapidsvn > Xlib: ?extension "Generic Event Extension" missing on display ":1.0". > Xlib: ?extension "Generic Event Extension" missing on display ":1.0". > Xlib: ?extension "Generic Event Extension" missing on display ":1.0". > Segmentation Fault (core dumped) > > Perhaps it was because of the vnc server? ?Is rapidsvn running with > wxwidgets 2.8.10 for you? I downgraded the wxwidgets_gtk2 package from 2.8.10 to 2.8.5. rapidsvn worked, only threw some warnings: maciej at vsol01 pkg $ rapidsvn Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". Xlib: extension "Generic Event Extension" missing on display ":1.0". (rapidsvn:9295): Gtk-WARNING **: Unable to locate theme engine in module_path: "xfce", (rapidsvn:9295): Gtk-WARNING **: Unable to locate theme engine in module_path: "xfce", (rapidsvn:9295): Gtk-WARNING **: Unable to locate theme engine in module_path: "xfce", a (rapidsvn:9295): Gdk-CRITICAL **: file gdkproperty-x11.c: line 192: assertion `atom != GDK_NONE' failed It means that it doesn't like the new package and segfaults on it. Any ideas why a recompiled library of the same version might segfault? Perhaps we should just include the old binaries in the new package. From skayser at opencsw.org Mon Nov 16 15:42:38 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 16 Nov 2009 15:42:38 +0100 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: Message-ID: <20091116144238.GA1788@sebastiankayser.de> * Maciej (Matchek) Blizinski wrote: > I tried to run rapidsvn in a vnc server. No joy: > > maciej at vsol01 pkg $ rapidsvn > Xlib: extension "Generic Event Extension" missing on display ":1.0". > Xlib: extension "Generic Event Extension" missing on display ":1.0". > Xlib: extension "Generic Event Extension" missing on display ":1.0". > Segmentation Fault (core dumped) Benny had some weird problems when re-packaging pureftpd and IIRC traced it down to the application being compiled against a variant of crypt() (or similar) and run-time-linked against another one which expected its arguments to be a tad different (symbol was present in two libs, both linked into the application). Could be seen with some debugging. Could our mixed X11 libs environment cause similar problems? Sebastian From skayser at opencsw.org Mon Nov 16 15:46:47 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 16 Nov 2009 15:46:47 +0100 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: <20091116144238.GA1788@sebastiankayser.de> References: <20091116144238.GA1788@sebastiankayser.de> Message-ID: <20091116144647.GB1788@sebastiankayser.de> * Sebastian Kayser wrote: > * Maciej (Matchek) Blizinski wrote: > > I tried to run rapidsvn in a vnc server. No joy: > > > > maciej at vsol01 pkg $ rapidsvn > > Xlib: extension "Generic Event Extension" missing on display ":1.0". > > Xlib: extension "Generic Event Extension" missing on display ":1.0". > > Xlib: extension "Generic Event Extension" missing on display ":1.0". > > Segmentation Fault (core dumped) > > Benny had some weird problems when re-packaging pureftpd and IIRC traced > it down to the application being compiled against a variant of crypt() > (or similar) and run-time-linked against another one which expected its > arguments to be a tad different (symbol was present in two libs, both > linked into the application). Could be seen with some debugging. To be more specific: weird problems ^= segfaults > Could our mixed X11 libs environment cause similar problems? Sebastian From korpela at opencsw.org Mon Nov 16 22:19:24 2009 From: korpela at opencsw.org (Eric J Korpela) Date: Mon, 16 Nov 2009 13:19:24 -0800 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: Message-ID: I'll try to build boincmanager against the new libraries some time this week From bonivart at opencsw.org Mon Nov 16 22:31:24 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 16 Nov 2009 22:31:24 +0100 Subject: [csw-maintainers] Could someone please update CSWpygtk? Message-ID: <625385e30911161331l54ef66b9o9180de81b37ba9c9@mail.gmail.com> A colleague of mine was trying to install CSWmeld and it obviously needed CSWpygtk so we installed that, more things were missing to get meld running but the main problem seemed to be this already reported bug: http://www.opencsw.org/mantis/view.php?id=3832 -- /peter From skayser at opencsw.org Tue Nov 17 09:46:09 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 17 Nov 2009 09:46:09 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <6af4270911141103p550e49ebr208a62ae9cdf3836@mail.gmail.com> References: <4ADA85FA.7090506@opencsw.org> <20091110134933.GC30301@sebastiankayser.de> <6af4270911141103p550e49ebr208a62ae9cdf3836@mail.gmail.com> Message-ID: <20091117084609.GD1788@sebastiankayser.de> * rupert THURNER wrote: >> On Tue, Nov 10, 2009 at 14:49, Sebastian Kayser <[1]skayser at opencsw.org> >> wrote: >> Any progress on the "new subversion/trac packages" front? I have had >> internal requests for 1.6.6 (quite a bit of bugfixes [1] from our >> current/ 1.6.2) and saw that a 1.6.5 build recipe with the adjusted >> python bindings package name is already in GAR. > > i compiled it and put it in testing - as we want to do that upgrade as > well soon. i made it world writeable so anybody can overwrite it in case. Thanks, Rupert. The GAR build recipe for subversion skips the tests, did you run these for the updated version? Sebastian From maciej at opencsw.org Tue Nov 17 11:20:56 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 10:20:56 +0000 Subject: [csw-maintainers] Could someone please update CSWpygtk? In-Reply-To: <625385e30911161331l54ef66b9o9180de81b37ba9c9@mail.gmail.com> References: <625385e30911161331l54ef66b9o9180de81b37ba9c9@mail.gmail.com> Message-ID: On Mon, Nov 16, 2009 at 9:31 PM, Peter Bonivart wrote: > A colleague of mine was trying to install CSWmeld and it obviously > needed CSWpygtk so we installed that, more things were missing to get > meld running but the main problem seemed to be this already reported > bug: > > http://www.opencsw.org/mantis/view.php?id=3832 This breakage sucks. Which pygtk version are we aiming for? 1.14, 1.15 or 1.16? The pygtk website says that 1.14 is stable. Which pygtk version does meld require? Maciej From maciej at opencsw.org Tue Nov 17 11:57:38 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 10:57:38 +0000 Subject: [csw-maintainers] Could someone please update CSWpygtk? In-Reply-To: References: <625385e30911161331l54ef66b9o9180de81b37ba9c9@mail.gmail.com> Message-ID: On Tue, Nov 17, 2009 at 10:20 AM, Maciej (Matchek) Blizinski wrote: > On Mon, Nov 16, 2009 at 9:31 PM, Peter Bonivart wrote: >> A colleague of mine was trying to install CSWmeld and it obviously >> needed CSWpygtk so we installed that, more things were missing to get >> meld running but the main problem seemed to be this already reported >> bug: >> >> http://www.opencsw.org/mantis/view.php?id=3832 > > This breakage sucks. ?Which pygtk version are we aiming for? ?1.14, > 1.15 or 1.16? ?The pygtk website says that 1.14 is stable. ?Which > pygtk version does meld require? I looked at the newest pygtk. It requires newer pygobject than the one in catalog. I looked at pygobject, got it to compile on Solaris 10 x86, then went and tried building it on the buildfarm. I got an error: maciej at build8x [build8x]:~/src/opencsw/pkg/pygobject/trunk > (cd /home/maciej/src/opencsw/pkg/pygobject/trunk/work/solaris8-i386/build-isa-i386/pygobject-2.20.0/gobject; /bin/bash ../libtool --tag=CC --mode=link /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT -D_PTHREADS -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/python2.6 -I/opt/csw/include/python2.6 -lglib-2.0 -xO3 -xarch=386 -I/opt/csw/include -xarch=386 -L/opt/csw/lib -o generate-constants generate_constants-generate-constants.o) libtool: link: /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT -D_PTHREADS -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/python2.6 -I/opt/csw/include/python2.6 -xO3 -xarch=386 -I/opt/csw/include -xarch=386 -o generate-constants generate_constants-generate-constants.o -lglib-2.0 -L/opt/csw/lib ld: fatal: library -lglib-2.0: not found ld: fatal: File processing errors. No output written to generate-constants I don't quite get it. The library is there on the disk: maciej at build8x [build8x]:~/src/opencsw/pkg/pygobject/trunk > ls -l /opt/csw/lib/libglib-2.0.so* lrwxrwxrwx 1 root other 23 Apr 28 2009 /opt/csw/lib/libglib-2.0.so -> libglib-2.0.so.0.2000.0 lrwxrwxrwx 1 root other 23 Apr 28 2009 /opt/csw/lib/libglib-2.0.so.0 -> libglib-2.0.so.0.2000.0 -rwxr-xr-x 1 root bin 1190120 Apr 9 2009 /opt/csw/lib/libglib-2.0.so.0.2000.0 There's also the -L/opt/csw/lib flag. What else does it need to find the library? Has anyone seen such a problem before? Maciej From james at opencsw.org Tue Nov 17 12:23:04 2009 From: james at opencsw.org (James Lee) Date: Tue, 17 Nov 2009 11:23:04 GMT Subject: [csw-maintainers] Could someone please update CSWpygtk? In-Reply-To: References: Message-ID: <20091117.11230400.3792129617@gyor.oxdrove.co.uk> On 17/11/09, 10:57:38, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] Could someone please update CSWpygtk?: > libtool: link: /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT > -D_PTHREADS -I/opt/csw/include/glib-2.0 > -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/python2.6 > -I/opt/csw/include/python2.6 -xO3 -xarch=386 -I/opt/csw/include > -xarch=386 -o generate-constants > generate_constants-generate-constants.o -lglib-2.0 -L/opt/csw/lib > ld: fatal: library -lglib-2.0: not found > ld: fatal: File processing errors. No output written to > generate-constants > I don't quite get it. The library is there on the disk: ... > There's also the -L/opt/csw/lib flag. What else does it need to find > the library? Our dear friend libtool. It's added the L path but after the lib. James. From maciej at opencsw.org Tue Nov 17 15:58:34 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 14:58:34 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 Message-ID: I'm looking at building postgresql-8.4.1. I used this db engine before a lot and I'd like to have its recent version. The main problem with compilation is this: http://archives.postgresql.org/pgsql-general/2009-11/msg00687.php In short, the old includes from /opt/csw/postgresql/include are breaking the build. How would you fix it? I guess that uninstalling the devel postgresql package would help, but it's not the proper solution. It looks like a general problem: suppose there are old, incompatible header files in the include/ directory. The application needs include its foo.h, which is present in both /opt/csw/include/ and its source directory. The code using the header file just says: #include "foo.h" The foo.h file is also in, say ../../../src/include. The compiler invocation looks like this: /opt/studio/SOS11/SUNWspro/bin/cc -Xa -xO3 -xarch=v8 -I/opt/csw/include -I../../../src/include -I/opt/csw/include -c -o nodeGroup.o nodeGroup.c What should it look like to compile correctly, assuming that the /opt/csw/include/foo.h files is incompatible with the software being built? Maciej From maciej at opencsw.org Tue Nov 17 16:15:44 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 15:15:44 +0000 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: On Fri, Oct 23, 2009 at 4:48 PM, Philip Brown wrote: > On Fri, Oct 23, 2009 at 8:27 AM, Maciej (Matchek) Blizinski > wrote: >> >> There's no default; you're supposed to create your own ~/.garrc, and >> the sample file contains: >> >> ${HOME}/staging/build-$(date '+%d.%b.%Y') >>[...] >> I prefer ISO standards for dates[(it builds better)] > > definately :-) > > Hmmm. the non-deterministic nature of that, would make it slightly > difficult to have any kind of automated, > "Go autobuild 10 packages and add them" > script at a customer site. > > How many people are using something else there, and if so, what? I think it there is a need to provide an API for specifying the pkg destination directory. I can think of a couple of ways: - an environment variable (PKG_DEST_DIR?) - an entry in a configuration file (where would the file be? in what format?) - an argument to the build script (./build --pkg-dest-dir=/home/joe/staging?) Alternatively, the destination directory might be the one in which the build script is. But then it might be hard to separate the newly built packages from any other files that might be in the same directory. Which people think is best? Maciej From dam at opencsw.org Tue Nov 17 17:45:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 17:45:22 +0100 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: Message-ID: <83CED7D4-8FCB-4D9D-965F-4D8975BEEF6D@opencsw.org> Hi Erik, Am 16.11.2009 um 22:19 schrieb Eric J Korpela: > I'll try to build boincmanager against the new libraries some time > this week Cool. Let me know if you need additional machines or installs on build*t as the updated wxwidgets library will only be installed on build*s/x after release and there is still an unresolved issue. Best regards -- Dago From phil at bolthole.com Tue Nov 17 17:47:04 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Nov 2009 08:47:04 -0800 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: On Tue, Nov 17, 2009 at 7:15 AM, Maciej (Matchek) Blizinski wrote: > >> How many people are using something else there, and if so, what? > > I think it there is a need to provide an API for specifying the pkg > destination directory. ?I can think of a couple of ways: > > - an environment variable (PKG_DEST_DIR?) > - an entry in a configuration file (where would the file be? in what format?) > - an argument to the build script (./build --pkg-dest-dir=/home/joe/staging?) simplest thing is an environment variable, particularly since most other things (CFLAGS, etc) will be environment variables. I will propose that any csw specific vars, have csw prefix. So, CSW_PKG_DIR perhaps? We also need a good default. I think Mike's example, of $(HOME)/newpkgs is a good default. Can I get a second on that? From phil at bolthole.com Tue Nov 17 17:49:45 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Nov 2009 08:49:45 -0800 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: Message-ID: On Tue, Nov 17, 2009 at 6:58 AM, Maciej (Matchek) Blizinski wrote: > I'm looking at building postgresql-8.4.1. ?I used this db engine > before a lot and I'd like to have its recent version. > > The main problem with compilation is this: > http://archives.postgresql.org/pgsql-general/2009-11/msg00687.php > > In short, the old includes from /opt/csw/postgresql/include are > breaking the build. ?How would you fix it? ?I guess that uninstalling > the devel postgresql package would help, but it's not the proper > solution. actually, its a perfectly reasonable, albeit a little inconvenient, solution. Other packages also require this. To better fix the problem, requires that you convince your "upstream" to make its build environment better, which can sometimes be very difficult. > The foo.h file is also in, say ../../../src/include. The compiler > invocation looks like this: > > /opt/studio/SOS11/SUNWspro/bin/cc -Xa -xO3 -xarch=v8 > -I/opt/csw/include -I../../../src/include -I/opt/csw/include ? -c -o > nodeGroup.o nodeGroup.c If you had the -I../.. first, it should actually work the way you want it. kind of like if you had -L/opt/csw/lib -L/usr/local/lib long as ours are "first", things will work out ok, usually. From bwalton at opencsw.org Tue Nov 17 17:50:57 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 17 Nov 2009 11:50:57 -0500 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: <1258476632-sup-1910@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Nov 17 11:47:04 -0500 2009: > $(HOME)/newpkgs > > is a good default. > Can I get a second on that? I'd switch my .garrc to that. +1. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Tue Nov 17 17:52:27 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 17:52:27 +0100 Subject: [csw-maintainers] Could someone please update CSWpygtk? In-Reply-To: <20091117.11230400.3792129617@gyor.oxdrove.co.uk> References: <20091117.11230400.3792129617@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 17.11.2009 um 12:23 schrieb James Lee: > On 17/11/09, 10:57:38, Maciej "(Matchek)" Blizinski > > wrote regarding Re: [csw-maintainers] Could someone please update > CSWpygtk?: > >> libtool: link: /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT >> -D_PTHREADS -I/opt/csw/include/glib-2.0 >> -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/python2.6 >> -I/opt/csw/include/python2.6 -xO3 -xarch=386 -I/opt/csw/include >> -xarch=386 -o generate-constants >> generate_constants-generate-constants.o -lglib-2.0 -L/opt/csw/lib >> ld: fatal: library -lglib-2.0: not found >> ld: fatal: File processing errors. No output written to >> generate-constants > >> I don't quite get it. The library is there on the disk: > ... >> There's also the -L/opt/csw/lib flag. What else does it need to find >> the library? > > Our dear friend libtool. It's added the L path but after the lib. Nope, look again: > maciej at build8x [build8x]:~/src/opencsw/pkg/pygobject/trunk > (cd > /home/maciej/src/opencsw/pkg/pygobject/trunk/work/solaris8-i386/ > build-isa-i386/pygobject-2.20.0/gobject; > /bin/bash ../libtool --tag=CC --mode=link > /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT -D_PTHREADS > -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include > -I/opt/csw/include/python2.6 -I/opt/csw/include/python2.6 -lglib-2.0 > -xO3 -xarch=386 -I/opt/csw/include -xarch=386 -L/opt/csw/lib -o > generate-constants generate_constants-generate-constants.o) The above is what is passed to libtool. Here the order is already wrong. And I am not only saying this as the libtool-maintainer ;-) Libtool than just passes the order: > libtool: link: /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT > -D_PTHREADS -I/opt/csw/include/glib-2.0 > -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/python2.6 > -I/opt/csw/include/python2.6 -xO3 -xarch=386 -I/opt/csw/include > -xarch=386 -o generate-constants > generate_constants-generate-constants.o -lglib-2.0 -L/opt/csw/lib > ld: fatal: library -lglib-2.0: not found > ld: fatal: File processing errors. No output written to generate- > constants Best regards -- Dago From dam at opencsw.org Tue Nov 17 17:58:14 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 17:58:14 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: Message-ID: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Hi Maciej, Am 17.11.2009 um 15:58 schrieb Maciej (Matchek) Blizinski: > I'm looking at building postgresql-8.4.1. I used this db engine > before a lot and I'd like to have its recent version. > > The main problem with compilation is this: > http://archives.postgresql.org/pgsql-general/2009-11/msg00687.php > > In short, the old includes from /opt/csw/postgresql/include are > breaking the build. How would you fix it? I guess that uninstalling > the devel postgresql package would help, but it's not the proper > solution. It looks like a general problem: suppose there are old, > incompatible header files in the include/ directory. The application > needs include its foo.h, which is present in both /opt/csw/include/ > and its source directory. The code using the header file just says: > > #include "foo.h" > > The foo.h file is also in, say ../../../src/include. The compiler > invocation looks like this: > > /opt/studio/SOS11/SUNWspro/bin/cc -Xa -xO3 -xarch=v8 > -I/opt/csw/include -I../../../src/include -I/opt/csw/include -c -o > nodeGroup.o nodeGroup.c > > What should it look like to compile correctly, assuming that the > /opt/csw/include/foo.h files is incompatible with the software being > built? The problem is that GAR adds the include to CPPFLAGS and CFLAGS. An upstream maintainer (can't remember who) already pointed out that it is not good to pass -I in CPPFLAGS and CFLAGS and that CPPFLAGS would be sufficient. The Makefile from Postgres makes the assumption that it takes CFLAGS, then adds his includes and then the CPPFLAGS. Putting the include in CFLAGS erranously prepends it before his own flags. I had this problem myself some times but didn't recognize the cause properly: grep filter-out */trunk/Makefile | grep CFLAGS I even used argument-reordering on compile invocation for flac to work around it which may have better be solved in the above way. Now that I have understood it I would propose to remove the "-I" from CFLAGS in GAR, but I am afraid that this may break existing Makefiles as they may rely on it. This is especially true for manual builds which pass CFLAGS explicitly without passing CPPFLAGS explicitly. What do the C-gurus say? James? Anybody? Best regards -- Dago From dam at opencsw.org Tue Nov 17 17:59:03 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 17:59:03 +0100 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: Hi Maciej, Am 17.11.2009 um 16:15 schrieb Maciej (Matchek) Blizinski: > On Fri, Oct 23, 2009 at 4:48 PM, Philip Brown > wrote: >> On Fri, Oct 23, 2009 at 8:27 AM, Maciej (Matchek) Blizinski >> wrote: >>> >>> There's no default; you're supposed to create your own ~/.garrc, and >>> the sample file contains: >>> >>> ${HOME}/staging/build-$(date '+%d.%b.%Y') >>> [...] >>> I prefer ISO standards for dates[(it builds better)] >> >> definately :-) >> >> Hmmm. the non-deterministic nature of that, would make it slightly >> difficult to have any kind of automated, >> "Go autobuild 10 packages and add them" >> script at a customer site. >> >> How many people are using something else there, and if so, what? > > I think it there is a need to provide an API for specifying the pkg > destination directory. I can think of a couple of ways: > > - an environment variable (PKG_DEST_DIR?) > - an entry in a configuration file (where would the file be? in what > format?) > - an argument to the build script (./build --pkg-dest-dir=/home/joe/ > staging?) > > Alternatively, the destination directory might be the one in which the > build script is. But then it might be hard to separate the newly > built packages from any other files that might be in the same > directory. > > Which people think is best? I would prefer the environment variable as it is both easy to use and to add to the build tree. Best regards -- Dago From dam at opencsw.org Tue Nov 17 18:06:00 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 18:06:00 +0100 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: <1258476632-sup-1910@ntdws12.chass.utoronto.ca> References: <1258476632-sup-1910@ntdws12.chass.utoronto.ca> Message-ID: <8FCB89D1-8D85-48BB-909A-FD758462DB7A@opencsw.org> Hi, Am 17.11.2009 um 17:50 schrieb Ben Walton: > Excerpts from Philip Brown's message of Tue Nov 17 11:47:04 -0500 > 2009: >> $(HOME)/newpkgs >> >> is a good default. >> Can I get a second on that? > > I'd switch my .garrc to that. +1. Why do we need a default? The API make setting this mandatory. It may be good to have a default in the enclosing build system, but the maintainer should set a use-specific default. So I don't see a need that the inner build-systems need to handle defaults. Best regards -- Dago From phil at bolthole.com Tue Nov 17 18:09:07 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Nov 2009 09:09:07 -0800 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: <8FCB89D1-8D85-48BB-909A-FD758462DB7A@opencsw.org> References: <1258476632-sup-1910@ntdws12.chass.utoronto.ca> <8FCB89D1-8D85-48BB-909A-FD758462DB7A@opencsw.org> Message-ID: On Tue, Nov 17, 2009 at 9:06 AM, Dagobert Michelsen wrote: > Hi, > > Am 17.11.2009 um 17:50 schrieb Ben Walton: >> >> Excerpts from Philip Brown's message of Tue Nov 17 11:47:04 -0500 2009: >>> >>> $(HOME)/newpkgs >>> >>> is a good default. >>> Can I get a second on that? >> >> I'd switch my .garrc to that. ?+1. > > Why do we need a default? The API make setting this mandatory. It may > be good to have a default in the enclosing build system, but the maintainer > should set a use-specific default. So I don't see a need that the inner > build-systems need to handle defaults. > err, are you speaking of "[the gar] build system"? or the "raw API" one? I think you are referring to gar. the "raw API" one does not have setting anything mandatory. In order to keep discussion for this "raw api" thread simple (just like the proposed API ;-), lets please keep discussions of GAR, to a completely different thread From bonivart at opencsw.org Tue Nov 17 18:11:35 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 17 Nov 2009 18:11:35 +0100 Subject: [csw-maintainers] /testing cfengine, cvsproxy, diffuse, oinkmaster, perl, snort Message-ID: <625385e30911170911o7e76ae6bme982ec90ccd7fdc8@mail.gmail.com> I would like some help testing a few packages. If you use any of the below packages in their current versions and have time to test these I would really appreciate it. Note that if you want to test cvsproxy you need to be aware of this bug in the current package: http://www.opencsw.org/mantis/view.php?id=1839. cfengine-2.2.10,REV=2009.11.11-SunOS5.8-i386-CSW.pkg.gz cfengine-2.2.10,REV=2009.11.11-SunOS5.8-sparc-CSW.pkg.gz cfengine_doc-2.2.10,REV=2009.11.11-SunOS5.8-all-CSW.pkg.gz cvsproxy-1.0.1,REV=2009.11.01-SunOS5.8-i386-CSW.pkg.gz cvsproxy-1.0.1,REV=2009.11.01-SunOS5.8-sparc-CSW.pkg.gz diffuse-0.4.1,REV=2009.10.21-SunOS5.8-all-CSW.pkg.gz oinkmaster-2.0,REV=2009.10.19-SunOS5.8-all-CSW.pkg.gz perl-5.8.8,REV=2009.11.12-SunOS5.8-i386-CSW.pkg.gz perl-5.8.8,REV=2009.11.12-SunOS5.8-sparc-CSW.pkg.gz perldoc-5.8.8,REV=2009.11.12-SunOS5.8-all-CSW.pkg.gz snort-2.8.5,REV=2009.10.19-SunOS5.8-i386-CSW.pkg.gz snort-2.8.5,REV=2009.10.19-SunOS5.8-sparc-CSW.pkg.gz http://mirror.opencsw.org/testing.html -- /peter From phil at bolthole.com Tue Nov 17 18:12:19 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Nov 2009 09:12:19 -0800 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Message-ID: >(Dagobert writes) > I had this problem myself some times but didn't recognize the cause > properly: > ?grep filter-out */trunk/Makefile | grep CFLAGS > I even used argument-reordering on compile invocation for flac to > work around it which may have better be solved in the above way. > Now that I have understood it I would propose to remove > the "-I" from CFLAGS in GAR, but I am afraid that this may break > existing Makefiles as they may rely on it. This is especially true > for manual builds which pass CFLAGS explicitly without passing > CPPFLAGS explicitly. > > What do the C-gurus say? James? Anybody? > In my opinion, it belongs in CPPFLAGS, if you are going to force defaults. (and you should make sure to force our default as "first" :-) package builds that break, will break. Although most shouldnt. Ones that do, will have to be fixed when needed. From dam at opencsw.org Tue Nov 17 18:17:30 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 18:17:30 +0100 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <20091116.9573700.2235360213@gyor.oxdrove.co.uk> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> Message-ID: <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> Hi, Am 16.11.2009 um 10:57 schrieb James Lee: > On 13/11/09, 19:52:24, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] Change python modules catalog names to have a > py_ > prefix (instead of just py)?: > >> Having a consistent mapping between catalogname and >> packagenames is a Very Good Thing(tm), but I don't see >> how we can achieve it with the technology we have right now. > > It's completely achievable and always has been. People have > simply chosen not to. Don't put restricted characters in the > names, e.g. no '-' and '_'. Well, some packages do use "-" in the package name. All Maciej is aiming at is consistency. If we the mapping is "use _ on catalog names under condition x" and "package names are catalog name with '_' removed" that would ok also. Best regards -- Dago From maciej at opencsw.org Tue Nov 17 18:36:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 17:36:54 +0000 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: <1258476632-sup-1910@ntdws12.chass.utoronto.ca> <8FCB89D1-8D85-48BB-909A-FD758462DB7A@opencsw.org> Message-ID: On Tue, Nov 17, 2009 at 5:09 PM, Philip Brown wrote: >> Why do we need a default? The API make setting this mandatory. It may >> be good to have a default in the enclosing build system, but the maintainer >> should set a use-specific default. So I don't see a need that the inner >> build-systems need to handle defaults. >> > > err, are you speaking of "[the gar] build system"? or the "raw API" one? > I think you are referring to gar. the "raw API" one does not have > setting anything mandatory. > In order to keep discussion for this "raw api" thread simple (just > like the proposed API ;-), lets please keep discussions of GAR, to a > completely different thread GAR? What's GAR? ;-) I don't see anything inherently wrong with having a default. Just one thought. Imagine a newcomer who downloads the source, runs the build script and has no clue what files have been created and where. It could be a guideline (?) to print out a useful message at the end of the scripts work: your new shiny files have been created here and here. The default will make it possible for the script to work without any configuration, and the message will make it possible for a newcomer to find their way around the build system. Maciej From maciej at opencsw.org Tue Nov 17 18:50:55 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 17:50:55 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Message-ID: On Tue, Nov 17, 2009 at 5:12 PM, Philip Brown wrote: >>(Dagobert writes) >> I had this problem myself some times but didn't recognize the cause >> properly: >> ?grep filter-out */trunk/Makefile | grep CFLAGS >> I even used argument-reordering on compile invocation for flac to >> work around it which may have better be solved in the above way. >> Now that I have understood it I would propose to remove >> the "-I" from CFLAGS in GAR, but I am afraid that this may break >> existing Makefiles as they may rely on it. This is especially true >> for manual builds which pass CFLAGS explicitly without passing >> CPPFLAGS explicitly. >> >> What do the C-gurus say? James? Anybody? >> > > > In my opinion, it belongs in CPPFLAGS, if you are going to force defaults. Yes, CPPFLAGS are for the C PreProcessor, and it's the preprocessor that takes care of including files. References: http://stackoverflow.com/questions/495598/difference-between-cppflags-and-cxxflags-in-gnu-make http://en.wikipedia.org/wiki/CPPFLAGS > (and you should make sure to force our default as "first" :-) > > package builds that break, will break. Although most shouldnt. > Ones that do, will have to be fixed when needed. I second that. It's worth the trouble. If there's a build that needs includes to be passed via CFLAGS, it's not hard to add them by hand in the Makefile. Maciej From phil at bolthole.com Tue Nov 17 19:00:49 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Nov 2009 10:00:49 -0800 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Message-ID: On Tue, Nov 17, 2009 at 9:50 AM, Maciej (Matchek) Blizinski wrote: > > References: > ... > http://en.wikipedia.org/wiki/CPPFLAGS ooo, i learned something today. CFLAGS is officially for compiling *and linking* C code. I thought it was only for compiling. so adding -L/-R and other arcane stuff to CFLAGS is not technically improper. (Reason I mention this is that I usually add those to LDFLAGS.. but there was ONE program, that would not compile nicely unless I added something to CFLAGS when I thought I could only put it in LDFLAGS. The program was still wrong for not respecting LDFLAGS :-} but at least i feel better about the workaround now ;-) Although in retrospect, if CFLAGS is for linking also, I wonder why GNUheads decided to start using CCLDFLAGS recently? Grrr... From dam at opencsw.org Tue Nov 17 20:03:07 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 20:03:07 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Message-ID: Hi, Am 17.11.2009 um 18:50 schrieb Maciej (Matchek) Blizinski: > Yes, CPPFLAGS are for the C PreProcessor, and it's the preprocessor > that takes care of including files. > > References: > http://stackoverflow.com/questions/495598/difference-between-cppflags-and-cxxflags-in-gnu-make > http://en.wikipedia.org/wiki/CPPFLAGS > >> (and you should make sure to force our default as "first" :-) >> >> package builds that break, will break. Although most shouldnt. >> Ones that do, will have to be fixed when needed. > > I second that. It's worth the trouble. If there's a build that needs > includes to be passed via CFLAGS, it's not hard to add them by hand in > the Makefile. Ok then, I will prepare that for GAR and make a special page in the wiki with major changes to GAR and the revision they occured. That way a maintainer can simply look at all changes since the last build. Best regards -- Dago From james at opencsw.org Tue Nov 17 20:12:53 2009 From: james at opencsw.org (James Lee) Date: Tue, 17 Nov 2009 19:12:53 GMT Subject: [csw-maintainers] Could someone please update CSWpygtk? In-Reply-To: References: <20091117.11230400.3792129617@gyor.oxdrove.co.uk> Message-ID: <20091117.19125300.3743629234@gyor.oxdrove.co.uk> On 17/11/09, 16:52:27, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Could someone please update CSWpygtk?: > >> libtool: link: /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT > >> -D_PTHREADS -I/opt/csw/include/glib-2.0 > >> -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/python2.6 > >> -I/opt/csw/include/python2.6 -xO3 -xarch=386 -I/opt/csw/include > >> -xarch=386 -o generate-constants > >> generate_constants-generate-constants.o -lglib-2.0 -L/opt/csw/lib > >> ld: fatal: library -lglib-2.0: not found > >> ld: fatal: File processing errors. No output written to > >> generate-constants > > > >> I don't quite get it. The library is there on the disk: > > ... > >> There's also the -L/opt/csw/lib flag. What else does it need to find > >> the library? > > > > Our dear friend libtool. It's added the L path but after the lib. > Nope, look again: > > maciej at build8x [build8x]:~/src/opencsw/pkg/pygobject/trunk > (cd > > /home/maciej/src/opencsw/pkg/pygobject/trunk/work/solaris8-i386/ > > build-isa-i386/pygobject-2.20.0/gobject; > > /bin/bash ../libtool --tag=CC --mode=link > > /opt/studio/SOS11/SUNWspro/bin/cc -D_REENTRANT -D_PTHREADS > > -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include > > -I/opt/csw/include/python2.6 -I/opt/csw/include/python2.6 -lglib-2.0 > > -xO3 -xarch=386 -I/opt/csw/include -xarch=386 -L/opt/csw/lib -o > > generate-constants generate_constants-generate-constants.o) > The above is what is passed to libtool. Here the order is already wrong. > And I am not only saying this as the libtool-maintainer ;-) Libtool > than just passes the order: It's using ../libtool so we don't know if you can take credit. Did I say libtool had changed the order? True it's not the script libtool's choice but probably some other part in the "GNU build system" that has the args in the wrong order. The problem remains the same, args not in correct order. If anyone has any doubts about libtool's arg changing powers try: $ libtool --tag=CC --mode=link /bin/echo -o out -zone -lone -ztwo -ltwo James. From james at opencsw.org Tue Nov 17 20:14:43 2009 From: james at opencsw.org (James Lee) Date: Tue, 17 Nov 2009 19:14:43 GMT Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> References: <4A91CB5A.4080109@opencsw.org> <4AB9DE48.8060006@opencsw.org> <4ABAA654.1000706@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> Message-ID: <20091117.19144300.1872225613@gyor.oxdrove.co.uk> On 17/11/09, 17:17:30, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)?: > >> Having a consistent mapping between catalogname and > >> packagenames is a Very Good Thing(tm), but I don't see > >> how we can achieve it with the technology we have right now. > > > > It's completely achievable and always has been. People have > > simply chosen not to. Don't put restricted characters in the > > names, e.g. no '-' and '_'. > Well, some packages do use "-" in the package name. Only through choice, it's not the technology. > All Maciej > is aiming at is consistency. If we the mapping is "use _ on > catalog names under condition x" and "package names are > catalog name with '_' removed" that would ok also. A one way transform so I'd say not "between". You could exchange the '_' for '-' but it wouldn't help me to cut and paste the names. James. From maciej at opencsw.org Tue Nov 17 20:45:24 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Nov 2009 19:45:24 +0000 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <20091117.19144300.1872225613@gyor.oxdrove.co.uk> References: <4A91CB5A.4080109@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> Message-ID: On Tue, Nov 17, 2009 at 7:14 PM, James Lee wrote: > On 17/11/09, 17:17:30, Dagobert Michelsen wrote regarding > Re: [csw-maintainers] Change python modules catalog names to have a py_ > prefix (instead of just py)?: > >> >> Having a consistent mapping between catalogname and >> >> packagenames is a Very Good Thing(tm), but I don't see >> >> how we can achieve it with the technology we have right now. >> > >> > It's completely achievable and always has been. ?People have >> > simply chosen not to. ?Don't put restricted characters in the >> > names, e.g. no '-' and '_'. > >> Well, some packages do use "-" in the package name. > > Only through choice, it's not the technology. > > >> All Maciej >> is aiming at is consistency. If we the mapping is "use _ on >> catalog names under condition x" and "package names are >> catalog name with '_' removed" that would ok also. > > A one way transform so I'd say not "between". ?You could exchange > the '_' for '-' but it wouldn't help me to cut and paste the names. I like the idea of s/_/-/g when going from catalog names to pkgnames. Thissentenceismymainargumentforusingdashesitsjusthardtoread. I would really like to have a blessed word separator for the pkgnames. Sun packages uses cases, the have something like SUNWonewordSECONDWORD. I perceive it as ugly. Speaking of consistency... we can make the choice of being consistent with the existing packages[1] and not introduce dashes. Or we can use dashes for new packages, leaving the current ones alone, to be possibly changed later, if we decide it's important. The consistency I'm definitely for is that we achieve consensus, it gets documented, and we follow it. [1] Currently, there are 48 pkgnames using dashes, out of the total 2171. Maciej From bchill at opencsw.org Tue Nov 17 21:54:53 2009 From: bchill at opencsw.org (Brian Hill) Date: Tue, 17 Nov 2009 20:54:53 +0000 Subject: [csw-maintainers] /testing cfengine, cvsproxy, diffuse, oinkmaster, perl, snort In-Reply-To: <625385e30911170911o7e76ae6bme982ec90ccd7fdc8@mail.gmail.com> References: <625385e30911170911o7e76ae6bme982ec90ccd7fdc8@mail.gmail.com> Message-ID: <20091117205453.GA9219@vm-1.bch.net> I grabbed cfengine-2.2.10 and perl-5.8.8, both of which I use heavily, and they seem to be working well, except that CFE complained about about these two DB files being in an unrecognized format (because you have to get the newer bdb as well): cf_LastSeen.db performance.db Since I don't make use of these, simply deleting them wasn't a problem for me. Brian ====================================================================== On Tue, Nov 17, 2009 at 06:11:35PM +0100, Peter Bonivart wrote: > I would like some help testing a few packages. If you use any of the > below packages in their current versions and have time to test these I > would really appreciate it. > > Note that if you want to test cvsproxy you need to be aware of this > bug in the current package: > http://www.opencsw.org/mantis/view.php?id=1839. > > cfengine-2.2.10,REV=2009.11.11-SunOS5.8-i386-CSW.pkg.gz > cfengine-2.2.10,REV=2009.11.11-SunOS5.8-sparc-CSW.pkg.gz > cfengine_doc-2.2.10,REV=2009.11.11-SunOS5.8-all-CSW.pkg.gz > cvsproxy-1.0.1,REV=2009.11.01-SunOS5.8-i386-CSW.pkg.gz > cvsproxy-1.0.1,REV=2009.11.01-SunOS5.8-sparc-CSW.pkg.gz > diffuse-0.4.1,REV=2009.10.21-SunOS5.8-all-CSW.pkg.gz > oinkmaster-2.0,REV=2009.10.19-SunOS5.8-all-CSW.pkg.gz > perl-5.8.8,REV=2009.11.12-SunOS5.8-i386-CSW.pkg.gz > perl-5.8.8,REV=2009.11.12-SunOS5.8-sparc-CSW.pkg.gz > perldoc-5.8.8,REV=2009.11.12-SunOS5.8-all-CSW.pkg.gz > snort-2.8.5,REV=2009.10.19-SunOS5.8-i386-CSW.pkg.gz > snort-2.8.5,REV=2009.10.19-SunOS5.8-sparc-CSW.pkg.gz > > http://mirror.opencsw.org/testing.html > > -- > /peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers -- _____________________________________________________________________ / Brian C. Hill bchill at bch.net http://brian.bch.net \ | UNIX Specialist BCH Technical Services http://www.bch.net | From phil at bolthole.com Tue Nov 17 21:56:02 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Nov 2009 12:56:02 -0800 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> Message-ID: On Tue, Nov 17, 2009 at 11:45 AM, Maciej (Matchek) Blizinski wrote: > > I like the idea of s/_/-/g when going from catalog names to pkgnames. > Thissentenceismymainargumentforusingdashesitsjusthardtoread. ?I would > really like to have a blessed word separator for the pkgnames. ?Sun > packages uses cases, the have something like SUNWonewordSECONDWORD. ?I > perceive it as ugly. > > > The consistency I'm definitely for is that we achieve consensus, it > gets documented, and we follow it. > well, in some cases, the CSWxxx name doesnt realliyhave to be "readable", that's what our "software name" is for. the PKG name is there almost just as a placeholder. and an argument AGAINST having - in the names: CSWxxx-yyy does not double-click-select in xterm. you ahve to click and drag to select it. in contrast, some_software_name selects as a single word. So, another vote for "no - in PKG names at all", if we are insisting on One True Standard. From dam at opencsw.org Tue Nov 17 22:29:12 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Nov 2009 22:29:12 +0100 Subject: [csw-maintainers] FFI for libshout: Ruby, OCaml, Python, Java Message-ID: <4DBBF4DA-EDB3-46A9-B8FD-B96AD697E556@opencsw.org> Hi folks, I just packaged up libshout with full dependencies and 32/64 bit and the Perl language binding. In addition to that there are a lot of other language bindings which the respective maintainers may want to pick up. This is especially: - Ruby - Objective CAML - Python - Java All bindings are available from http://www.icecast.org/download.php libshout is already installed on the farm :-) Best regards -- Dago From bwalton at opencsw.org Wed Nov 18 01:19:14 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 17 Nov 2009 19:19:14 -0500 Subject: [csw-maintainers] FFI for libshout: Ruby, OCaml, Python, Java In-Reply-To: <4DBBF4DA-EDB3-46A9-B8FD-B96AD697E556@opencsw.org> References: <4DBBF4DA-EDB3-46A9-B8FD-B96AD697E556@opencsw.org> Message-ID: <1258503478-sup-4476@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Nov 17 16:29:12 -0500 2009: > bindings which the respective maintainers may want to pick up. This is > especially: > > - Ruby Is there user demand for this? I'll package it on request, but since I myself don't need it, I won't rush to do it right away. I actually don't like to package things I don't use personally, since I'm not as intimate with them and may not spot obvious packaging/functionality issues. 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 Nov 18 09:56:22 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 08:56:22 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Message-ID: Continuing the postgresql topic, I've written a first sketch of the new file layout proposal. It's now submitted into the repository. I think that GAR hasn't seen this file layout before and is slightly confused about handling 32 and 64-bit binaries. For instance, the 32-bit and 64-bit install directories look like this: > ls work/solaris8-sparc/install-isa-sparcv*/opt/csw/bin/postgresql/8.4/initdb work/solaris8-sparc/install-isa-sparcv8/opt/csw/bin/postgresql/8.4/initdb work/solaris8-sparc/install-isa-sparcv9/opt/csw/bin/postgresql/8.4/initdb Both v8 and v9 binaries are there, but: > ggrep initdb work/solaris8-sparc/build-global/CSWpostgresql.prototype-sparc l none /opt/csw/bin/postgresql/8.4/initdb=/opt/csw/bin/isaexec 0755 root bin f none /opt/csw/bin/postgresql/8.4/sparcv8/initdb=/opt/csw/bin/postgresql/8.4/initdb 0755 root bin f none /opt/csw/bin/sparcv9/initdb 0755 root bin ...the v9 binary not where I'd expect it to be. It sounds like a GAR issue. I can already see Dago swearing at this yet another special case... ;-) Maciej From maciej at opencsw.org Wed Nov 18 10:06:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 09:06:01 +0000 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin Message-ID: Maintainers, There's a user request to create symlinks from /usr/bin to /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. http://www.opencsw.org/mantis/view.php?id=2924 I think there might be a use case for it, but at the same time, why not just set the PATH? I don't mind creating such package, but we're not putting anything into /usr/bin by the rule. What are your thoughts? Create a package with symlinks or not? Maciej From dam at opencsw.org Wed Nov 18 10:16:33 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 10:16:33 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> Message-ID: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Hi Maciej, Am 18.11.2009 um 09:56 schrieb Maciej (Matchek) Blizinski: > Continuing the postgresql topic, I've written a first sketch of the > new file layout proposal. It's now submitted into the repository. I > think that GAR hasn't seen this file layout before and is slightly > confused about handling 32 and 64-bit binaries. For instance, the > 32-bit and 64-bit install directories look like this: > >> ls work/solaris8-sparc/install-isa-sparcv*/opt/csw/bin/postgresql/ >> 8.4/initdb > work/solaris8-sparc/install-isa-sparcv8/opt/csw/bin/postgresql/8.4/ > initdb > work/solaris8-sparc/install-isa-sparcv9/opt/csw/bin/postgresql/8.4/ > initdb > > Both v8 and v9 binaries are there, but: > >> ggrep initdb work/solaris8-sparc/build-global/ >> CSWpostgresql.prototype-sparc > l none /opt/csw/bin/postgresql/8.4/initdb=/opt/csw/bin/isaexec 0755 > root bin > f none /opt/csw/bin/postgresql/8.4/sparcv8/initdb=/opt/csw/bin/ > postgresql/8.4/initdb > 0755 root bin > f none /opt/csw/bin/sparcv9/initdb 0755 root bin > > ...the v9 binary not where I'd expect it to be. It sounds like a GAR > issue. I can already see Dago swearing at this yet another special > case... ;-) I don't think it is a special case. Most likely there is a wrong basedirectory applied in GAR during merge. I'll take a look... Best regards -- Dago From dam at opencsw.org Wed Nov 18 10:23:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 10:23:19 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: <14D4A7F6-9DB1-4C5E-BC1C-2F27E6FE5155@opencsw.org> Hi Maciej, Am 18.11.2009 um 10:06 schrieb Maciej (Matchek) Blizinski: > There's a user request to create symlinks from /usr/bin to > /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. > > http://www.opencsw.org/mantis/view.php?id=2924 > > I think there might be a use case for it, but at the same time, why > not just set the PATH? I don't mind creating such package, but we're > not putting anything into /usr/bin by the rule. What are your > thoughts? Create a package with symlinks or not? Well, I have at least one customer who needs it that way :-) Best regards -- Dago From dam at opencsw.org Wed Nov 18 10:43:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 10:43:18 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: Hi Maciej, Am 18.11.2009 um 10:16 schrieb Dagobert Michelsen: >> Both v8 and v9 binaries are there, but: >> >>> ggrep initdb work/solaris8-sparc/build-global/ >>> CSWpostgresql.prototype-sparc >> l none /opt/csw/bin/postgresql/8.4/initdb=/opt/csw/bin/isaexec 0755 >> root bin >> f none /opt/csw/bin/postgresql/8.4/sparcv8/initdb=/opt/csw/bin/ >> postgresql/8.4/initdb >> 0755 root bin >> f none /opt/csw/bin/sparcv9/initdb 0755 root bin >> >> ...the v9 binary not where I'd expect it to be. It sounds like a GAR >> issue. I can already see Dago swearing at this yet another special >> case... ;-) > > I don't think it is a special case. Most likely there is a wrong > basedirectory applied in GAR during merge. I'll take a look... Umh... I can't reproduce it: > build8s% ggrep initdb work/solaris8-sparc/build-global/ > CSWpostgresql.prototype-sparc > l none /opt/csw/postgresql/bin/initdb=/opt/csw/bin/isaexec 0755 root > bin > f none /opt/csw/postgresql/bin/sparcv8/initdb=/opt/csw/postgresql/ > bin/initdb 0755 root bin > f none /opt/csw/postgresql/bin/sparcv9/initdb 0755 root bin > f none /opt/csw/postgresql/share/man/man1/initdb.1 0644 root bin Would you mind doing a "gmake repackage" and see if the error persists? I haven't changed anything. Best regards -- Dago From maciej at opencsw.org Wed Nov 18 10:49:16 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 09:49:16 +0000 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: <14D4A7F6-9DB1-4C5E-BC1C-2F27E6FE5155@opencsw.org> References: <14D4A7F6-9DB1-4C5E-BC1C-2F27E6FE5155@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 9:23 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 18.11.2009 um 10:06 schrieb Maciej (Matchek) Blizinski: >> >> There's a user request to create symlinks from /usr/bin to >> /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. >> >> http://www.opencsw.org/mantis/view.php?id=2924 >> >> I think there might be a use case for it, but at the same time, why >> not just set the PATH? ?I don't mind creating such package, but we're >> not putting anything into /usr/bin by the rule. ?What are your >> thoughts? ?Create a package with symlinks or not? > > Well, I have at least one customer who needs it that way :-) All right, I'm rolling a it now then! Will be in testing later day. Maciej From dam at opencsw.org Wed Nov 18 10:51:07 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 10:51:07 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> Hi Maciej, Am 18.11.2009 um 10:43 schrieb Dagobert Michelsen: > Am 18.11.2009 um 10:16 schrieb Dagobert Michelsen: >>> Both v8 and v9 binaries are there, but: >>> >>>> ggrep initdb work/solaris8-sparc/build-global/ >>>> CSWpostgresql.prototype-sparc >>> l none /opt/csw/bin/postgresql/8.4/initdb=/opt/csw/bin/isaexec >>> 0755 root bin >>> f none /opt/csw/bin/postgresql/8.4/sparcv8/initdb=/opt/csw/bin/ >>> postgresql/8.4/initdb >>> 0755 root bin >>> f none /opt/csw/bin/sparcv9/initdb 0755 root bin >>> >>> ...the v9 binary not where I'd expect it to be. It sounds like a >>> GAR >>> issue. I can already see Dago swearing at this yet another special >>> case... ;-) BTW: Make sure to read files/README-CSW.txt. It is stated in there that the databases for 32 and 64 bit are not compatible, so I am pretty sure you don't want isaexec anywhere in the package, but want to select 32/64 explicitly as also stated in the README. Best regards, and thanks for doing postgres! -- Dago From maciej at opencsw.org Wed Nov 18 10:55:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 09:55:58 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 9:43 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 18.11.2009 um 10:16 schrieb Dagobert Michelsen: >>> >>> Both v8 and v9 binaries are there, but: >>> >>>> ggrep initdb >>>> work/solaris8-sparc/build-global/CSWpostgresql.prototype-sparc >>> >>> l none /opt/csw/bin/postgresql/8.4/initdb=/opt/csw/bin/isaexec 0755 root >>> bin >>> f none >>> /opt/csw/bin/postgresql/8.4/sparcv8/initdb=/opt/csw/bin/postgresql/8.4/initdb >>> 0755 root bin >>> f none /opt/csw/bin/sparcv9/initdb 0755 root bin >>> >>> ...the v9 binary not where I'd expect it to be. ?It sounds like a GAR >>> issue. ?I can already see Dago swearing at this yet another special >>> case... ;-) >> >> I don't think it is a special case. Most likely there is a wrong >> basedirectory applied in GAR during merge. I'll take a look... > > Umh... I can't reproduce it: > >> build8s% ggrep initdb >> work/solaris8-sparc/build-global/CSWpostgresql.prototype-sparc >> l none /opt/csw/postgresql/bin/initdb=/opt/csw/bin/isaexec 0755 root bin >> f none >> /opt/csw/postgresql/bin/sparcv8/initdb=/opt/csw/postgresql/bin/initdb 0755 >> root bin >> f none /opt/csw/postgresql/bin/sparcv9/initdb 0755 root bin >> f none /opt/csw/postgresql/share/man/man1/initdb.1 0644 root bin > > Would you mind doing a "gmake repackage" and see if the error persists? > I haven't changed anything. It persists. Your example looks different from mine: You have /opt/csw/postgresql/bin/initdb, I have /opt/csw/bin/postgresql/8.4/initdb. Maciej From dam at opencsw.org Wed Nov 18 11:04:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 11:04:22 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: Hi Maciej, Am 18.11.2009 um 10:55 schrieb Maciej (Matchek) Blizinski: > It persists. Your example looks different from mine: You have > /opt/csw/postgresql/bin/initdb, I have > /opt/csw/bin/postgresql/8.4/initdb. I build freshly. Did you change configure options or directories without making "gmake clean"? This completely confuses GAR. Please retry the complete build and I am pretty sure that the error will then be gone as this is what I did ;-) Best regards -- Dago From maciej at opencsw.org Wed Nov 18 11:17:27 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 10:17:27 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 9:51 AM, Dagobert Michelsen wrote: > BTW: Make sure to read files/README-CSW.txt. It is stated in there > that the databases for 32 and 64 bit are not compatible, so I am pretty > sure you don't want isaexec anywhere in the package, but want to > select 32/64 explicitly as also stated in the README. I understand the incompatibility. I don't understand why would it matter. Machine's architecture doesn't change after installation. If it's 64-bit, it's always been and always will be, until the machine is retired. There might be a problem when someone has been running 32-bit binaries on a 64-bit machine and now switches to the 64-bit enabled PostgreSQL. In such a they should downgrade their package back to the 32-bit and do the dump/restore dance. However, if they upgrade from 8.3 to 8.4 (which is the case here), they will have to do this anyway. I also think that the PGCTL explicit setting is a non-solution. It makes people run 32-bit binaries on 64-bit machines by default, which wastes the migration effort: they could've migrated from 32-bit 8.3 to 64-bit 8.4, but they only migrated from 32-bit 8.3 to 32-bit 8.4. I assert that using isaexec in 8.4 is no worse than using explicit architecture setting in 8.4. Thoughts? Maciej From maciej at opencsw.org Wed Nov 18 12:04:52 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 11:04:52 +0000 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> Message-ID: On Tue, Nov 17, 2009 at 8:56 PM, Philip Brown wrote: > On Tue, Nov 17, 2009 at 11:45 AM, Maciej (Matchek) Blizinski > wrote: >> >> I like the idea of s/_/-/g when going from catalog names to pkgnames. >> Thissentenceismymainargumentforusingdashesitsjusthardtoread. ?I would >> really like to have a blessed word separator for the pkgnames. ?Sun >> packages uses cases, the have something like SUNWonewordSECONDWORD. ?I >> perceive it as ugly. >> >> >> The consistency I'm definitely for is that we achieve consensus, it >> gets documented, and we follow it. >> > > well, in some cases, the CSWxxx name doesnt realliyhave to be > "readable", that's what our "software name" is for. ?the PKG name is > there almost just as a placeholder. > > and an argument AGAINST having - in the names: > > CSWxxx-yyy ?does not double-click-select in xterm. you ahve to click > and drag to select it. > in contrast, some_software_name selects as a single word. Looks like your terminal emulator is broken. Pick a non-broken one or fix yours! ;-) > So, another vote for "no - in PKG names at all", if we are insisting > on One True Standard. Should we write up the pros and cons so we can have a nice overview picture of the pros and cons? I'd also like to point out that what I would like to have is not the dash character explicitly, what I'd like to have is a word separator. It can be dashes, underscores, CamelCase, or anything else, I don't care what specifically. I would just like to be able to have visually separate words in the pkgnames. Maciej From maciej at opencsw.org Wed Nov 18 12:07:41 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 11:07:41 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 10:04 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 18.11.2009 um 10:55 schrieb Maciej (Matchek) Blizinski: >> >> It persists. ?Your example looks different from mine: You have >> /opt/csw/postgresql/bin/initdb, I have >> /opt/csw/bin/postgresql/8.4/initdb. > > I build freshly. Did you change configure options or directories > without making "gmake clean"? This completely confuses GAR. > Please retry the complete build and I am pretty sure that the > error will then be gone as this is what I did ;-) I did a clean build. Which revision are you building? Mine is: maciej at build8s [build8s]:~/src/opencsw/pkg/postgresql/trunk > svn info Makefile Path: Makefile Name: Makefile URL: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/postgresql/trunk/Makefile Repository Root: https://gar.svn.sourceforge.net/svnroot/gar Repository UUID: d3b55034-1cff-0310-a425-aefe953e1e90 Revision: 7334 Node Kind: file Schedule: normal Last Changed Author: wahwah Last Changed Rev: 7334 Last Changed Date: 2009-11-17 23:16:07 +0100 (Tue, 17 Nov 2009) Text Last Updated: 2009-11-17 23:15:04 +0100 (Tue, 17 Nov 2009) Checksum: edc1ba9fb66f6c7e3ecce9497ef71d08 Maciej From james at opencsw.org Wed Nov 18 12:20:21 2009 From: james at opencsw.org (James Lee) Date: Wed, 18 Nov 2009 11:20:21 GMT Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: <20091118.11202100.2985158056@gyor.oxdrove.co.uk> On 18/11/09, 09:06:01, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin: > There's a user request to create symlinks from /usr/bin to > /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. I think it's not good. It will fail in a zone with global /usr. Same question applies to /usr/lib/sendmail. Too many bad programs hard code sendmail in - that's tautology hard coding sendmail defines a program as bad! James. From james at opencsw.org Wed Nov 18 12:21:25 2009 From: james at opencsw.org (James Lee) Date: Wed, 18 Nov 2009 11:21:25 GMT Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> Message-ID: <20091118.11212500.3339303609@gyor.oxdrove.co.uk> On 18/11/09, 10:17:27, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] Building postgresql-8.4.1: > It makes > people run 32-bit binaries on 64-bit machines by default, which wastes > the migration effort: they could've migrated from 32-bit 8.3 to 64-bit > 8.4, but they only migrated from 32-bit 8.3 to 32-bit 8.4. I understand it's a waste running 64 bit when it's not needed, only those that really need it do so, hence the default is 32 and the choice is there. James. From james at opencsw.org Wed Nov 18 13:09:59 2009 From: james at opencsw.org (James Lee) Date: Wed, 18 Nov 2009 12:09:59 GMT Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <4ABBE6C4.3040600@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> Message-ID: <20091118.12095900.1758710002@gyor.oxdrove.co.uk> On 17/11/09, 20:56:02, Philip Brown wrote regarding Re: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)?: > well, in some cases, the CSWxxx name doesnt realliyhave to be > "readable", that's what our "software name" is for. the PKG name is > there almost just as a placeholder. It doesn't have to match but it makes life so much easier. Any reason not to make it meaningful? Good: pkg-get -i foobar -> installs CSWfoobar Bad: pkg-get -i foobar -> installs CSWfb Daft: pkg-get -i foobar -> installs CSWx9 The system uses package name. After install the software name is not needed and since pkg-get was revised we can even install with package name. James. From james at opencsw.org Wed Nov 18 13:14:31 2009 From: james at opencsw.org (James Lee) Date: Wed, 18 Nov 2009 12:14:31 GMT Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <1253832055-sup-9675@ntdws12.chass.utoronto.ca> <4ABD1B60.5060700@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> Message-ID: <20091118.12143100.3993068214@gyor.oxdrove.co.uk> On 18/11/09, 11:04:52, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)?: > > and an argument AGAINST having - in the names: > > > > CSWxxx-yyy ??does not double-click-select in xterm. you ahve to click > > and drag to select it. > > in contrast, some_software_name selects as a single word. > Looks like your terminal emulator is broken. Pick a non-broken one or > fix yours! ;-) It's not broken, it's quite normal. e.g. perl regexp \w includes alphanumeric and '_' but not '-'. My comment about pasting is: cut the software name, type "CSW", paste. I wish it to result in package name. I'd also like a machine capable transform. I'm happy doing: pacakgeHome.findBySoftwareName("foobar").getPackageName(); just to get "CSWfoobar" when hitting the problem with a J2EE sledgehammer but in simple scripts it would be useful to... #!/bin/ksh softwareName="foobar" echo "software name: ${softwareName}" packageName="CSW${softwareName}" echo "package name from software name: ${packageName}" echo "software name from package name: ${packageName#CSW}" ...this passed by long ago. 's/_/-/g' and the reverse can used in scripts but then the quick script becomes more complicated than using my J2EE. James. From maciej at opencsw.org Wed Nov 18 13:46:07 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 12:46:07 +0000 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <20091118.12143100.3993068214@gyor.oxdrove.co.uk> References: <4A91CB5A.4080109@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> <20091118.12143100.3993068214@gyor.oxdrove.co.uk> Message-ID: On Wed, Nov 18, 2009 at 12:14 PM, James Lee wrote: > On 18/11/09, 11:04:52, Maciej "(Matchek)" Blizinski > wrote regarding Re: [csw-maintainers] Change python modules catalog names > to have a py_ prefix (instead of just py)?: > >> > and an argument AGAINST having - in the names: >> > >> > CSWxxx-yyy ??does not double-click-select in xterm. you ahve to click >> > and drag to select it. >> > in contrast, some_software_name selects as a single word. > >> Looks like your terminal emulator is broken. ?Pick a non-broken one or >> fix yours! ;-) > > It's not broken, it's quite normal. ?e.g. perl regexp \w includes > alphanumeric and '_' but not '-'. I was mocking the misuse of the absolute term 'broken' when all it means it a subjective "your software doesn't work the way I think it should". > My comment about pasting is: cut the software name, type "CSW", paste. > I wish it to result in package name. > > > I'd also like a machine capable transform. ?I'm happy doing: > ? ? ? ?pacakgeHome.findBySoftwareName("foobar").getPackageName(); > just to get "CSWfoobar" when hitting the problem with a J2EE sledgehammer > but in simple scripts it would be useful to... > > #!/bin/ksh > > softwareName="foobar" > echo "software name: ${softwareName}" > packageName="CSW${softwareName}" > echo "package name from software name: ${packageName}" > echo "software name from package name: ${packageName#CSW}" > > ...this passed by long ago. > > 's/_/-/g' and the reverse can used in scripts but then the quick script > becomes more complicated than using my J2EE. Any other ideas for a word separator? From dam at opencsw.org Wed Nov 18 14:10:58 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 14:10:58 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <77FE2AD3-748C-4AB8-A915-5069ED333EE3@opencsw.org> <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> Message-ID: <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> Hi Maciej, Am 18.11.2009 um 11:17 schrieb Maciej (Matchek) Blizinski: > On Wed, Nov 18, 2009 at 9:51 AM, Dagobert Michelsen > wrote: >> BTW: Make sure to read files/README-CSW.txt. It is stated in there >> that the databases for 32 and 64 bit are not compatible, so I am >> pretty >> sure you don't want isaexec anywhere in the package, but want to >> select 32/64 explicitly as also stated in the README. > > I understand the incompatibility. I don't understand why would it > matter. Machine's architecture doesn't change after installation. If > it's 64-bit, it's always been and always will be, until the machine is > retired. > > There might be a problem when someone has been running 32-bit binaries > on a 64-bit machine and now switches to the 64-bit enabled PostgreSQL. > In such a they should downgrade their package back to the 32-bit and > do the dump/restore dance. However, if they upgrade from 8.3 to 8.4 > (which is the case here), they will have to do this anyway. I also > think that the PGCTL explicit setting is a non-solution. It makes > people run 32-bit binaries on 64-bit machines by default, which wastes > the migration effort: they could've migrated from 32-bit 8.3 to 64-bit > 8.4, but they only migrated from 32-bit 8.3 to 32-bit 8.4. I assert > that using isaexec in 8.4 is no worse than using explicit architecture > setting in 8.4. > > Thoughts? You assume that using 64 bit is always better than using 32 bit. This is not the case. If you need more than 2 GB of RAM or have large databases you are right. But if the database is not that big you are better off using 32 bit. IMHO it is good to automatically make the 32/64 bit decision under the following circumstances: (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 see that any of the above applies in the case of postgres. Best regards -- Dago From bonivart at opencsw.org Wed Nov 18 14:29:06 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 18 Nov 2009 14:29:06 +0100 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: References: <4A91CB5A.4080109@opencsw.org> <535FC71F-7135-4CCD-A2DE-355F024BA4D0@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> <20091118.12143100.3993068214@gyor.oxdrove.co.uk> Message-ID: <625385e30911180529p1f0debfaj837d03934072ead6@mail.gmail.com> On Wed, Nov 18, 2009 at 1:46 PM, Maciej (Matchek) Blizinski wrote: > Any other ideas for a word separator? Why do we need a word separator? The names are short and readability isn't enhanced that much by a separator. CSWperldoc -> CSWperl-doc perldoc -> perl_doc My vote goes to using neither dashes nor underscores for new packages. -- /peter From dam at opencsw.org Wed Nov 18 14:34:00 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 14:34:00 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: <20091118.11202100.2985158056@gyor.oxdrove.co.uk> References: <20091118.11202100.2985158056@gyor.oxdrove.co.uk> Message-ID: <728DE690-8397-4803-9B81-F029B5167CF6@opencsw.org> Hi, Am 18.11.2009 um 12:20 schrieb James Lee: > On 18/11/09, 09:06:01, Maciej "(Matchek)" Blizinski > > wrote regarding [csw-maintainers] User requests symlinking from /usr/ > bin > to > /opt/csw/bin: > >> There's a user request to create symlinks from /usr/bin to >> /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. > > I think it's not good. > > It will fail in a zone with global /usr. It is a purely optional package that depends on cups and its whole purpose is to replace the SysV-lp system. Nothing more. If you don't want the system replaced you don't install this package. We may choose a slightly modifed prefix like CSWScups (CSW Solaris cups) or something to mark that it doesn't install in /opt/csw but replaced Solaris core functionality. Best regards -- Dago From bonivart at opencsw.org Wed Nov 18 16:00:35 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 18 Nov 2009 16:00:35 +0100 Subject: [csw-maintainers] /testing cfengine, cvsproxy, diffuse, oinkmaster, perl, snort In-Reply-To: <20091117205453.GA9219@vm-1.bch.net> References: <625385e30911170911o7e76ae6bme982ec90ccd7fdc8@mail.gmail.com> <20091117205453.GA9219@vm-1.bch.net> Message-ID: <625385e30911180700l21c7472y67b655c7ff195249@mail.gmail.com> On Tue, Nov 17, 2009 at 9:54 PM, Brian Hill wrote: > ? ? ? ?I grabbed cfengine-2.2.10 and perl-5.8.8, both of which I use > heavily, and they seem to be working well, except that CFE complained > about about these two DB files being in an unrecognized format (because > you have to get the newer bdb as well): > > ? ? ? ?cf_LastSeen.db > ? ? ? ?performance.db > > ? ? ? ?Since I don't make use of these, simply deleting them wasn't a > problem for me. Thanks a lot for that report, I've been running that perl package for a while myself but I can't test cfengine right now. -- /peter From phil at bolthole.com Wed Nov 18 18:09:23 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Nov 2009 09:09:23 -0800 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: On Wed, Nov 18, 2009 at 1:06 AM, Maciej (Matchek) Blizinski wrote: > Maintainers, > > There's a user request to create symlinks from /usr/bin to > /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. > > http://www.opencsw.org/mantis/view.php?id=2924 > > I think there might be a use case for it, but at the same time, why > not just set the PATH? ?I don't mind creating such package, but we're > not putting anything into /usr/bin by the rule. ?What are your > thoughts? ?Create a package with symlinks or not? > Hmm... there then becomes a question of, what to put in the package? for example, we have a gnu links package, that links ALL (or at least most) of the g-prefixed GNU utilities in /opt/csw/bin, to /opt/csw/gnu. That is a cross-package set of links. Should we do the same for this sort of request? If so, which packages/programs should we include symlinks for? or should we make a whole bunch of separate CSWxxx"links" packages? OR... should we make a metapackage, with some sort of config file, and let the user decide? eg: CSWusrlinks, which will reference one or both of /opt/csw/etc/cswusrlinks.conf /etc/opt/csw/cswusrlinks.conf and then if CSWxyz is mentioned there, it will make symlinks into /usr for that package. (in a postinstall script) ORRRRR... do we create another cswclassutils class, where either individual files can be set as in the "usrlinks" class, or it provides a config file, "if the user wants symlinks into usr for my package, make symlinks for the following files automatically..." I think this last one is perhaps the best long term option. for one reason, because it uses class action scripts instead of postinstall scripts, so it is the most future-proof. From phil at bolthole.com Wed Nov 18 18:11:28 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Nov 2009 09:11:28 -0800 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 5:10 AM, Dagobert Michelsen wrote: >.... > You assume that using 64 bit is always better than using 32 bit. This > is not the case. If you need more than 2 GB of RAM or have large > databases you are right. But if the database is not that big you are > better off using 32 bit.[....] > I don't see that any of the above applies in the case of postgres. > yup. it is exactly for these reasons, that our (old, yes) mysql package, provides BOTH 32bit and 64bit database binaries, and lets the user decide which one they wish to run. NO use of isaexec. From phil at bolthole.com Wed Nov 18 18:19:32 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Nov 2009 09:19:32 -0800 Subject: [csw-maintainers] Change python modules catalog names to have a py_ prefix (instead of just py)? In-Reply-To: <625385e30911180529p1f0debfaj837d03934072ead6@mail.gmail.com> References: <4A91CB5A.4080109@opencsw.org> <20091116.9573700.2235360213@gyor.oxdrove.co.uk> <03090F43-B964-436B-8AE2-E58CC0D8E9B0@opencsw.org> <20091117.19144300.1872225613@gyor.oxdrove.co.uk> <20091118.12143100.3993068214@gyor.oxdrove.co.uk> <625385e30911180529p1f0debfaj837d03934072ead6@mail.gmail.com> Message-ID: On Wed, Nov 18, 2009 at 5:29 AM, Peter Bonivart wrote: > > > Why do we need a word separator? The names are short and readability > isn't enhanced that much by a separator. > > CSWperldoc -> CSWperl-doc > perldoc -> perl_doc > > My vote goes to using neither dashes nor underscores for new packages. > well, that certainly would make for consistency From dam at opencsw.org Wed Nov 18 18:21:00 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Nov 2009 18:21:00 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: Hi Phil, Am 18.11.2009 um 18:09 schrieb Philip Brown: > Hmm... there then becomes a question of, what to put in the package? > > for example, we have a gnu links package, that links ALL (or at least > most) of the g-prefixed GNU utilities in /opt/csw/bin, to > /opt/csw/gnu. > > That is a cross-package set of links. > Should we do the same for this sort of request? > If so, which packages/programs should we include symlinks for? > > or should we make a whole bunch of separate CSWxxx"links" packages? > > > OR... should we make a metapackage, with some sort of config file, and > let the user decide? > > eg: CSWusrlinks, which will reference one or both of > > /opt/csw/etc/cswusrlinks.conf > /etc/opt/csw/cswusrlinks.conf > > and then if CSWxyz is mentioned there, it will make symlinks into /usr > for that package. > (in a postinstall script) > > ORRRRR... do we create another cswclassutils class, where either > individual files can be set as in the "usrlinks" class, or it provides > a config file, "if the user wants symlinks into usr for my package, > make symlinks for the following files automatically..." > > I think this last one is perhaps the best long term option. for one > reason, because it uses class action scripts instead of postinstall > scripts, so it is the most future-proof. I prefer the way Maciej has done it: with a separete package per software (Cups in this case), marked incompatible to the Solaris packages it replaces. You can't have that with classutils. And it is cleanly separated from the CSW-only packages. If the "-ln" suffix is consistent may be discussed, in the current naming scheme "CSWcupslinks" would IMHO be better, but that is another thing. Best regards -- Dago From maciej at opencsw.org Wed Nov 18 18:57:45 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 18 Nov 2009 17:57:45 +0000 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: On Wed, Nov 18, 2009 at 5:21 PM, Dagobert Michelsen wrote: > is cleanly separated from the CSW-only packages. If the "-ln" > suffix is consistent may be discussed, in the current naming > scheme "CSWcupslinks" would IMHO be better, but that is another > thing. I couldn't decide which was better. I had the following ideas: CSWcupsln CSWcupslinks CSWcupslpdcompat CSWcupsusrbin CSWcups-ln CSWcups-links CSWcups-lpdcompat CSWcups-usrbin CSWcupsclientln CSWcupsclientlinks CSWcupsclientlpdcompat CSWcupsclientusrbin CSWcupsclient-ln CSWcupsclient-links CSWcupsclient-lpdcompat CSWcupsclient-usrbin Which one do you like best? Maciej From phil at bolthole.com Wed Nov 18 19:11:52 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Nov 2009 10:11:52 -0800 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: On Wed, Nov 18, 2009 at 9:21 AM, Dagobert Michelsen wrote: > > I prefer the way Maciej has done it: with a separete package per > software (Cups in this case), marked incompatible to the Solaris > packages it replaces. eu, ick. I didnt notice that "feature". I dont think we have any business conflicting with packages that arent "ours". From phil at bolthole.com Wed Nov 18 19:16:40 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Nov 2009 10:16:40 -0800 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: On Wed, Nov 18, 2009 at 10:11 AM, Philip Brown wrote: > >... > I dont think we have any business conflicting with packages that arent "ours". > Let me give just one explicit example of why: "pkg-get install all" From skayser at opencsw.org Wed Nov 18 23:02:55 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 18 Nov 2009 23:02:55 +0100 Subject: [csw-maintainers] New cswclassutils: cswcron, cswtexinfo, cswmigrateconf and GAR integration In-Reply-To: <0691F15A-1BF5-4817-968F-449FC848E2D7@opencsw.org> References: <0691F15A-1BF5-4817-968F-449FC848E2D7@opencsw.org> Message-ID: <4B046F0F.6060509@opencsw.org> Hi Dago, Dagobert Michelsen wrote on 11.11.2009 15:58: > as of r7226 and cswclassutils 1.28 there is support for three new > classes: > > - cswcron allows modifying of the crontab > - cswtexinfo allows automatic addition of .info files to the texinfo dir > - cswmigrateconf allows easy migration of config files from /opt/csw/etc > to /etc/opt/csw > > The usage has been documented at > i have been trying to leverage MIGRATE_FILES for axel, the cswmigrateconf stays empty though. ... sysconfdir = /etc/opt/csw SAMPLECONF = $(sysconfdir)/axelrc MIGRATE_FILES = axelrc ... skayser @ build8x ~/mgar/pkg/axel/trunk$ cat work/solaris8-i386/pkgroot/etc/opt/csw/pkg/CSWaxel/cswmigrateconf MIGRATE_FILES="" Build files are checked in, would you mind having a look? Sebastian From glaw at opencsw.org Thu Nov 19 00:26:09 2009 From: glaw at opencsw.org (Gary Law) Date: Wed, 18 Nov 2009 23:26:09 +0000 Subject: [csw-maintainers] [csw-buildfarm] gmake: warning: Clock skew detected. Your build may be incomplete. In-Reply-To: <4B047CB6.5050007@opencsw.org> References: <4B047CB6.5050007@opencsw.org> Message-ID: and the time on build9x is out by 1 hour (or the timezone is wrong, depending on your point of view) 2009/11/18 Sebastian Kayser : > I am working on build8x and build8s mostly and lately there seems to > be a time keeping issue. At least i am seeing lots of messages > like the following > > ... > gmake: Warning: File `work/solaris8-i386/cookies/global' has modification time 3.3 s in the future > ... > gmake: warning: ?Clock skew detected. ?Your build may be incomplete. > ... > > Looking at the systems, it seems as if the build.s are in sync, whereas > the build.x boxes have different notions of "the current time". Could > someone please have a look at it? > > Sebastian > _______________________________________________ > buildfarm mailing list > buildfarm at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/buildfarm > -- Gary Law Email: garylaw at garylaw.net Chat googletalk/messenger: gary.law at gmail.com iChat/jabber/AIM: gary.law at mac.com From schwindt at dfki.uni-kl.de Thu Nov 19 08:23:42 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Thu, 19 Nov 2009 08:23:42 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: Your message of "Wed, 18 Nov 2009 14:34:00 +0100." <728DE690-8397-4803-9B81-F029B5167CF6@opencsw.org> Message-ID: <200911190723.nAJ7NgYL012355@dfki.uni-kl.de> [...] > >> There's a user request to create symlinks from /usr/bin to > >> /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. > > > > I think it's not good. > > > > It will fail in a zone with global /usr. > > It is a purely optional package that depends on cups and its whole > purpose > is to replace the SysV-lp system. Nothing more. If you don't want the > system replaced you don't install this package. We may choose a slightly > modifed prefix like > CSWScups (CSW Solaris cups) > or something to mark that it doesn't install in /opt/csw but replaced > Solaris core functionality. Which I can do by adjusting the order of my PATH elements. Nothing belongs in /usr besides what SUN puts there. The zones are are an example where this fails, and also the fact that I've seen several customer mount /usr read only. Besides that, it is law - at least to me - that's why there is /opt. This is not linux ! Also I do not see cupsclient as purely optional. CSWcupslibs gets pulled in on behave of several packages. To be able to verify you setup one will need CSWcupsclient. The actual printing can be done with the onboard toolchain. Apart from that - what happens to /usr/bin/lpr, is it deleted ? Is SUNWpcu deinstalled ? Before making such modification one should think about making his on distribution rather than build packages for an existing one. Nicolai From maciej at opencsw.org Thu Nov 19 10:02:26 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 19 Nov 2009 09:02:26 +0000 Subject: [csw-maintainers] nspr in testing/ Message-ID: I've seen that William has done some work on the nspr library (netscape portable runtime). I know that Firefox needs it, so I'm not sure how is William currently compiling Firefox. I thought it would be good to have nspr as a separate library, in case someone wants to build a package with nspr as a dependency, such as Evolution, xulrunner, NSS (Mozilla's Network Security Services library), etc. I did some changes to the Makefile which was in the repository. I took out the --with-dist-prefix and --with-dist-bindir options. I assumed that William worked with only Firefox in mind, I want to have a regular system library. The library has been built with 32 and 64-bit support. It's currently in testing/. Maciej From maciej at opencsw.org Thu Nov 19 10:26:15 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 19 Nov 2009 09:26:15 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 1:10 PM, Dagobert Michelsen wrote: > You assume that using 64 bit is always better than using 32 bit. That's too strong a statement. Let's put it this way: I assume it's not significantly worse. But let's stop guessing and look at data. Do we have any numbers on it? What's the difference in memory footprint between 32 and 64-bit versions? > This > is not the case. If you need more than 2 GB of RAM or have large > databases you are right. Basically, if somebody's database is growing, we're making sure that it's already grown big when they realize they need to switch to the 64-bit version. > But if the database is not that big you are > better off using 32 bit. IMHO it is good to automatically make the > 32/64 bit decision under the following circumstances: > > (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 see that any of the above applies in the case of postgres. So why are we building everything else with isaexec? For instance, why do we want cups to be 64-bit enabled? Maciej From maciej at opencsw.org Thu Nov 19 10:30:31 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 19 Nov 2009 09:30:31 +0000 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: On Wed, Nov 18, 2009 at 11:07 AM, Maciej (Matchek) Blizinski wrote: > On Wed, Nov 18, 2009 at 10:04 AM, Dagobert Michelsen wrote: >> Hi Maciej, >> >> Am 18.11.2009 um 10:55 schrieb Maciej (Matchek) Blizinski: >>> >>> It persists. ?Your example looks different from mine: You have >>> /opt/csw/postgresql/bin/initdb, I have >>> /opt/csw/bin/postgresql/8.4/initdb. The same thing happens with pkg/mysql5/branches/mysql-5.1.x-optcsw. It looks like GAR puts sparcv9 subdirectory always directly under bin/, ignoring any subdirectories under bin/. Maciej From bchill at opencsw.org Thu Nov 19 16:42:24 2009 From: bchill at opencsw.org (Brian Hill) Date: Thu, 19 Nov 2009 15:42:24 +0000 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin Message-ID: <20091119154224.GA28243@vm-1.bch.net> Nicolai Schwindt wrote: > [...] > >>>> There's a user request to create symlinks from /usr/bin to >>>> /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. >>>> >>> I think it's not good. >>> >>> It will fail in a zone with global /usr. >>> >> It is a purely optional package that depends on cups and its whole purpose >> is to replace the SysV-lp system. Nothing more. If you don't want the >> system replaced you don't install this package. We may choose a slightly >> modifed prefix like >> CSWScups (CSW Solaris cups) >> or something to mark that it doesn't install in /opt/csw but replaced >> Solaris core functionality. >> > > Which I can do by adjusting the order of my PATH elements. > Nothing belongs in /usr besides what SUN puts there. > The zones are are an example where this fails, and also the fact that I've seen several customer > mount /usr read only. > > Besides that, it is law - at least to me - that's why there is /opt. > This is not linux ! > Also I do not see cupsclient as purely optional. CSWcupslibs gets pulled in on behave of several > packages. To be able to verify you setup one will need CSWcupsclient. The actual printing can > be done with the onboard toolchain. > > Apart from that - what happens to /usr/bin/lpr, is it deleted ? Is SUNWpcu deinstalled ? > > Before making such modification one should think about making his on distribution rather than > build packages for an existing one. > > > Nicolai Hi Nicolai, Solaris does not exist in its a vacuum. :-) As a system manager, I want to deploy as few OS-specific solutions as possible; that is, I don't want to defer to FHS (File Hierarchy Standard) on Linux systems, which most 3rd-party Linux rpms follow to install files, but then have to modify /etc/default/login and other files on Sun systems, and /opt/local or /sw on Macs in some other file, if that's even possible on Macs (still looking into how Darwin handles a global PATH). Remote execution (ssh, rsh) and cron are additional examples of how trying to add to a PATH globally becomes difficult. And that Solaris 10 has the issue of zones affecting /usr isn't persuasive enough. To address this, I have made /usr/local on my systems strictly a symbolic link tree, with symbolic links pointing all over the place, which has helped a lot, but it's really not a substitute /usr/bin. The sysadmin is the user in the 'user experience' that CSW works for. We could argue forever about the direction that the PATH vs. /usr/bin debate is headed in the broader UNIX world, but CSW could offer at least one other avenue, especially if someone is CSW land is willing to offer that flexibility to deal with this. No solution will tip-toe with complete success around an installed OS. CSW already does it in /etc/rc* and /etc/init.d (I have to move CSW's init files out of the way after installing CSW's tools because I use my own init file method). Creating /usr/bin symbolic links in optional pkgs is as reasonable as modifying /etc/default/login, /detc/default/su and/or /etc/profile & /etc/csh.login. That a filesystem 'namespace' clash can happen somewhere in user land is a guarantee, but not all sysadmin's should be held hostage in the effort to avoid that clash. My 2 cents. Brian From korpela at opencsw.org Thu Nov 19 17:57:09 2009 From: korpela at opencsw.org (Eric J Korpela) Date: Thu, 19 Nov 2009 08:57:09 -0800 Subject: [csw-maintainers] Fwd: wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: References: <83CED7D4-8FCB-4D9D-965F-4D8975BEEF6D@opencsw.org> Message-ID: ---------- Forwarded message ---------- From: Eric J Korpela Date: Thu, Nov 19, 2009 at 8:56 AM Subject: Re: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) To: List for OpenCSW maintainers 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. Eric On Tue, Nov 17, 2009 at 8:45 AM, Dagobert Michelsen wrote: > Hi Erik, > > Am 16.11.2009 um 22:19 schrieb Eric J Korpela: >> >> I'll try to build boincmanager against the new libraries some time this >> week > > Cool. Let me know if you need additional machines or installs on build*t as > the > updated wxwidgets library will only be installed on build*s/x after release > and > there is still an unresolved issue. > > > Best regards > > ?-- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > From phil at bolthole.com Thu Nov 19 18:31:38 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 19 Nov 2009 09:31:38 -0800 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> Message-ID: On Thu, Nov 19, 2009 at 1:26 AM, Maciej (Matchek) Blizinski wrote: > > > So why are we building everything else with isaexec? we dont build "everything else" with isaexec. there is no 64bit "grep" for example. > ?For instance, > why do we want cups to be 64-bit enabled? there is a difference between "enabled[/available]", and "default to using it". hopefully, we havent bothered making 64bit executables for cups. but we need 64bit versions of the libraries AVAILABLE, so that some applications that want cups support, can be compiled in 64bit mode, if beneficial. obvious candidate: GIMP. From phil at bolthole.com Thu Nov 19 18:34:07 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 19 Nov 2009 09:34:07 -0800 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: <20091119154224.GA28243@vm-1.bch.net> References: <20091119154224.GA28243@vm-1.bch.net> Message-ID: On Thu, Nov 19, 2009 at 7:42 AM, Brian Hill wrote: > > Creating /usr/bin symbolic links in optional pkgs is as reasonable as > modifying /etc/default/login, /detc/default/su and/or /etc/profile & > /etc/csh.login. i would have to disagree there. those files, are /etc files. they are meant to be modified. From phil at bolthole.com Thu Nov 19 21:43:33 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 19 Nov 2009 12:43:33 -0800 Subject: [csw-maintainers] f-spot, anyone? Message-ID: Sooo.. anyone feel like packaging "f-spot"? It's a light(er)-weight photo cropping/tweaking tool. http://f-spot.org/Features From bwalton at opencsw.org Thu Nov 19 21:57:15 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 19 Nov 2009 15:57:15 -0500 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: References: Message-ID: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Nov 19 15:43:33 -0500 2009: > It's a light(er)-weight photo cropping/tweaking tool. ...that requires the mono runtime. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Thu Nov 19 22:05:47 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 19 Nov 2009 13:05:47 -0800 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Nov 19, 2009 at 12:57 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Nov 19 15:43:33 -0500 2009: >> It's a light(er)-weight photo cropping/tweaking tool. > > ...that requires the mono runtime. > so much for light.. Euuuuu.... From phil at bolthole.com Thu Nov 19 22:16:35 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 19 Nov 2009 13:16:35 -0800 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Nov 19, 2009 at 1:05 PM, Philip Brown wrote: > On Thu, Nov 19, 2009 at 12:57 PM, Ben Walton wrote: >> Excerpts from Philip Brown's message of Thu Nov 19 15:43:33 -0500 2009: >>> It's a light(er)-weight photo cropping/tweaking tool. >> >> ...that requires the mono runtime. >> > > so much for light.. Euuuuu.... > A pure java based one might be interesting. http://www.jhlabs.com/ie/index.html "Java Image Editor" Looks pretty. java kinda makes it non-light. but at least it has minimal (zero) other dependancies ;-) From william at wbonnet.net Thu Nov 19 23:50:55 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 19 Nov 2009 23:50:55 +0100 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> Message-ID: <4B05CBCF.4050106@wbonnet.net> Hi > A pure java based one might be interesting. > > http://www.jhlabs.com/ie/index.html > > "Java Image Editor" > > Looks pretty. > done :) Package is ready, but license is unclear on the web site. I mailed the author for more information about the license and authorization to distribute it. I have found information about the use of the APL 2.0 license, but it is not clear if it applies to every software on the web site, or only to filters sources. I suggest that i commit to GAR and put package in testing only when the author will have answered me... I would be surprised if redistribution was not authorized, but i prefer to wait for. Any thoughts ? cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From bwalton at opencsw.org Fri Nov 20 04:00:40 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 19 Nov 2009 22:00:40 -0500 Subject: [csw-maintainers] /testing cfengine, cvsproxy, diffuse, oinkmaster, perl, snort In-Reply-To: <625385e30911180700l21c7472y67b655c7ff195249@mail.gmail.com> References: <625385e30911170911o7e76ae6bme982ec90ccd7fdc8@mail.gmail.com> <20091117205453.GA9219@vm-1.bch.net> <625385e30911180700l21c7472y67b655c7ff195249@mail.gmail.com> Message-ID: <1258686013-sup-6695@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Wed Nov 18 10:00:35 -0500 2009: Hi Peter, > Thanks a lot for that report, I've been running that perl package for > a while myself but I can't test cfengine right now. I updated cfengine on my primary server here and it looks ok to me so far. 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 Fri Nov 20 14:42:43 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 20 Nov 2009 08:42:43 -0500 Subject: [csw-maintainers] gnulinks Message-ID: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> Hi All, A user queried me today about the current setup of CSWgnulinks. He wondered why gnulinks didn't depend on all of the gnu *utils packages for which it provides links to. Part of the answer is that I simply updated the existing package and left it functionally equivalent to the previous version. I'd also be hesitant to make it so heavy weight. I wonder though, and I realize there is a pile of work involved, whether a better solution would be to have each package that uses the g prefix on binaries provide its own links in /opt/csw/gnu? This would provide a solution without extra dependencies and prevent broken symlink possibilities in /opt/csw/gnu without being an overly heavy solution (packaging work aside). Thoughts? -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 Nov 20 14:47:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 14:47:45 +0100 Subject: [csw-maintainers] gnulinks In-Reply-To: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> Message-ID: <3FD6CA1C-1808-4820-A8A5-2998E95C097C@opencsw.org> Hi Ben, Am 20.11.2009 um 14:42 schrieb Ben Walton: > A user queried me today about the current setup of CSWgnulinks. He > wondered why gnulinks didn't depend on all of the gnu *utils packages > for which it provides links to. > > Part of the answer is that I simply updated the existing package and > left it functionally equivalent to the previous version. I'd also be > hesitant to make it so heavy weight. > > I wonder though, and I realize there is a pile of work involved, > whether a better solution would be to have each package that uses the > g prefix on binaries provide its own links in /opt/csw/gnu? This > would provide a solution without extra dependencies and prevent broken > symlink possibilities in /opt/csw/gnu without being an overly heavy > solution (packaging work aside). Sounds like a good solution to me. In addition to that adding the links is not that complicated. Best regards -- Dago From dam at opencsw.org Fri Nov 20 15:22:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 15:22:49 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: <4D11E69F-0C02-4F3A-BFED-1A9268EEF8B5@opencsw.org> Hi Maciej, Am 18.11.2009 um 18:57 schrieb Maciej (Matchek) Blizinski: > On Wed, Nov 18, 2009 at 5:21 PM, Dagobert Michelsen > wrote: >> is cleanly separated from the CSW-only packages. If the "-ln" >> suffix is consistent may be discussed, in the current naming >> scheme "CSWcupslinks" would IMHO be better, but that is another >> thing. > > I couldn't decide which was better. I had the following ideas: > > CSWcupsln > CSWcupslinks > CSWcupslpdcompat > CSWcupsusrbin > CSWcups-ln > CSWcups-links > CSWcups-lpdcompat > CSWcups-usrbin > CSWcupsclientln > CSWcupsclientlinks > CSWcupsclientlpdcompat > CSWcupsclientusrbin > CSWcupsclient-ln > CSWcupsclient-links > CSWcupsclient-lpdcompat > CSWcupsclient-usrbin > > Which one do you like best? Maybe we should choose a different prefix that makes it clear that we replace a Solaris system with it. Maybe something like CSWXcupsclient which then depends on CSWcupsclient Best regards -- Dago From dam at opencsw.org Fri Nov 20 15:23:29 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 15:23:29 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: <927C1D38-948D-4830-A8C4-DB8AA20FBEDE@opencsw.org> Hi Phil, Am 18.11.2009 um 19:11 schrieb Philip Brown: > On Wed, Nov 18, 2009 at 9:21 AM, Dagobert Michelsen > wrote: >> >> I prefer the way Maciej has done it: with a separete package per >> software (Cups in this case), marked incompatible to the Solaris >> packages it replaces. > > eu, ick. I didnt notice that "feature". > > I dont think we have any business conflicting with packages that > arent "ours". If the package has files that conflict with an existing Solaris package we should conflict with it. Bets regrads -- Dago From dam at opencsw.org Fri Nov 20 15:24:33 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 15:24:33 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: Hi Phil, Am 18.11.2009 um 19:16 schrieb Philip Brown: > On Wed, Nov 18, 2009 at 10:11 AM, Philip Brown > wrote: >> >> ... >> I dont think we have any business conflicting with packages that >> arent "ours". > > Let me give just one explicit example of why: > > "pkg-get install all" I can't imagine a single use of this. Why would anybody would want all packages? There is so much special stuff in the catalog that I simply cannot imagine that anybody would actually want to install everything. Best regards -- Dago From dam at opencsw.org Fri Nov 20 15:51:50 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 15:51:50 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: <200911190723.nAJ7NgYL012355@dfki.uni-kl.de> References: <200911190723.nAJ7NgYL012355@dfki.uni-kl.de> Message-ID: Hi Nicolai, Am 19.11.2009 um 08:23 schrieb Nicolai Schwindt: > [...] >>>> There's a user request to create symlinks from /usr/bin to >>>> /opt/csw/bin, for instance, /usr/bin/lpr --> /opt/csw/bin/lpr. >>> >>> I think it's not good. >>> >>> It will fail in a zone with global /usr. >> >> It is a purely optional package that depends on cups and its whole >> purpose >> is to replace the SysV-lp system. Nothing more. If you don't want the >> system replaced you don't install this package. We may choose a >> slightly >> modifed prefix like >> CSWScups (CSW Solaris cups) >> or something to mark that it doesn't install in /opt/csw but replaced >> Solaris core functionality. > > Which I can do by adjusting the order of my PATH elements. > Nothing belongs in /usr besides what SUN puts there. The problem start when you have binaries that explicitly call /usr/bin/ lp which are distributed as binaries and you want CSW CUPS as print system. > The zones are are an example where this fails, and also the fact > that I've > seen several customer > mount /usr read only. > > Besides that, it is law - at least to me - that's why there is /opt. > This is not linux ! > > Also I do not see cupsclient as purely optional. CSWcupslibs gets > pulled in on > behave of several > packages. To be able to verify you setup one will need > CSWcupsclient. The > actual printing can > be done with the onboard toolchain. The idea is to have an ADDITIONAL package which depends on the cups client package, provides the links from the original Sun lp-system to /opt/csw/ and be incompatible with the existing print packages. > Apart from that - what happens to /usr/bin/lpr, is it deleted ? Is > SUNWpcu > deinstalled ? You must deinstall the Solaris packages first, than add the link package. > Before making such modification one should think about making his on > distribution rather than > build packages for an existing one. The idea is to have a supported system and replace the outdated parts with usable replacements. This would be cups here. So again: This is meant as an add-on. Optional. Which you may or may not install and install only if you want to replace the original print system. If you don't want to replace the original print system you install the other cups packages, but not this one. Best regards -- Dago From dam at opencsw.org Fri Nov 20 15:56:41 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 15:56:41 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> <8EB7D882-BA4E-4F0D-A90C-9C927309679C@opencsw.org> <13D7C986-698D-4D81-AD0B-95E944BC70DB@opencsw.org> Message-ID: <7B5B1DC6-D0C9-49A2-8AC8-3877C3DB9B83@opencsw.org> Hi Maciej, Am 19.11.2009 um 10:26 schrieb Maciej (Matchek) Blizinski: > On Wed, Nov 18, 2009 at 1:10 PM, Dagobert Michelsen > wrote: >> You assume that using 64 bit is always better than using 32 bit. > > That's too strong a statement. Let's put it this way: I assume it's > not significantly worse. But let's stop guessing and look at data. > Do we have any numbers on it? What's the difference in memory > footprint between 32 and 64-bit versions? > >> This >> is not the case. If you need more than 2 GB of RAM or have large >> databases you are right. > > Basically, if somebody's database is growing, we're making sure that > it's already grown big when they realize they need to switch to the > 64-bit version. The biggest concern for me is that the decision if 32 or 64 bit is used is triggered from the state of the calling OS. That means if the outer conditions from the OS change the database will change. I admit that this will most of the time not make problems, but I don't like the idea that moving to another host invalidates my db structure. Defining 32/64 statically on installation and even defaulting to 64 bit would IMHO be much better than isaexec here. >> But if the database is not that big you are >> better off using 32 bit. IMHO it is good to automatically make the >> 32/64 bit decision under the following circumstances: >> >> (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 see that any of the above applies in the case of postgres. > > So why are we building everything else with isaexec? For instance, > why do we want cups to be 64-bit enabled? We don't. As Phil explained, the libs should be available in 64 bit everytime to allow compiling apps in 64 bit that need the libraries. There is no need for an isaexec 64 bit print system. Best regards -- Dago From dam at opencsw.org Fri Nov 20 16:06:15 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 16:06:15 +0100 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: <4B05CBCF.4050106@wbonnet.net> References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> <4B05CBCF.4050106@wbonnet.net> Message-ID: <74232416-CCBA-4C8C-B925-44F1FD55C009@opencsw.org> Hi William, Am 19.11.2009 um 23:50 schrieb William Bonnet: > Hi >> A pure java based one might be interesting. >> >> http://www.jhlabs.com/ie/index.html >> >> "Java Image Editor" >> >> Looks pretty. >> > done :) > > Package is ready, but license is unclear on the web site. I mailed > the author for more information about the license and authorization > to distribute it. I have found information about the use of the APL > 2.0 license, but it is not clear if it applies to every software on > the web site, or only to filters sources. > > I suggest that i commit to GAR and put package in testing only when > the author will have answered me... I would be surprised if > redistribution was not authorized, but i prefer to wait for. Any > thoughts ? Yes. Please commit the Makefile anyway. Even if the license prohibits binary distribution we may distribute the source package in the future. Best regards -- Dago From dam at opencsw.org Fri Nov 20 16:17:25 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 16:17:25 +0100 Subject: [csw-maintainers] New cswclassutils: cswcron, cswtexinfo, cswmigrateconf and GAR integration In-Reply-To: <4B046F0F.6060509@opencsw.org> References: <0691F15A-1BF5-4817-968F-449FC848E2D7@opencsw.org> <4B046F0F.6060509@opencsw.org> Message-ID: <8D0258D5-569F-4FD5-BB5E-1A1B72209D25@opencsw.org> Hi Sebastian, Am 18.11.2009 um 23:02 schrieb Sebastian Kayser: > Dagobert Michelsen wrote on 11.11.2009 15:58: >> as of r7226 and cswclassutils 1.28 there is support for three new >> classes: >> >> - cswcron allows modifying of the crontab >> - cswtexinfo allows automatic addition of .info files to the >> texinfo dir >> - cswmigrateconf allows easy migration of config files from /opt/ >> csw/etc >> to /etc/opt/csw >> >> The usage has been documented at >> > > i have been trying to leverage MIGRATE_FILES for axel, the > cswmigrateconf stays empty though. > > ... > sysconfdir = /etc/opt/csw > SAMPLECONF = $(sysconfdir)/axelrc > MIGRATE_FILES = axelrc > ... > > skayser @ build8x ~/mgar/pkg/axel/trunk$ cat work/solaris8-i386/ > pkgroot/etc/opt/csw/pkg/CSWaxel/cswmigrateconf > MIGRATE_FILES="" > > Build files are checked in, would you mind having a look? You are right. This rule-specific assignment in GNU Make is tricky. This is hopefully fixed in r7361. Best regards -- Dago From Darin.Perusich at cognigencorp.com Fri Nov 20 16:31:42 2009 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 20 Nov 2009 10:31:42 -0500 Subject: [csw-maintainers] cswclassutils cswinetdconf Message-ID: <4B06B65E.80008@cognigencorp.com> The documentation on the wiki needs to be updated regarding this particular class. The section on this class only relates to the term 'cswinetdconf' as the class, but the class to be executed is actually 'cswinetd'. Can someone please update the docs to reflect this? Otherwise packagers attempting to use this class, like me, are going wonder why inetd isn't properly updated. Can examples for the pkginfo and prototype files be added as well. Have these examples for all classes would be very helpful. Now onto the problem. After updating my pkginfo and prototypes accordingly the conversion of the inetd entry is failing with the following. Installing class ... /opt/csw/etc/pkg/CSWcheck_mk_agent/inetd.conf inetconv: Error opening /var/opt/csw/svc/manifest/network/check_mk-tcp.xml: No such file or directory pkgadd: ERROR: class action script did not complete successfully When I perform a verbose install I see the class is trying to install the manifest into /var/opt/csw/svc/manifest/network, a directory which doesn't exist! Shouldn't the class action script create this directory if it doesn't exist or fall back on /var/svc/manifest/network? -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From dam at opencsw.org Fri Nov 20 16:35:01 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 16:35:01 +0100 Subject: [csw-maintainers] Building postgresql-8.4.1 In-Reply-To: References: <21F5F93F-2F0E-47AF-8DAA-BE75885BE06A@opencsw.org> Message-ID: <988C113A-0FD5-4D91-B3DE-8174D2620B61@opencsw.org> Hi Maciej, Am 19.11.2009 um 10:30 schrieb Maciej (Matchek) Blizinski: > On Wed, Nov 18, 2009 at 11:07 AM, Maciej (Matchek) Blizinski > wrote: >> On Wed, Nov 18, 2009 at 10:04 AM, Dagobert Michelsen >> wrote: >>> Hi Maciej, >>> >>> Am 18.11.2009 um 10:55 schrieb Maciej (Matchek) Blizinski: >>>> >>>> It persists. Your example looks different from mine: You have >>>> /opt/csw/postgresql/bin/initdb, I have >>>> /opt/csw/bin/postgresql/8.4/initdb. > > The same thing happens with pkg/mysql5/branches/mysql-5.1.x-optcsw. > It looks like GAR puts sparcv9 subdirectory always directly under > bin/, ignoring any subdirectories under bin/. I just verified, the problem is there. You are relocating postgres inside each subdirectory: /opt/csw/bin/postgres/ /opt/csw/lib/postgres/ instead of confining the installation to /opt/csw/postgres/ as it is done for e. g. Berkeley DB. This is not a problem by itself, you must however use different variables if you finegrained tune install variables. $(bindir) for example is the directory where the binaries go. It is defined as bindir_install ?= $(exec_prefix)/bin bindir ?= $(abspath $(bindir_install)/$(MM_BINDIR)) That means bindir is used directly as option to configure and GAR expects it to be adjusted the way it thinks is good. If it is adjusted manually it can be done by using the corresponding bindir_install variable. The variables that are sensitive to this are bindir, sbindir, libexecdir and libdir I adjusted your Makefile to now work fully with ISA modulations as https://sourceforge.net/apps/trac/gar/changeset/7362 Best regards -- Dago From dam at opencsw.org Fri Nov 20 16:42:32 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 16:42:32 +0100 Subject: [csw-maintainers] cswclassutils cswinetdconf In-Reply-To: <4B06B65E.80008@cognigencorp.com> References: <4B06B65E.80008@cognigencorp.com> Message-ID: Hi Darin, Am 20.11.2009 um 16:31 schrieb Darin Perusich: > The documentation on the wiki needs to be updated regarding this > particular class. The section on this class only relates to the term > 'cswinetdconf' as the class, but the class to be executed is actually > 'cswinetd'. Can someone please update the docs to reflect this? Thanks for catching this, fixed. > Otherwise packagers attempting to use this class, like me, are going > wonder why inetd isn't properly updated. Can examples for the pkginfo > and prototype files be added as well. Have these examples for all > classes would be very helpful. > > Now onto the problem. After updating my pkginfo and prototypes > accordingly the conversion of the inetd entry is failing with the > following. > > Installing class ... > /opt/csw/etc/pkg/CSWcheck_mk_agent/inetd.conf > inetconv: Error opening > /var/opt/csw/svc/manifest/network/check_mk-tcp.xml: No such file or > directory > pkgadd: ERROR: class action script did not complete successfully > > When I perform a verbose install I see the class is trying to install > the manifest into /var/opt/csw/svc/manifest/network, a directory which > doesn't exist! Shouldn't the class action script create this directory > if it doesn't exist or fall back on /var/svc/manifest/network? That should be create, yes. Ben, would you mind adding it and ask Peter to release a new version? Best regards -- Dago From william at wbonnet.net Fri Nov 20 16:46:26 2009 From: william at wbonnet.net (William Bonnet) Date: Fri, 20 Nov 2009 16:46:26 +0100 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: <74232416-CCBA-4C8C-B925-44F1FD55C009@opencsw.org> References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> <4B05CBCF.4050106@wbonnet.net> <74232416-CCBA-4C8C-B925-44F1FD55C009@opencsw.org> Message-ID: <4B06B9D2.6080003@wbonnet.net> Hi >> I suggest that i commit to GAR and put package in testing only when >> the author will have answered me... I would be surprised if >> redistribution was not authorized, but i prefer to wait for. Any >> thoughts ? > > Yes. Please commit the Makefile anyway. Even if the license prohibits > binary distribution we may distribute the source package in the future. Actually i have no source, only a jar to redistribute. cheers W. From dam at opencsw.org Fri Nov 20 16:49:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 16:49:43 +0100 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: <4B06B9D2.6080003@wbonnet.net> References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> <4B05CBCF.4050106@wbonnet.net> <74232416-CCBA-4C8C-B925-44F1FD55C009@opencsw.org> <4B06B9D2.6080003@wbonnet.net> Message-ID: <956C2ABD-DAD3-4E8A-B0F0-F5CCB0B42DF6@opencsw.org> Hi William, Am 20.11.2009 um 16:46 schrieb William Bonnet: >>> I suggest that i commit to GAR and put package in testing only >>> when the author will have answered me... I would be surprised if >>> redistribution was not authorized, but i prefer to wait for. Any >>> thoughts ? >> >> Yes. Please commit the Makefile anyway. Even if the license prohibits >> binary distribution we may distribute the source package in the >> future. > Actually i have no source, only a jar to redistribute. Hugh? "I suggest that i commit to GAR", why not commit that? Best regards -- Dago From william at wbonnet.net Fri Nov 20 16:54:24 2009 From: william at wbonnet.net (William Bonnet) Date: Fri, 20 Nov 2009 16:54:24 +0100 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: <956C2ABD-DAD3-4E8A-B0F0-F5CCB0B42DF6@opencsw.org> References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> <4B05CBCF.4050106@wbonnet.net> <74232416-CCBA-4C8C-B925-44F1FD55C009@opencsw.org> <4B06B9D2.6080003@wbonnet.net> <956C2ABD-DAD3-4E8A-B0F0-F5CCB0B42DF6@opencsw.org> Message-ID: <4B06BBB0.3050703@wbonnet.net> Dagobert Michelsen a ?crit : > Hi William, > > Am 20.11.2009 um 16:46 schrieb William Bonnet: >>>> I suggest that i commit to GAR and put package in testing only when >>>> the author will have answered me... I would be surprised if >>>> redistribution was not authorized, but i prefer to wait for. Any >>>> thoughts ? >>> >>> Yes. Please commit the Makefile anyway. Even if the license prohibits >>> binary distribution we may distribute the source package in the future. >> Actually i have no source, only a jar to redistribute. > > Hugh? "I suggest that i commit to GAR", why not commit that? > Yes no problem :) What i meant is that actually i cannot produce a source package unless i "source" the jar file. I see no real problem to distribute a way to make people create the package by themselves. I'll do it when i'll be home. cheers W. From dam at opencsw.org Fri Nov 20 16:56:29 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 16:56:29 +0100 Subject: [csw-maintainers] f-spot, anyone? In-Reply-To: <4B06BBB0.3050703@wbonnet.net> References: <1258664198-sup-5500@ntdws12.chass.utoronto.ca> <4B05CBCF.4050106@wbonnet.net> <74232416-CCBA-4C8C-B925-44F1FD55C009@opencsw.org> <4B06B9D2.6080003@wbonnet.net> <956C2ABD-DAD3-4E8A-B0F0-F5CCB0B42DF6@opencsw.org> <4B06BBB0.3050703@wbonnet.net> Message-ID: <0D76C9F6-5400-44AC-8743-0DD1964682A2@opencsw.org> Hi William, Am 20.11.2009 um 16:54 schrieb William Bonnet: > Dagobert Michelsen a ?crit : >> Hi William, >> >> Am 20.11.2009 um 16:46 schrieb William Bonnet: >>>>> I suggest that i commit to GAR and put package in testing only >>>>> when the author will have answered me... I would be surprised if >>>>> redistribution was not authorized, but i prefer to wait for. Any >>>>> thoughts ? >>>> >>>> Yes. Please commit the Makefile anyway. Even if the license >>>> prohibits >>>> binary distribution we may distribute the source package in the >>>> future. >>> Actually i have no source, only a jar to redistribute. >> >> Hugh? "I suggest that i commit to GAR", why not commit that? >> > > Yes no problem :) > > What i meant is that actually i cannot produce a source package > unless i "source" the jar file. I see no real problem to distribute > a way to make people create the package by themselves. > > I'll do it when i'll be home. The idea is to provide a manual download location and let the user fill $GARCHIVEDIR. You can see https://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/jdk6/trunk/Makefile for an example of how it could be done. Best regards -- Dago From Darin.Perusich at cognigencorp.com Fri Nov 20 17:07:45 2009 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 20 Nov 2009 11:07:45 -0500 Subject: [csw-maintainers] not displaying the license during install Message-ID: <4B06BED1.6040206@cognigencorp.com> What is the procedure for this and is it documented anywhere? -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From bwalton at opencsw.org Fri Nov 20 17:12:51 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 20 Nov 2009 11:12:51 -0500 Subject: [csw-maintainers] cswclassutils cswinetdconf In-Reply-To: References: <4B06B65E.80008@cognigencorp.com> Message-ID: <1258733431-sup-8799@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Nov 20 10:42:32 -0500 2009: Hi Darin, Dago, > > When I perform a verbose install I see the class is trying to install > > the manifest into /var/opt/csw/svc/manifest/network, a directory which > > doesn't exist! Shouldn't the class action script create this directory > > if it doesn't exist or fall back on /var/svc/manifest/network? > > That should be create, yes. Ben, would you mind adding it and ask > Peter to release a new version? Yes, I'll certainly fix that. It's not something I encountered though...I wonder if I created that directory manually on my test boxes? I didn't encounter issues adding the updated CSWgitosis on mirror.opencsw.org, either, which implies that directory existed. I'll compare cswinetd with svc/init script to see if it's creating that directory too and harmonize things. 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 Nov 20 17:37:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 17:37:28 +0100 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: <4B06BED1.6040206@cognigencorp.com> References: <4B06BED1.6040206@cognigencorp.com> Message-ID: Hi Darin, Am 20.11.2009 um 17:07 schrieb Darin Perusich: > not displaying the license during install > What is the procedure for this and is it documented anywhere? The notice displayed on install is in the package at install/copyright The real license should be in /opt/csw/share/doc//license Best regards -- Dago From dam at opencsw.org Fri Nov 20 17:43:06 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 17:43:06 +0100 Subject: [csw-maintainers] [csw-buildfarm] gmake: warning: Clock skew detected. Your build may be incomplete. In-Reply-To: References: <4B047CB6.5050007@opencsw.org> Message-ID: <479BDAAC-3A9D-44E9-BEC4-46E5C73237EE@opencsw.org> Hi, Am 19.11.2009 um 00:26 schrieb Gary Law: > 2009/11/18 Sebastian Kayser : >> I am working on build8x and build8s mostly and lately there seems to >> be a time keeping issue. At least i am seeing lots of messages >> like the following >> >> ... >> gmake: Warning: File `work/solaris8-i386/cookies/global' has >> modification time 3.3 s in the future >> ... >> gmake: warning: Clock skew detected. Your build may be incomplete. >> ... >> >> Looking at the systems, it seems as if the build.s are in sync, >> whereas >> the build.x boxes have different notions of "the current time". Could >> someone please have a look at it? > > and the time on build9x is out by 1 hour (or the timezone is wrong, > depending on your point of view) All NTP issues should be fixed. A network was disconnected from the global zone which was unused. Well, not really unused as only NTP was synchronized from there... Best regards -- Dago From james at opencsw.org Fri Nov 20 17:45:03 2009 From: james at opencsw.org (James Lee) Date: Fri, 20 Nov 2009 16:45:03 GMT Subject: [csw-maintainers] not displaying the license during install In-Reply-To: <4B06BED1.6040206@cognigencorp.com> References: <4B06BED1.6040206@cognigencorp.com> Message-ID: <20091120.16450300.3887259882@gyor.oxdrove.co.uk> On 20/11/09, 16:07:45, Darin Perusich wrote regarding [csw-maintainers] not displaying the license during install: > What is the procedure for this # pkgadd -S ... > and is it documented anywhere? It's not in the man page. James. From dam at opencsw.org Fri Nov 20 17:59:12 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 17:59:12 +0100 Subject: [csw-maintainers] Mike Watters going sabbatical Message-ID: <281EC0A2-937C-4649-8CF0-7DC95F3F1488@opencsw.org> Hi, due to high workload Mike Watters is taking a sabbatical. There are some bugs reported on his packages: http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mwatters As all of them are in GAR it should be fairly easy to fix them. Important packages are subversion, gcc4, sudo, python, squid. If anybody is interested in adopting some this would be really great. Best regards -- Dago From dam at opencsw.org Fri Nov 20 18:04:15 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 18:04:15 +0100 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: <20091120.16450300.3887259882@gyor.oxdrove.co.uk> References: <4B06BED1.6040206@cognigencorp.com> <20091120.16450300.3887259882@gyor.oxdrove.co.uk> Message-ID: <14D0FF44-B460-4D02-B0B3-63313B6A7C33@opencsw.org> Hi, Am 20.11.2009 um 17:45 schrieb James Lee: > On 20/11/09, 16:07:45, Darin Perusich > > wrote regarding [csw-maintainers] not displaying the license during > install: > >> What is the procedure for this > > # pkgadd -S ... > >> and is it documented anywhere? > > It's not in the man page. How come every time you write an email I learn something? ;-) However, it is documented in the source: Best regards -- Dago From phil at bolthole.com Fri Nov 20 18:04:48 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 09:04:48 -0800 Subject: [csw-maintainers] gnulinks In-Reply-To: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 20, 2009 at 5:42 AM, Ben Walton wrote: > > Hi All, > > A user queried me today about the current setup of CSWgnulinks. ?He > wondered why gnulinks didn't depend on all of the gnu *utils packages > for which it provides links to. > maybe because that's a LOT of packages, and may be not everyone WANTS to have all those packages automagically pulled in? From phil at bolthole.com Fri Nov 20 18:10:04 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 09:10:04 -0800 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: On Fri, Nov 20, 2009 at 6:24 AM, Dagobert Michelsen wrote: > Hi Phil, > > Am 18.11.2009 um 19:16 schrieb Philip Brown: >> >>> I dont think we have any business conflicting with packages that arent >>> "ours". >> >> Let me give just one explicit example of why: >> >> "pkg-get install all" > > I can't imagine a single use of this. Why would anybody would want all > packages? > There is so much special stuff in the catalog that I simply cannot imagine > that > anybody would actually want to install everything. That's kind of like saying, "I cant imagine anyone would do a 'full install' in solaris. there's so many packages in there, no-one will want to actually use everything". :-P People DO install everything. Because it's easier/quicker than wading through everything deciding, "Hmm, install this yes or no?" From dam at opencsw.org Fri Nov 20 18:10:36 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Nov 2009 18:10:36 +0100 Subject: [csw-maintainers] gnulinks In-Reply-To: References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> Message-ID: <4842F4C8-F165-4908-BD47-F37B3C6CCE87@opencsw.org> Hi Phil, Am 20.11.2009 um 18:04 schrieb Philip Brown: > On Fri, Nov 20, 2009 at 5:42 AM, Ben Walton > wrote: >> A user queried me today about the current setup of CSWgnulinks. He >> wondered why gnulinks didn't depend on all of the gnu *utils packages >> for which it provides links to. > > maybe because that's a LOT of packages, and may be not everyone WANTS > to have all those packages automagically pulled in? Understood. But wouldn't it be good if each package would provide his own gnulinks? Best regards -- Dago From Darin.Perusich at cognigencorp.com Fri Nov 20 18:12:36 2009 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 20 Nov 2009 12:12:36 -0500 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: References: <4B06BED1.6040206@cognigencorp.com> Message-ID: <4B06CE04.2060408@cognigencorp.com> Dagobert Michelsen wrote: > Hi Darin, > > Am 20.11.2009 um 17:07 schrieb Darin Perusich: >> not displaying the license during install >> What is the procedure for this and is it documented anywhere? > > The notice displayed on install is in the package at > install/copyright > The real license should be in > /opt/csw/share/doc//license > Yes, but when you use 'createpkg' and the prototype doesn't contain 'i copyright' it exists and tells you to add it. I'm going to assume people getting around this by including 'i copyright' in their prototypes which has a blurp about where to see the full license or bypassing 'createpkg' all together. I don't have a problem using either of these methods, I'm simply looking for a little guidance on what might be considered the best practice for accomplishing this. -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From phil at bolthole.com Fri Nov 20 18:21:22 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 09:21:22 -0800 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: <4B06CE04.2060408@cognigencorp.com> References: <4B06BED1.6040206@cognigencorp.com> <4B06CE04.2060408@cognigencorp.com> Message-ID: On Fri, Nov 20, 2009 at 9:12 AM, Darin Perusich wrote: > > > Yes, but when you use 'createpkg' and the prototype doesn't contain 'i > copyright' it exists and tells you to add it. I'm going to assume people > getting around this by including 'i copyright' in their prototypes which > has a blurp about where to see the full license... yes exactly. It's not a "getting around this" thing, it's a "what you're expected to do" sort of thing. Sorry if it isnt documented well. GAR automatically puts in a stub "here's where the copyright is" thing automagically, btw. From phil at bolthole.com Fri Nov 20 18:22:23 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 09:22:23 -0800 Subject: [csw-maintainers] Mike Watters going sabbatical In-Reply-To: <281EC0A2-937C-4649-8CF0-7DC95F3F1488@opencsw.org> References: <281EC0A2-937C-4649-8CF0-7DC95F3F1488@opencsw.org> Message-ID: On Fri, Nov 20, 2009 at 8:59 AM, Dagobert Michelsen wrote: > Hi, > > due to high workload Mike Watters is taking a sabbatical. > There are some bugs reported on his packages: > ?http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mwatters > As all of them are in GAR it should be fairly easy to fix them. > Important packages are subversion, gcc4, sudo, python, squid. > If anybody is interested in adopting some this would be really > great. > > FYI, Maciej is already working on a sudo update. From phil at bolthole.com Fri Nov 20 18:25:44 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 09:25:44 -0800 Subject: [csw-maintainers] gnulinks In-Reply-To: <4842F4C8-F165-4908-BD47-F37B3C6CCE87@opencsw.org> References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> <4842F4C8-F165-4908-BD47-F37B3C6CCE87@opencsw.org> Message-ID: On Fri, Nov 20, 2009 at 9:10 AM, Dagobert Michelsen wrote: > Hi Phil, *wave* >> maybe because that's a LOT of packages, and may be not everyone WANTS >> to have all those packages automagically pulled in? > > Understood. But wouldn't it be good if each package would provide his > own gnulinks? That's another interesting alternative. From bwalton at opencsw.org Fri Nov 20 18:28:20 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 20 Nov 2009 12:28:20 -0500 Subject: [csw-maintainers] gnulinks In-Reply-To: References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> Message-ID: <1258738007-sup-8273@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Nov 20 12:04:48 -0500 2009: > maybe because that's a LOT of packages, and may be not everyone WANTS > to have all those packages automagically pulled in? I agree with this, in principle. In practice though, the decision to not depends on everything pointed is suboptimal. Personally, I'm leaning toward the 'provide your own gnulinks' approach. If coreutils can be built (and pass tests), I'll be add links appropriately in that package...to get the ball rolling. -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 bonivart at opencsw.org Fri Nov 20 18:44:50 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 20 Nov 2009 18:44:50 +0100 Subject: [csw-maintainers] cswclassutils cswinetdconf In-Reply-To: <1258733431-sup-8799@ntdws12.chass.utoronto.ca> References: <4B06B65E.80008@cognigencorp.com> <1258733431-sup-8799@ntdws12.chass.utoronto.ca> Message-ID: <625385e30911200944rf45927clb1a5a27f320860f2@mail.gmail.com> On Fri, Nov 20, 2009 at 5:12 PM, Ben Walton wrote: > Yes, I'll certainly fix that. ?It's not something I encountered > though...I wonder if I created that directory manually on my test > boxes? ?I didn't encounter issues adding the updated CSWgitosis on > mirror.opencsw.org, either, which implies that directory existed. Cswclassutils creates /var/opt/csw/svc/manifest and maybe on your system you had a package installed using the network path because it gets created by cswinitsmf if needed. As you always use network you could just do something like this: [ ! -d $outdir ] && mkdir $outdir -- /peter From bchill at opencsw.org Fri Nov 20 19:40:05 2009 From: bchill at opencsw.org (Brian Hill) Date: Fri, 20 Nov 2009 18:40:05 +0000 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: <20091120184005.GA20699@vm-1.bch.net> On Fri, Nov 20, 2009 at 09:10:04AM -0800, Philip Brown wrote: > On Fri, Nov 20, 2009 at 6:24 AM, Dagobert Michelsen wrote: > > Hi Phil, > > > > Am 18.11.2009 um 19:16 schrieb Philip Brown: > >> > >>> I dont think we have any business conflicting with packages that arent > >>> "ours". > >> > >> Let me give just one explicit example of why: > >> > >> "pkg-get install all" > > > > I can't imagine a single use of this. Why would anybody would want all > > packages? > > There is so much special stuff in the catalog that I simply cannot imagine > > that > > anybody would actually want to install everything. > > > That's kind of like saying, "I cant imagine anyone would do a 'full > install' in solaris. there's so many packages in there, no-one will > want to actually use everything". > > > :-P > > > People DO install everything. > Because it's easier/quicker than wading through everything deciding, > "Hmm, install this yes or no?" I completely agree. When I do OS installs, I install everything. The time spent micro-deciding before system installs on what's-going-to-be-installed-where across potentially hundreds or thousands of systems is time totally wasted. It confuses users and sysadmins alike, and causes productivity interuptions when a tool or service is then suddenly needed on a system where it was thought it would not be needed. I haven't installed all of the CSW tools yet, but as soon as I find I need one, I install it on all Suns for consistency. I might install it all at some point. I also don't think there is a problem with dangling symlinks. My /usr/local tree has links that dangle depending on the OS - it's never been a problem. In short, indeed, some people either do install everything or are very likely to install everything. :-) Brian From phil at bolthole.com Fri Nov 20 20:12:02 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 11:12:02 -0800 Subject: [csw-maintainers] gnulinks In-Reply-To: <1258738007-sup-8273@ntdws12.chass.utoronto.ca> References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> <1258738007-sup-8273@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 20, 2009 at 9:28 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Nov 20 12:04:48 -0500 2009: > >> maybe because that's a LOT of packages, and may be not everyone WANTS >> to have all those packages automagically pulled in? > > I agree with this, in principle. ?In practice though, the decision to > not depends on everything pointed is suboptimal. ?Personally, I'm > leaning toward the 'provide your own gnulinks' approach. > > If coreutils can be built (and pass tests), I'll be add links > appropriately in that package...to get the ball rolling. > coreutils is kinda a sore spot. It should be an easy build, in and of itself. However, no-one so far who has mentioned it, has been willing to do the work to "nicely" transition us to it. The issue is that coreutils is a conglomerate of previously separate utils. So if you're going to replace them, you need to handle the dependancies from packages that depend on those. (Another issue, is that coreutils is a lot bigger, and it's kinda annoying to download the whole bloatware lot, if you only want one of the original pieces of it. But that's just a side issue thats kinda optional; the main issue is handling the transition smoothly) From bwalton at opencsw.org Fri Nov 20 20:21:25 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 20 Nov 2009 14:21:25 -0500 Subject: [csw-maintainers] gnulinks In-Reply-To: References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> <1258738007-sup-8273@ntdws12.chass.utoronto.ca> Message-ID: <1258744738-sup-8496@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Nov 20 14:12:02 -0500 2009: > coreutils is kinda a sore spot. It should be an easy build, in and > of itself. However, no-one so far who has mentioned it, has been > willing to do the work to "nicely" transition us to it. I'm willing to do the work and will add it to my task list. I miss 'readlink'[1] which wasn't included in the old separate packages. > (Another issue, is that coreutils is a lot bigger, and it's kinda > annoying to download the whole bloatware lot, if you only want one > of the original pieces of it. But that's just a side issue thats > kinda optional; the main issue is handling the transition smoothly) The transition shouldn't be _that_ difficult, should it? It would simply be a matter of marking itself I with CSWgfile, CSWshutils, etc, right? Given that it's a superset of those packages... -Ben [1] Apparently a few script-ish apps also miss this too. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Nov 20 20:25:02 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 11:25:02 -0800 Subject: [csw-maintainers] gnulinks In-Reply-To: <1258744738-sup-8496@ntdws12.chass.utoronto.ca> References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> <1258738007-sup-8273@ntdws12.chass.utoronto.ca> <1258744738-sup-8496@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 20, 2009 at 11:21 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Nov 20 14:12:02 -0500 2009: > >> coreutils is kinda a sore spot. It should be an easy build, in and >> of itself. ?However, no-one so far who has mentioned it, has been >> willing to do the work to "nicely" transition us to it. >.... > > The transition shouldn't be _that_ difficult, should it? ?It would > simply be a matter of marking itself I with CSWgfile, CSWshutils, etc, > right? ?Given that it's a superset of those packages... > that would be fine, if nothing depended on those packages. But... things DO depend on those packages. for example, one of them that you named, CSWshutils, has 3 packages depending on it. From bwalton at opencsw.org Fri Nov 20 20:29:33 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 20 Nov 2009 14:29:33 -0500 Subject: [csw-maintainers] gnulinks In-Reply-To: References: <1258724338-sup-3190@ntdws12.chass.utoronto.ca> <1258738007-sup-8273@ntdws12.chass.utoronto.ca> <1258744738-sup-8496@ntdws12.chass.utoronto.ca> Message-ID: <1258745329-sup-4788@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Nov 20 14:25:02 -0500 2009: > that would be fine, if nothing depended on those packages. > But... things DO depend on those packages. *face*palm*...of course. > for example, one of them that you named, CSWshutils, has 3 packages > depending on it. Ok, bigger job, but the payoff is worthwhile. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Fri Nov 20 20:43:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 20 Nov 2009 19:43:54 +0000 Subject: [csw-maintainers] Mike Watters going sabbatical In-Reply-To: References: <281EC0A2-937C-4649-8CF0-7DC95F3F1488@opencsw.org> Message-ID: On Fri, Nov 20, 2009 at 5:22 PM, Philip Brown wrote: > FYI, Maciej is already working on a sudo update. Yes, I am. I also have filed a bug against Python (deprecate the CSWpython-rt package) which is easy enough to do. There's a number of very significant packages that Mike has been maintaining. I think it's a very good thing that it's easy to continue Mike's work, and I might be building new versions of some if his packages. However, I'm slightly loathing to take on much more packages before I make sure I can keep up with the ones I have at the moment. Maciej From phil at bolthole.com Fri Nov 20 20:53:19 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 11:53:19 -0800 Subject: [csw-maintainers] Mike Watters going sabbatical In-Reply-To: References: <281EC0A2-937C-4649-8CF0-7DC95F3F1488@opencsw.org> Message-ID: On Fri, Nov 20, 2009 at 11:43 AM, Maciej (Matchek) Blizinski wrote: > On Fri, Nov 20, 2009 at 5:22 PM, Philip Brown wrote: >> FYI, Maciej is already working on a sudo update. > > Yes, I am. ?I also have filed a bug against Python (deprecate the > CSWpython-rt package) which is easy enough to do. ?There's a number of > very significant packages that Mike has been maintaining. ?I think > it's a very good thing that it's easy to continue Mike's work, and I > might be building new versions of some if his packages. ?However, I'm > slightly loathing to take on much more packages before I make sure I > can keep up with the ones I have at the moment. > The REAALLY important one,is php ! From phil at bolthole.com Fri Nov 20 20:57:26 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Nov 2009 11:57:26 -0800 Subject: [csw-maintainers] coreutils Message-ID: On Fri, Nov 20, 2009 at 11:29 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Fri Nov 20 14:25:02 -0500 2009: >> >> for example, one of them that you named, CSWshutils, has 3 packages >> depending on it. > > Ok, bigger job, but the payoff is worthwhile. > A thought: one way to handle this, over a LONG term, would be to define a virtual package CSWcoreutils (hmm.. or CSWgcoreutils, or CSWgnucoreutils might be better) which depended on all the ones it will eventually replace. Then you could focus on updating dependancies to point at the new package, over time. THEN, once things are finally all pointing at the new package, you would then be free and clear to do your original planned "easy way". Contrariwise, you could compile coreutils, but actually have it split up into the old-style packages, release it now as-is (replacing those older CSWgxxx packages), and that wya, leave the dependancies alone :-) From bwalton at opencsw.org Fri Nov 20 22:27:22 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 20 Nov 2009 16:27:22 -0500 Subject: [csw-maintainers] cswclassutils cswinetdconf In-Reply-To: <625385e30911200944rf45927clb1a5a27f320860f2@mail.gmail.com> References: <4B06B65E.80008@cognigencorp.com> <1258733431-sup-8799@ntdws12.chass.utoronto.ca> <625385e30911200944rf45927clb1a5a27f320860f2@mail.gmail.com> Message-ID: <1258752409-sup-2194@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Fri Nov 20 12:44:50 -0500 2009: > As you always use network you could just do something like this: > > [ ! -d $outdir ] && mkdir $outdir ...changes committed. Can you stick an update in testing/? 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 Nov 21 10:56:15 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 21 Nov 2009 10:56:15 +0100 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: References: Message-ID: <41050420-A9A4-4241-9332-16A4A16BF73E@opencsw.org> Hi Phil, Am 20.11.2009 um 18:10 schrieb Philip Brown: > On Fri, Nov 20, 2009 at 6:24 AM, Dagobert Michelsen > wrote: >> Hi Phil, >> >> Am 18.11.2009 um 19:16 schrieb Philip Brown: >>> >>>> I dont think we have any business conflicting with packages that >>>> arent >>>> "ours". >>> >>> Let me give just one explicit example of why: >>> >>> "pkg-get install all" >> >> I can't imagine a single use of this. Why would anybody would want >> all >> packages? >> There is so much special stuff in the catalog that I simply cannot >> imagine >> that >> anybody would actually want to install everything. > > That's kind of like saying, "I cant imagine anyone would do a 'full > install' in solaris. there's so many packages in there, no-one will > want to actually use everything". Anyway, this is not the point here. The point is: how can we integrate packages that replace existing Solaris functionality without breaking the usecase you described. I proposed a different package name prefix. Please state if this would be feasible or if you have a better idea. At least Sebastian and me are using it, so there is obiously a need for this kind of packages. The example sendmail would also be a good candidate for this. Best regards -- Dago From dam at opencsw.org Sat Nov 21 10:59:16 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 21 Nov 2009 10:59:16 +0100 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: References: <4B06BED1.6040206@cognigencorp.com> <4B06CE04.2060408@cognigencorp.com> Message-ID: Hi, Am 20.11.2009 um 18:21 schrieb Philip Brown: > On Fri, Nov 20, 2009 at 9:12 AM, Darin Perusich > wrote: >> Yes, but when you use 'createpkg' and the prototype doesn't contain >> 'i >> copyright' it exists and tells you to add it. I'm going to assume >> people >> getting around this by including 'i copyright' in their prototypes >> which >> has a blurp about where to see the full license... > > yes exactly. It's not a "getting around this" thing, it's a "what > you're expected to do" sort of thing. > Sorry if it isnt documented well. > > GAR automatically puts in a stub "here's where the copyright is" thing > automagically, btw. Am 20.11.2009 um 18:12 schrieb Darin Perusich: > I don't have a problem using either of these methods, I'm simply > looking > for a little guidance on what might be considered the best practice > for > accomplishing this. And, yes, using GAR is the best practice for this. With the sabbatical of Mike we have another excellent example why it is a good idea to have a central repository with standardized build recipes. It allowed Maciej to take over sudo in no time. Best regards -- Dago From maciej at opencsw.org Sat Nov 21 12:09:10 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 21 Nov 2009 11:09:10 +0000 Subject: [csw-maintainers] nspr in testing/ In-Reply-To: References: Message-ID: I have a question, mostly to Phil, about one shared object file in CSWnspr. Here's the prototype bit: d none /opt/csw/lib/nspr/cpu 0755 root bin d none /opt/csw/lib/nspr/cpu/sparcv8plus 0755 root bin f none /opt/csw/lib/nspr/cpu/sparcv8plus/libnspr_flt4.so 0755 root bin It looks like nspr builds one V8+ shared library on purpose. It puts it in a separate directory. All other shared libraries are V8. Normally, packages with V8+ binaries are rejected. In this case, there's a clearly separate V8+ binary, which looks optional to me. Would it be a problem to include it in the package? Or should I just exclude it? Maciej From bwalton at opencsw.org Sat Nov 21 15:11:47 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 21 Nov 2009 09:11:47 -0500 Subject: [csw-maintainers] cswclassutils cswinetdconf In-Reply-To: <4B06B65E.80008@cognigencorp.com> References: <4B06B65E.80008@cognigencorp.com> Message-ID: <1258811600-sup-8997@ntdws12.chass.utoronto.ca> Excerpts from Darin Perusich's message of Fri Nov 20 10:31:42 -0500 2009: Hi Darin, > When I perform a verbose install I see the class is trying to install > the manifest into /var/opt/csw/svc/manifest/network, a directory which > doesn't exist! Shouldn't the class action script create this directory > if it doesn't exist or fall back on /var/svc/manifest/network? There is an updated version of cswclassutils in testing/. Peter is going to release it later today, but if you want to do local tests of the packaging and install, etc, please use 1.30. 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 Sat Nov 21 21:43:09 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 21 Nov 2009 20:43:09 +0000 Subject: [csw-maintainers] Building Mozilla NSS (it aborts) Message-ID: I'm working on NSS, Mozilla's Network Security Services[1] library. I've already jumped over a number of hoops, but I'm now stuck-ish. During the build stage, a 'shlibsign' binary is called; it's part of the NSS build. At first it was (consistently) segfaulting. I figured out that it was missing a search path to libsqlite3.so, I added a runtime search path option (not via GNU make flags, I had to patch the NSS sources as their build ignores LDFLAGS and LD_OPTIONS). Now it aborts, like this: gmake[5]: Leaving directory `/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/mangle' cd SunOS5.8_OPT.OBJ ; sh /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/./sign.sh /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/../../../dist/SunOS5.8_OPT.OBJ \ /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/SunOS5.8_OPT.OBJ SunOS \ /opt/csw/lib/nspr /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/../../../dist/SunOS5.8_OPT.OBJ/lib/libsoftokn3.so /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/SunOS5.8_OPT.OBJ/shlibsign -v -i /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/../../../dist/SunOS5.8_OPT.OBJ/lib/libsoftokn3.so moduleSpec configdir='' certPrefix='' keyPrefix='' secmod='' flags=noCertDB, noModDB Abort - core dumped gmake[4]: *** [../../../dist/SunOS5.8_OPT.OBJ/lib/libsoftokn3.chk] Error 134 gmake[4]: Leaving directory `/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign' The relevant bit of truss output: 17896: stat("/opt/csw/lib/nspr/libkstat.so.1", 0xFFBFDF30) Err#2 ENOENT 17896: stat("/home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/dist/SunOS5.8_OPT.OBJ/lib/libkstat.so.1", 0xFFBFDF30) Err#2 ENOENT 17896: stat("/usr/lib/libkstat.so.1", 0xFFBFDF30) = 0 17896: resolvepath("/usr/lib/libkstat.so.1", "/usr/lib/libkstat.so.1", 1023) = 22 17896: open("/usr/lib/libkstat.so.1", O_RDONLY) = 3 17896: mmap(0xFF010000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF010000 17896: mmap(0x00000000, 81920, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON, -1, 0) = 0xFED90000 17896: mmap(0xFED90000, 4030, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFED90000 17896: mmap(0xFEDA2000, 460, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 8192) = 0xFEDA2000 17896: munmap(0xFED92000, 65536) = 0 17896: memcntl(0xFED90000, 2244, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 17896: close(3) = 0 17896: munmap(0xFF010000, 8192) = 0 17896: sigaction(SIGABRT, 0x00000000, 0xFFBFE2C8) = 0 17896: lwp_sigtimedwait(0xFFBFE2D0, 0xFFBFE220, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE210, 0xFFBFE2D0, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE2C8, 0xFFBFE560, 0x00000020) = 0 17896: llseek(0, 0, SEEK_CUR) = 7044041 17896: lwp_sigtimedwait(0xFFBFE390, 0xFFBFE250, 0x00000020) = 0 17896: lwp_sigtimedwait(0xFFBFE258, 0xFFBFE180, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE170, 0xFFBFE258, 0x00000010) = 0 17896: sigaction(SIGABRT, 0xFFBFE250, 0xFFBFE228) = 0 17896: lwp_sigtimedwait(0xFFBFE230, 0xFFBFE180, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE170, 0xFFBFE230, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE228, 0xFFBFE4B0, 0x00000020) = 0 17896: lwp_sigtimedwait(0xFF167C18, 0xFFBFE248, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE238, 0xFFBFE2C0, 0x00000010) = 0 17896: sigprocmask(SIG_SETMASK, 0xFFBFE2C0, 0xFFBFE2D0) = 0 17896: lwp_sigtimedwait(0xFFBFE2D0, 0xFFBFE248, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE238, 0xFFBFE410, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE3FC, 0xFFBFE248, 0x00000010) = 0 17896: lwp_sigtimedwait(0xFFBFE238, 0xFFBFE2C0, 0x00000010) = 0 17896: sigprocmask(SIG_SETMASK, 0xFFBFE2C0, 0x00000000) = 0 17896: lwp_kill(1, SIGABRT) = 0 17896: Received signal #6, SIGABRT [default] 17896: siginfo: SIGABRT pid=17896 uid=17108 code=-1 17896: *** process killed *** My vague plan is to alter the build so that a binary with debugging symbols is produced; then run the offending program under dbx. Before I continue attacking this build, do you have any ideas on how to proceed? Do you have any other ideas than just debugging this binary? The problem is 100% reproducible, the code is in Subversion. In order to reproduce it, one needs to have CSWnspr-devel installed (it's in testing). I was working on NSS on build8st. Maciej [1] http://www.mozilla.org/projects/security/pki/nss/ From maciej at opencsw.org Sun Nov 22 13:10:18 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 22 Nov 2009 12:10:18 +0000 Subject: [csw-maintainers] Building Mozilla NSS (it aborts) In-Reply-To: References: Message-ID: I've found the place where it aborts[1], by running shlibsign under dbx: (dbx) unOS5.8_DBG.OBJ/lib/libsoftokn3.so" < Running: shlibsign -v -i /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/../../../dist/SunOS5.8_DBG.OBJ/lib/libsoftokn3.so (process id 1696) Reading libsoftokn3.so Reading libnssutil3.so Reading libsqlite3.so.0 Reading libbsm.so.1 moduleSpec configdir='' certPrefix='' keyPrefix='' secmod='' flags=noCertDB, noModDB Reading libfreebl_32fpu_3.so Reading libkstat.so.1 t at 1 (l at 1) signal ABRT (Abort) in (unknown) at 0xff3db7b0 0xff3db7b0: bcc,pt %icc,0xff3db7c4 ! 0xff3db7c4 Current function is PR_NewLock_stub 429 abort(); (dbx) where current thread: t at 1 [1] 0xff3db7b0(0xffbfe220, 0xa3, 0x1, 0x6, 0x0, 0x6), at 0xff3db7b0 [2] 0xff3d7ff4(0x1, 0x6, 0x0, 0xfefbc000, 0xff166000, 0x0), at 0xff3d7ff4 [3] 0xff3db710(0x1, 0x6, 0x0, 0xfefbc000, 0xff166000, 0x0), at 0xff3db710 [4] raise(0x6, 0x0, 0x0, 0xffffffff, 0xfefc03cc, 0x29010), at 0xfef4bd1c [5] abort(0xfefbc000, 0xff1b3e18, 0xff1b2984, 0x1494, 0x1e90c, 0x1400), at 0xfef35a34 =>[6] PR_NewLock_stub(), line 429 in "stubs.c" [7] rng_init(), line 391 in "drbg.c" [8] PR_CallOnce(0x1494, 0xfec3ac08, 0x1400, 0x27c24, 0xfecbdcfc, 0xff1b2984), at 0xff18adcc [9] PR_CallOnce_stub(once = 0xfecbdcfc, func = 0xfec3ac08 = &`libfreebl_32fpu_3.so`drbg.c`rng_init()), line 463 in "stubs.c" [10] RNG_RNGInit(), line 469 in "drbg.c" [11] RNG_RNGInit(), line 834 in "loader.c" [12] nsc_CommonInitialize(pReserved = 0xffbfe8f4, isFIPS = 0), line 2582 in "pkcs11.c" [13] NSC_Initialize(pReserved = 0xffbfe8f4), line 2710 in "pkcs11.c" [14] softokn_Init(pFunctionList = 0xfee59224, configDir = (nil), dbPrefix = (nil)), line 474 in "shlibsign.c" [15] main(argc = 4, argv = 0xffbff314), line 802 in "shlibsign.c" (dbx) >From reading the comments at the top of the stubs.c file it looks like it's a file which defines function stubs which are to be later overriden when loading shared libraries (util and nspr). I've trussed the execution of shlibsign and as far as I can tell, it finds each and every shared object it's looking for. Also, ldd shows that it finds all the libraries: maciej at build8st [build8st]:~/src/opencsw/pkg/nss/trunk > ldd /home/maciej/src/opencsw/pkg/nss/trunk/work/build-isa-sparcv8/nss-3.12.4-with-nspr-4.8/mozilla/security/nss/cmd/shlibsign/SunOS5.8_DBG.OBJ/shlibsign /usr/lib/secure/s8_preload.so.1 libplc4.so => /opt/csw/lib/nspr//libplc4.so libplds4.so => /opt/csw/lib/nspr//libplds4.so libnspr4.so => /opt/csw/lib/nspr//libnspr4.so libthread.so.1 => /usr/lib/libthread.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 librt.so.1 => /usr/lib/librt.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libc.so.1 => /usr/lib/libc.so.1 libpthread.so.1 => /usr/lib/libpthread.so.1 libmp.so.2 => /usr/lib/libmp.so.2 libaio.so.1 => /usr/lib/libaio.so.1 /opt/csw/lib/nspr/cpu/sparcv8plus/libnspr_flt4.so /usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 I'm really stuck now. Right now, it looks like I have to see how shared libraries are loaded and how function names get overriden. Hic sunt dracones. How do I debug the order in which shared libraries are loaded and why aren't NSPR stubs overriden with the actual functions? Do you have any hints? [1] http://mxr.mozilla.org/security/source/security/nss/lib/freebl/stubs.c#424 [2] http://mxr.mozilla.org/security/source/security/nss/lib/freebl/stubs.c#38 From korpela at ssl.berkeley.edu Thu Nov 19 17:56:24 2009 From: korpela at ssl.berkeley.edu (Eric J Korpela) Date: Thu, 19 Nov 2009 08:56:24 -0800 Subject: [csw-maintainers] wxwidgets in testing/ (was: Anyone wants to update wxWidgets?) In-Reply-To: <83CED7D4-8FCB-4D9D-965F-4D8975BEEF6D@opencsw.org> References: <83CED7D4-8FCB-4D9D-965F-4D8975BEEF6D@opencsw.org> Message-ID: 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. Eric On Tue, Nov 17, 2009 at 8:45 AM, Dagobert Michelsen wrote: > Hi Erik, > > Am 16.11.2009 um 22:19 schrieb Eric J Korpela: >> >> I'll try to build boincmanager against the new libraries some time this >> week > > Cool. Let me know if you need additional machines or installs on build*t as > the > updated wxwidgets library will only be installed on build*s/x after release > and > there is still an unresolved issue. > > > Best regards > > ?-- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > From wbonnet at opencsw.org Sat Nov 21 15:26:51 2009 From: wbonnet at opencsw.org (William Bonnet) Date: Sat, 21 Nov 2009 15:26:51 +0100 Subject: [csw-maintainers] nspr in testing/ In-Reply-To: References: Message-ID: <4B07F8AB.4060607@opencsw.org> Hi > I've seen that William has done some work on the nspr library > (netscape portable runtime). I know that Firefox needs it, so I'm not > sure how is William currently compiling Firefox. I thought it would > be good to have nspr as a separate library, in case someone wants to > build a package with nspr as a dependency, such as Evolution, > xulrunner, NSS (Mozilla's Network Security Services library), etc. > I do agree. I was planning to do it one day, but it is deep in my too long todo list ;) Thanks for working on this. Actually it is need for evolution which depends on firefox only for this runtime. > I did some changes to the Makefile which was in the repository. I > took out the --with-dist-prefix and --with-dist-bindir options. I > assumed that William worked with only Firefox in mind, I want to have > a regular system library. > It was a very first version. You can modify everything you need. I stopped working on this some month ago. It seems to me that this runtime will be useful for application like evolution xulrunner, etc. but i am not sure i'll be able to use it for FF, SM or TB. Versions are different, and they need the associated NSPR which is currently provided with the package. For others application it's really cool :) cheers W. -- William Bonnet http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From rupert at opencsw.org Sun Nov 22 17:00:48 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 22 Nov 2009 17:00:48 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <20091117084609.GD1788@sebastiankayser.de> References: <4ADA85FA.7090506@opencsw.org> <20091110134933.GC30301@sebastiankayser.de> <6af4270911141103p550e49ebr208a62ae9cdf3836@mail.gmail.com> <20091117084609.GD1788@sebastiankayser.de> Message-ID: <6af4270911220800y8267bffua1e85e151a8f76e0@mail.gmail.com> On Tue, Nov 17, 2009 at 09:46, Sebastian Kayser wrote: > * rupert THURNER wrote: > >> On Tue, Nov 10, 2009 at 14:49, Sebastian Kayser <[1]skayser at opencsw.org > > > >> wrote: > >> Any progress on the "new subversion/trac packages" front? I have had > >> internal requests for 1.6.6 (quite a bit of bugfixes [1] from our > >> current/ 1.6.2) and saw that a 1.6.5 build recipe with the adjusted > >> python bindings package name is already in GAR. > > > > i compiled it and put it in testing - as we want to do that upgrade as > > well soon. i made it world writeable so anybody can overwrite it in case. > > Thanks, Rupert. The GAR build recipe for subversion skips the tests, did > you run these for the updated version? > > i did PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" rupert at build8s :~/mgar/pkg/subversion/trunk/work/solaris8-sparc/build-isa-sparcv8/subversion-1.6.6 $ make check -j $PARALLELMFLAGS Running all tests in auth-test [1/71]...success Running all tests in cache-test [2/71]...success ... but i must admit i had only the patience to wait until test 34 out of 71 on both build8x and build8s - then it started to take forever. so i wonder if this parallel make is really working, or how it could be made working? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Nov 22 17:08:08 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 22 Nov 2009 16:08:08 +0000 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <6af4270911220800y8267bffua1e85e151a8f76e0@mail.gmail.com> References: <4ADA85FA.7090506@opencsw.org> <20091110134933.GC30301@sebastiankayser.de> <6af4270911141103p550e49ebr208a62ae9cdf3836@mail.gmail.com> <20091117084609.GD1788@sebastiankayser.de> <6af4270911220800y8267bffua1e85e151a8f76e0@mail.gmail.com> Message-ID: On Sun, Nov 22, 2009 at 4:00 PM, rupert THURNER wrote: > but i must admit i had only the patience to wait until test 34 out of 71 I suggest issuing "gmake platforms" in GNU screen on the login host and going to sleep. You'll see the results the next morning. That's what I do anyway. Maciej From skayser at opencsw.org Sun Nov 22 22:28:07 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 22 Nov 2009 22:28:07 +0100 Subject: [csw-maintainers] OpenCSW Winter Camp 2009, when/where? Feedback needed. In-Reply-To: <4AC51D40.7060007@opencsw.org> References: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> <4AC51D40.7060007@opencsw.org> Message-ID: <4B09ACE7.9040307@opencsw.org> Sebastian Kayser wrote on 01.10.2009 23:21: > Sebastian Kayser wrote on 24.09.2009 19:02: >> before we head to Toronto next year in summer :D, i would like to kick off >> this year's winter camp preparations for Munich. Two votes need your >> input. >> >> - Which weekend can you participate? >> http://doodle.com/p3rvwqkx542cu4rx >> >> - Which venue would you prefer (city/nature)? >> http://doodle.com/xwnhvxp274i8b3iv > > Thanks to those who already voted, looking forward to seeing you (again) > in a couple of months. Anyone else interested in coming? If so, please > take part in the above polls so that we can plan accordingly (i will try > to fix a date and venue by the end of next week). Sorry, it has taking me so long to pick this up again. Is the 22.01. - 24.01. still a valid date for those who are interested in coming? If there are no objections, I will go ahead and book the venue this Tuesday. Sebastian From maciej at opencsw.org Sun Nov 22 22:28:06 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 22 Nov 2009 21:28:06 +0000 Subject: [csw-maintainers] nspr in testing/ In-Reply-To: <4B07F8AB.4060607@opencsw.org> References: <4B07F8AB.4060607@opencsw.org> Message-ID: On Sat, Nov 21, 2009 at 2:26 PM, William Bonnet wrote: > Thanks for working on this. ?Actually it is need for evolution which depends > on firefox only for this runtime. Right, I've seen the nss libraries in the Firefox package. Packages for Linux distributions also include the nss.pc file, which isn't there in the Firefox package. Interestingly, it's also not in the separate NSS source, distributions create custom nss.pc to allow other programs to compile. Debian also creates custom nss-config. > It was a very first version. You can modify everything you need. I stopped > working on this some month ago. It seems to me that this runtime will be > useful for application like evolution xulrunner, etc. but i am not sure i'll > be able to use it for FF, SM or TB. Versions are different, and they need > the associated NSPR which is currently provided with the package. I see. I would be curious to see how is the Firefox-bundled NSS compiled. I'm banging my head against shlibsign which won't be nice load shared objects. Maciej From dam at opencsw.org Sun Nov 22 23:01:40 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 22 Nov 2009 23:01:40 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <6af4270911220800y8267bffua1e85e151a8f76e0@mail.gmail.com> References: <4ADA85FA.7090506@opencsw.org> <20091110134933.GC30301@sebastiankayser.de> <6af4270911141103p550e49ebr208a62ae9cdf3836@mail.gmail.com> <20091117084609.GD1788@sebastiankayser.de> <6af4270911220800y8267bffua1e85e151a8f76e0@mail.gmail.com> Message-ID: Hi Rupert, Am 22.11.2009 um 17:00 schrieb rupert THURNER: > On Tue, Nov 17, 2009 at 09:46, Sebastian Kayser wrote: > * rupert THURNER wrote: > >> On Tue, Nov 10, 2009 at 14:49, Sebastian Kayser <[1]skayser at opencsw.org> > >> wrote: > >> Any progress on the "new subversion/trac packages" front? I have had > >> internal requests for 1.6.6 (quite a bit of bugfixes [1] from our > >> current/ 1.6.2) and saw that a 1.6.5 build recipe with the adjusted > >> python bindings package name is already in GAR. > > > > i compiled it and put it in testing - as we want to do that upgrade as > > well soon. i made it world writeable so anybody can overwrite it in case. > > Thanks, Rupert. The GAR build recipe for subversion skips the tests, did > you run these for the updated version? > > > > i did > > PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" > rupert at build8s:~/mgar/pkg/subversion/trunk/work/solaris8-sparc/build-isa-sparcv8/subversion-1.6.6 > $ make check -j $PARALLELMFLAGS > Running all tests in auth-test [1/71]...success > Running all tests in cache-test [2/71]...success > ... > > but i must admit i had only the patience to wait until test 34 out of 71 on both build8x and build8s - then it started to take forever. so i wonder if this parallel make is really working, or how it could be made working? Usually the tests are one script which doesn't honor parallel builds. It is only valid for builds inside make. Best regards -- Dago From bwalton at opencsw.org Sun Nov 22 23:05:20 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 22 Nov 2009 17:05:20 -0500 Subject: [csw-maintainers] coreutils In-Reply-To: References: Message-ID: <1258926663-sup-4645@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Nov 20 14:57:26 -0500 2009: > one way to handle this, over a LONG term, would be to define a > virtual package CSWcoreutils (hmm.. or CSWgcoreutils, or > CSWgnucoreutils might be better) which depended on all the ones it > will eventually replace. I don't think it's as large a task as I'd thought. The following packages have dependencies on one or more of {textutils, shutils, fileutils}. CSWquilt (Murray Jensen) CSWgardevel (me) CSWbuildbot (Maciej) CSWcswutils (Dago) CSWxmlto (me) CSWlogwatch (Christian Pearce, retired) CSWgcc3core (Peter F) CSWrubydev (me) CSWcolormake (orphaned) CSWwgetpaste (Maciej) So, of the 10 affected packages, I'm responsible for 3, Maciej 2, Dago 1 and Peter F 1. I'm not sure how active Murray is, but his status is still 'active', so presumably he'd reroll quilt. That leaves only 2 orphaned packages for pickup. Logwatch should be near trivial, I think and I'm not sure what colormake would be like. I've fixed a bunch of the breakages I found in coreutils already and we have a coreutils devel with a buildfarm account that I'll leverage to help fix anything I can't do on my own. Given the above, I think it's pretty reasonable to have all packages with deps on the old names updated and a coreutils release at the same time. Thoughts? 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 Sun Nov 22 23:14:09 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 22 Nov 2009 23:14:09 +0100 Subject: [csw-maintainers] coreutils In-Reply-To: <1258926663-sup-4645@ntdws12.chass.utoronto.ca> References: <1258926663-sup-4645@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 22.11.2009 um 23:05 schrieb Ben Walton: > Excerpts from Philip Brown's message of Fri Nov 20 14:57:26 -0500 2009: > >> one way to handle this, over a LONG term, would be to define a >> virtual package CSWcoreutils (hmm.. or CSWgcoreutils, or >> CSWgnucoreutils might be better) which depended on all the ones it >> will eventually replace. > > I don't think it's as large a task as I'd thought. The following > packages have dependencies on one or more of {textutils, shutils, > fileutils}. > > CSWquilt (Murray Jensen) > CSWgardevel (me) > CSWbuildbot (Maciej) > CSWcswutils (Dago) > CSWxmlto (me) > CSWlogwatch (Christian Pearce, retired) > CSWgcc3core (Peter F) > CSWrubydev (me) > CSWcolormake (orphaned) > CSWwgetpaste (Maciej) > > So, of the 10 affected packages, I'm responsible for 3, Maciej 2, Dago > 1 and Peter F 1. I'm not sure how active Murray is, but his status is > still 'active', so presumably he'd reroll quilt. I just got an email from him that he is still with us, but didn't have the time (yet) to jump onto GAR. Maybe we can help him to get started with a one-on-one tutorial with one of his packages. > That leaves only 2 > orphaned packages for pickup. Logwatch should be near trivial, I > think and I'm not sure what colormake would be like. Just a script, but a manual build. Should be no longer than maybe two hours or so. > I've fixed a bunch of the breakages I found in coreutils already and > we have a coreutils devel with a buildfarm account that I'll leverage > to help fix anything I can't do on my own. > > Given the above, I think it's pretty reasonable to have all packages > with deps on the old names updated and a coreutils release at the same > time. > > Thoughts? I really like to see that you are going to work on this. Will your work also include adding the gnu links inside the packages? Best regards -- Dago From bwalton at opencsw.org Sun Nov 22 23:33:18 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 22 Nov 2009 17:33:18 -0500 Subject: [csw-maintainers] coreutils In-Reply-To: References: <1258926663-sup-4645@ntdws12.chass.utoronto.ca> Message-ID: <1258929133-sup-6551@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sun Nov 22 17:14:09 -0500 2009: > I really like to see that you are going to work on this. Will your work > also include adding the gnu links inside the packages? Yes, I'll add all the gnulinks as required for the coreutils package. A few other tools (gmake, gpatch), etc would need to be updated to provide their own links too. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton at opencsw.org Mon Nov 23 01:42:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 22 Nov 2009 19:42:12 -0500 Subject: [csw-maintainers] coreutils In-Reply-To: <1258929133-sup-6551@ntdws12.chass.utoronto.ca> References: <1258926663-sup-4645@ntdws12.chass.utoronto.ca> <1258929133-sup-6551@ntdws12.chass.utoronto.ca> Message-ID: <1258936877-sup-2095@ntdws12.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Nov 22 17:33:18 -0500 2009: > Yes, I'll add all the gnulinks as required for the coreutils package. > A few other tools (gmake, gpatch), etc would need to be updated to > provide their own links too. ...I wonder if a class action script might be nice for this instead of packaged files? That way, each site could still determine whether or not /opt/csw/gnu files were desired by setting a flag in csw.conf. Thoughts? -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 Mon Nov 23 13:20:38 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 23 Nov 2009 13:20:38 +0100 Subject: [csw-maintainers] New cswclassutils: cswcron, cswtexinfo, cswmigrateconf and GAR integration In-Reply-To: <8D0258D5-569F-4FD5-BB5E-1A1B72209D25@opencsw.org> References: <0691F15A-1BF5-4817-968F-449FC848E2D7@opencsw.org> <4B046F0F.6060509@opencsw.org> <8D0258D5-569F-4FD5-BB5E-1A1B72209D25@opencsw.org> Message-ID: <20091123122038.GL1788@sebastiankayser.de> * Dagobert Michelsen wrote: > Am 18.11.2009 um 23:02 schrieb Sebastian Kayser: > >i have been trying to leverage MIGRATE_FILES for axel, the > >cswmigrateconf stays empty though. > > > >... > >sysconfdir = /etc/opt/csw > >SAMPLECONF = $(sysconfdir)/axelrc > >MIGRATE_FILES = axelrc > >... > > > >skayser @ build8x ~/mgar/pkg/axel/trunk$ cat work/solaris8-i386/ > >pkgroot/etc/opt/csw/pkg/CSWaxel/cswmigrateconf > >MIGRATE_FILES="" > > > >Build files are checked in, would you mind having a look? > > You are right. This rule-specific assignment in GNU Make is tricky. > This is hopefully fixed in r7361. Works for me. Thanks! Sebastian From maciej at opencsw.org Mon Nov 23 13:41:37 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 23 Nov 2009 12:41:37 +0000 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link Message-ID: I'm working on a library package with the *.so files in /opt/csw/lib/foo. The package will have 64-bit support, so the shared objects will be: /opt/csw/lib/foo/*.so /opt/csw/lib/foo/sparcv9/*.so /opt/csw/lib/foo/amd64/*.so I've noticed that CSWcommon provides a symlink: /opt/csw/lib/64. It points to amd64 or sparcv9 depending on the host architecture. This link is needed to provide a architecture independent -L flag for 64-bit builds: /opt/csw/lib/foo/64. I guess that something along the lines of ln -s sparcv9 /opt/csw/lib/foo/64, or amd64, depending on the architecture. What's the right GAR idiom for it? Should it be a post-merge target? Maciej From phil at bolthole.com Mon Nov 23 18:51:46 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Nov 2009 09:51:46 -0800 Subject: [csw-maintainers] not displaying the license during install In-Reply-To: References: <4B06BED1.6040206@cognigencorp.com> <4B06CE04.2060408@cognigencorp.com> Message-ID: On Sat, Nov 21, 2009 at 1:59 AM, Dagobert Michelsen wrote: > > And, yes, using GAR is the best practice for this. With the sabbatical > of Mike we have another excellent example why it is a good idea to have > a central repository with standardized build recipes. It allowed > Maciej to take over sudo in no time. > bad example :-) From phil at bolthole.com Mon Nov 23 18:53:48 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Nov 2009 09:53:48 -0800 Subject: [csw-maintainers] nspr in testing/ In-Reply-To: References: Message-ID: On Sat, Nov 21, 2009 at 3:09 AM, Maciej (Matchek) Blizinski wrote: > I have a question, mostly to Phil, about one shared object file in > CSWnspr. ?Here's the prototype bit: > > d none /opt/csw/lib/nspr/cpu 0755 root bin > d none /opt/csw/lib/nspr/cpu/sparcv8plus 0755 root bin > f none /opt/csw/lib/nspr/cpu/sparcv8plus/libnspr_flt4.so 0755 root bin > > It looks like nspr builds one V8+ shared library on purpose. ?It puts > it in a separate directory. ?All other shared libraries are V8. > Normally, packages with V8+ binaries are rejected. ?In this case, > there's a clearly separate V8+ binary, which looks optional to me. > Would it be a problem to include it in the package? ?Or should I just > exclude it? > you absolutely SHOULD include it. looks very clean. There is no global restriction about V8+ binaries. there's just a restriction against them as /opt/csw/bin/executable_here From phil at bolthole.com Mon Nov 23 18:56:06 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Nov 2009 09:56:06 -0800 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: Message-ID: On Mon, Nov 23, 2009 at 4:41 AM, Maciej (Matchek) Blizinski wrote: > I'm working on a library package with the *.so files in > /opt/csw/lib/foo. ?The package will have 64-bit support, so the shared > objects will be: > > /opt/csw/lib/foo/*.so > /opt/csw/lib/foo/sparcv9/*.so > /opt/csw/lib/foo/amd64/*.so > > I've noticed that CSWcommon provides a symlink: /opt/csw/lib/64. ?It > points to amd64 or sparcv9 depending on the host architecture. ?This > link is needed to provide a architecture independent -L flag for > 64-bit builds: /opt/csw/lib/foo/64. > > I guess that something along the lines of ln -s sparcv9 > /opt/csw/lib/foo/64, or amd64, depending on the architecture. ?What's > the right GAR idiom for it? ?Should it be a post-merge target? > Eh, that's just a convention. If the library (or packages USING the library) work as-is, there's no need for you to be making those symlinks. From phil at bolthole.com Mon Nov 23 18:59:28 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Nov 2009 09:59:28 -0800 Subject: [csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin In-Reply-To: <41050420-A9A4-4241-9332-16A4A16BF73E@opencsw.org> References: <41050420-A9A4-4241-9332-16A4A16BF73E@opencsw.org> Message-ID: On Sat, Nov 21, 2009 at 1:56 AM, Dagobert Michelsen wrote: > >> >> That's kind of like saying, "I cant imagine anyone would do a 'full >> install' in solaris. there's so many packages in there, no-one will >> want to actually use everything". > > Anyway, this is not the point here. The point is: how can we integrate > packages that replace existing Solaris functionality without breaking > the usecase you described. I proposed a different package name prefix. > Please state if this would be feasible or if you have a better idea. > At least Sebastian and me are using it, so there is obiously a need > for this kind of packages. The example sendmail would also be a good > candidate for this. > I think you are stating the "need" in an overly narrow way. Probably the "need" would be better stated as, "How can we replace sun-package functionality, WHEN THE USER CHOOSES US TO, in a way that is easy for the user?" Woudl you like to start a fresh email "thread", with that as the start prompt? (and re-mention the concern that "install all" of CSW packages, should not blow away sun stuff by default; only if the user has made some kind of choice somewhere) From phil at bolthole.com Mon Nov 23 19:02:10 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Nov 2009 10:02:10 -0800 Subject: [csw-maintainers] coreutils In-Reply-To: <1258936877-sup-2095@ntdws12.chass.utoronto.ca> References: <1258926663-sup-4645@ntdws12.chass.utoronto.ca> <1258929133-sup-6551@ntdws12.chass.utoronto.ca> <1258936877-sup-2095@ntdws12.chass.utoronto.ca> Message-ID: On Sun, Nov 22, 2009 at 4:42 PM, Ben Walton wrote: > Excerpts from Ben Walton's message of Sun Nov 22 17:33:18 -0500 2009: >> Yes, I'll add all the gnulinks as required for the coreutils package. >> A few other tools (gmake, gpatch), etc would need to be updated to >> provide their own links too. > > ...I wonder if a class action script might be nice for this instead of > packaged files? ?That way, each site could still determine whether or > not /opt/csw/gnu files were desired by setting a flag in csw.conf. > > Thoughts? > well, there's no harm in providing the /opt/csw/gnu links. If they dont like em, then just dont add /opt/csw/gnu to their path. so I dont see a need to allow the user to opt out of creating them. From maciej at opencsw.org Mon Nov 23 22:57:48 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 23 Nov 2009 21:57:48 +0000 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: Message-ID: On Mon, Nov 23, 2009 at 5:56 PM, Philip Brown wrote: > On Mon, Nov 23, 2009 at 4:41 AM, Maciej (Matchek) Blizinski > wrote: >> I'm working on a library package with the *.so files in >> /opt/csw/lib/foo. ?The package will have 64-bit support, so the shared >> objects will be: >> >> /opt/csw/lib/foo/*.so >> /opt/csw/lib/foo/sparcv9/*.so >> /opt/csw/lib/foo/amd64/*.so >> >> I've noticed that CSWcommon provides a symlink: /opt/csw/lib/64. ?It >> points to amd64 or sparcv9 depending on the host architecture. ?This >> link is needed to provide a architecture independent -L flag for >> 64-bit builds: /opt/csw/lib/foo/64. >> >> I guess that something along the lines of ln -s sparcv9 >> /opt/csw/lib/foo/64, or amd64, depending on the architecture. ?What's >> the right GAR idiom for it? ?Should it be a post-merge target? >> > > Eh, that's just a convention. If the library (or packages USING the > library) work as-is, there's no need for you to be making those > symlinks. It seems to me as those links are very useful. When you have the 64 --> {sparcv9,amd64} symlinks, you can say: LD_OPTIONS = -R/opt/csw/lib/$ISALIST -R/opt/csw/lib/64 ...and it will work on both sparcv9 and amd64. Here's how I did it in GAR: post-merge: if [ "$(GARCH)" = sparc ]; then \ gln -sf sparc9 $(PKGROOT)$(libdir)/64; \ elif [ "$(GARCH)" = i386 ]; then \ gln -sf amd64 $(PKGROOT)$(libdir)/64; \ fi @$(MAKECOOKIE) It created the right structure: maciej at build8s [build8s]:~/src/opencsw/pkg/nspr/trunk > tree work/solaris8-sparc/pkgroot/opt/csw/lib/nspr work/solaris8-sparc/pkgroot/opt/csw/lib/nspr |-- 64 -> sparc9 |-- cpu | `-- sparcv8plus | `-- libnspr_flt4.so |-- libnspr4.so -> libnspr4.so.8 |-- libnspr4.so.8 |-- libplc4.so -> libplc4.so.8 |-- libplc4.so.8 |-- libplds4.so -> libplds4.so.8 |-- libplds4.so.8 `-- sparcv9 |-- libnspr4.so -> libnspr4.so.8 |-- libnspr4.so.8 |-- libplc4.so -> libplc4.so.8 |-- libplc4.so.8 |-- libplds4.so -> libplds4.so.8 `-- libplds4.so.8 3 directories, 14 files After making the package: d none /opt/csw/lib/nspr 0755 root bin s none /opt/csw/lib/nspr/64=sparcv9 (...) I'll be able now to create NSS packages using -L/opt/csw/lib/nspr/64. From blizinski at google.com Mon Nov 23 13:36:47 2009 From: blizinski at google.com (Maciej (Matchek) Blizinski) Date: Mon, 23 Nov 2009 12:36:47 +0000 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link Message-ID: I'm working on a library package with the *.so files in /opt/csw/lib/foo. The package will have 64-bit support, so the shared objects will be: /opt/csw/lib/foo/*.so /opt/csw/lib/foo/sparcv9/*.so /opt/csw/lib/foo/amd64/*.so I've noticed that CSWcommon provides a symlink: /opt/csw/lib/64. It points to amd64 or sparcv9 depending on the host architecture. This link is needed to provide a architecture independent -L flag for 64-bit builds: /opt/csw/lib/foo/64. I guess that something along the lines of ln -s sparcv9 /opt/csw/lib/foo/64, or amd64, depending on the architecture. What's the right GAR idiom for it? Should it be a post-merge target? Maciej From dam at opencsw.org Tue Nov 24 16:41:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Nov 2009 16:41:18 +0100 Subject: [csw-maintainers] New members welcome! Message-ID: <64918FC7-ABDB-4D85-BEF8-D2C884350A7E@opencsw.org> Hi, the association welcomes the newly accepted members - Maciej Blizinski Maciej already maintains several packages including some hard updates including TightVNC and WxWidgets. 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. If you have applied for membership and don't see your name anywhere above please let me know. Best regards -- Dago From dam at opencsw.org Tue Nov 24 16:42:54 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Nov 2009 16:42:54 +0100 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: Message-ID: Hi, Am 23.11.2009 um 18:56 schrieb Philip Brown: > On Mon, Nov 23, 2009 at 4:41 AM, Maciej (Matchek) Blizinski > wrote: >> I'm working on a library package with the *.so files in >> /opt/csw/lib/foo. The package will have 64-bit support, so the >> shared >> objects will be: >> >> /opt/csw/lib/foo/*.so >> /opt/csw/lib/foo/sparcv9/*.so >> /opt/csw/lib/foo/amd64/*.so >> >> I've noticed that CSWcommon provides a symlink: /opt/csw/lib/64. It >> points to amd64 or sparcv9 depending on the host architecture. This >> link is needed to provide a architecture independent -L flag for >> 64-bit builds: /opt/csw/lib/foo/64. >> >> I guess that something along the lines of ln -s sparcv9 >> /opt/csw/lib/foo/64, or amd64, depending on the architecture. What's >> the right GAR idiom for it? Should it be a post-merge target? >> > > Eh, that's just a convention. If the library (or packages USING the > library) work as-is, there's no need for you to be making those > symlinks. If you need to include the library in any other package it is mandatory to have these links as linking is GAR goes per default against the /64 directory. Best regards -- Dago From dam at opencsw.org Tue Nov 24 16:54:58 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Nov 2009 16:54:58 +0100 Subject: [csw-maintainers] Replacing existing Solaris functionality by OpenCSW packages Message-ID: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> Hi, continuing the discussion about CUPS it would be nice to have a standardized method of replacing certain subsystems of Solaris with the corresponding OpenCSW packages. The idea is to have a base set of packages working simply as add-on which lives in the standard /opt/csw location (this is what we have now). To replace the existing Solaris subsystem an additional package is provided which links from the standard Solaris locations like /usr/bin to the OpenCSW binaries. This package depends on the CSW packages and is marked incompatible to the Solaris packages taking up the locations of the CSW links. 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 prefix The addons would be named CSWX... to mark that they are Xtra to install. On the contra side these exclusion must be hardwired to pkg* tools. - Different catalog The extra packages may be put in a separate catalog. This required a complete duplication of the current/s|i/5.x/ directory structure and could be intergated by catalog overlays alreaddy present in pkgutil. Packages which could profit from these concepts are - OpenSSH (replacing Sun SSH) - CUPS (replacing Sys V printing) - sendmail (replacing Sun sendmail) Feedback welcome! Best regards --Dago From dam at opencsw.org Tue Nov 24 17:01:52 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Nov 2009 17:01:52 +0100 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: Message-ID: Hi Maciej, Am 23.11.2009 um 22:57 schrieb Maciej (Matchek) Blizinski: > It seems to me as those links are very useful. When you have the 64 > --> {sparcv9,amd64} symlinks, you can say: > > LD_OPTIONS = -R/opt/csw/lib/$ISALIST -R/opt/csw/lib/64 > > ...and it will work on both sparcv9 and amd64. > > Here's how I did it in GAR: > > post-merge: > if [ "$(GARCH)" = sparc ]; then \ > gln -sf sparc9 $(PKGROOT)$(libdir)/64; \ > elif [ "$(GARCH)" = i386 ]; then \ > gln -sf amd64 $(PKGROOT)$(libdir)/64; \ > fi > @$(MAKECOOKIE) It is easier to use this: post-merge-modulated: gln -s $(ISA_DEFAULT64) $(PKGROOT)$(libdir)/64 @$(MAKECOOKIE) ISA_DEFAULT contains the default 32 bit ISA on this platform, ISA_DEFAULT64 contains the default 64 bit ISA on this platform. Best regards -- Dago From dam at opencsw.org Tue Nov 24 17:09:35 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Nov 2009 17:09:35 +0100 Subject: [csw-maintainers] General update of Perl to 5.10 Message-ID: <5C593CC9-E888-419F-A5F7-262215EE4561@opencsw.org> Hi Peter, I start to encounter the first modules requiring Perl 5.10: > ==> Running Makefile.PL in work/build-isa-i386/Date-Manip-6.01 > Perl v5.10.0 required--this is only v5.8.8, stopped at Makefile.PL > line 3. However, Sebastian stated that there are some serious issues in the past with 5.10. Should we wait some more ot has this already been settled? Best regards -- Dago From maciej at opencsw.org Tue Nov 24 17:30:02 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 24 Nov 2009 16:30:02 +0000 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: Message-ID: On Tue, Nov 24, 2009 at 4:01 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 23.11.2009 um 22:57 schrieb Maciej (Matchek) Blizinski: >> >> It seems to me as those links are very useful. ?When you have the 64 >> --> {sparcv9,amd64} symlinks, you can say: >> >> LD_OPTIONS = -R/opt/csw/lib/$ISALIST -R/opt/csw/lib/64 >> >> ...and it will work on both sparcv9 and amd64. >> >> Here's how I did it in GAR: >> >> post-merge: >> ? ? ? if [ "$(GARCH)" = sparc ]; then \ >> ? ? ? ? ? ? ? gln -sf sparc9 $(PKGROOT)$(libdir)/64; \ >> ? ? ? elif [ "$(GARCH)" = i386 ]; then \ >> ? ? ? ? ? ? ? gln -sf amd64 $(PKGROOT)$(libdir)/64; \ >> ? ? ? fi >> ? ? ? @$(MAKECOOKIE) > > It is easier to use this: > > post-merge-modulated: > ? ? ? ?gln -s $(ISA_DEFAULT64) $(PKGROOT)$(libdir)/64 > ? ? ? ?@$(MAKECOOKIE) > > ISA_DEFAULT contains the default 32 bit ISA on this platform, > ISA_DEFAULT64 contains the default 64 bit ISA on this platform. This fails: gln -s "sparcv9" "/home/maciej/src/opencsw/pkg/nspr/trunk/work/solaris8-sparc/pkgroot/opt/csw/lib/nspr/64/64" gln: `/home/maciej/src/opencsw/pkg/nspr/trunk/work/solaris8-sparc/pkgroot/opt/csw/lib/nspr/64/64/sparcv9': cannot overwrite directory gmake[1]: *** [post-merge-modulated] Error 1 gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/nspr/trunk' gmake: *** [merge-isa-sparcv9] Error 2 I think it's because it must be run only once per architecture, that's why I initially chose post-merge and not post-merge-modulated. Is that correct? Maciej From phil at bolthole.com Tue Nov 24 17:32:19 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 24 Nov 2009 08:32:19 -0800 Subject: [csw-maintainers] Replacing existing Solaris functionality by OpenCSW packages In-Reply-To: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> References: <3D887877-FCA6-48CD-A5D1-2FE48D18C2E3@opencsw.org> Message-ID: 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") From skayser at opencsw.org Tue Nov 24 17:36:22 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 24 Nov 2009 17:36:22 +0100 Subject: [csw-maintainers] General update of Perl to 5.10 In-Reply-To: <5C593CC9-E888-419F-A5F7-262215EE4561@opencsw.org> References: <5C593CC9-E888-419F-A5F7-262215EE4561@opencsw.org> Message-ID: <20091124163621.GQ1788@sebastiankayser.de> * Dagobert Michelsen wrote: > I start to encounter the first modules requiring Perl 5.10: > > > ==> Running Makefile.PL in work/build-isa-i386/Date-Manip-6.01 > >Perl v5.10.0 required--this is only v5.8.8, stopped at Makefile.PL > >line 3. > > However, Sebastian stated that there are some serious issues in the past > with 5.10. Should we wait some more ot has this already been settled? A former colleague of mine working with perl quite extensively pointed out those 5.10 problems (related to perl warning messages which were unable to narrow down the offending source code line). Just asked him. These problems are fixed in 5.10.1 and although he doesn't use 5.10.1 in his historically grown production environment many people from #dbix-class, #catalyst, and #moose already do. This is 2nd hand information, but doesn't sound too bad. Sebastian From dam at opencsw.org Tue Nov 24 17:38:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Nov 2009 17:38:45 +0100 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: Message-ID: <2654364D-F74C-4F13-BD30-0471BD74C9D5@opencsw.org> Hi Maciej, Am 24.11.2009 um 17:30 schrieb Maciej (Matchek) Blizinski: >> It is easier to use this: >> >> post-merge-modulated: >> gln -s $(ISA_DEFAULT64) $(PKGROOT)$(libdir)/64 >> @$(MAKECOOKIE) >> >> ISA_DEFAULT contains the default 32 bit ISA on this platform, >> ISA_DEFAULT64 contains the default 64 bit ISA on this platform. > > This fails: > > gln -s "sparcv9" > "/home/maciej/src/opencsw/pkg/nspr/trunk/work/solaris8-sparc/pkgroot/ > opt/csw/lib/nspr/64/64" > gln: `/home/maciej/src/opencsw/pkg/nspr/trunk/work/solaris8-sparc/ > pkgroot/opt/csw/lib/nspr/64/64/sparcv9': > cannot overwrite directory > gmake[1]: *** [post-merge-modulated] Error 1 > gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/nspr/trunk' > gmake: *** [merge-isa-sparcv9] Error 2 > > I think it's because it must be run only once per architecture, that's > why I initially chose post-merge and not post-merge-modulated. Is > that correct? Yes, correct, just replace the gln line and drop the -modulated. I want to get rid of the -modulated at some time but here it actually makes a difference. Maybe there is need for differentiation, I'll do some more thinking... Best regards -- Dago From phil at bolthole.com Tue Nov 24 17:50:36 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 24 Nov 2009 08:50:36 -0800 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: <2654364D-F74C-4F13-BD30-0471BD74C9D5@opencsw.org> References: <2654364D-F74C-4F13-BD30-0471BD74C9D5@opencsw.org> Message-ID: On Tue, Nov 24, 2009 at 8:38 AM, Dagobert Michelsen wrote: > > > Yes, correct, just replace the gln line and drop the -modulated. > I want to get rid of the -modulated at some time but here it > actually makes a difference. Maybe there is need for differentiation, > I'll do some more thinking... > btw, why "gln" not "ln" ?? (i'm presuming thats GNU ln, not "gar ln" :-) From maciej at opencsw.org Tue Nov 24 17:59:04 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 24 Nov 2009 16:59:04 +0000 Subject: [csw-maintainers] GAR: Adding a /opt/csw/lib/foo/64 --> /opt/csw/lib/foo/{amd64, sparcv9} link In-Reply-To: References: <2654364D-F74C-4F13-BD30-0471BD74C9D5@opencsw.org> Message-ID: On Tue, Nov 24, 2009 at 4:50 PM, Philip Brown wrote: > btw, why "gln" not "ln" ?? Once upon a time ln didn't do what I wanted it to do, and gln did. It was related to the -f flag. I tend to prefer gln since. > (i'm presuming thats GNU ln, not "gar ln" :-) It's GNU ln, but did you know that GNU stands for GAR is Not Unix? ;-) From maciej at opencsw.org Wed Nov 25 11:43:11 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 25 Nov 2009 10:43:11 +0000 Subject: [csw-maintainers] Symlinks to shared libraries Message-ID: I just got a review of my NSPR build from a NSPR/NSS developer, Wan-Teh Chang. One of the comments was to stop creating a symlink to a shared library. By default, nspr creates bare *.so files. My build script renamed them to *.so.$(MINOR_VERSION) and created symlinks from *.so to *.so.$(MINOR_VERSION). > ls -l /opt/csw/lib/nspr/libnspr4.so* lrwxrwxrwx 1 root other 13 Nov 23 23:46 /opt/csw/lib/nspr/libnspr4.so -> libnspr4.so.8 -rwxr-xr-x 1 root bin 324344 Nov 23 23:02 /opt/csw/lib/nspr/libnspr4.so.8 Do we have any policy which requires creating symlinks? I'm afraid that shipping bare unversioned libraries is going to create problems during updates. Maciej From dam at opencsw.org Wed Nov 25 12:15:56 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 25 Nov 2009 12:15:56 +0100 Subject: [csw-maintainers] Symlinks to shared libraries In-Reply-To: References: Message-ID: <6695242C-A227-40E6-9F8C-3444A89723E0@opencsw.org> Hi Maciej, Am 25.11.2009 um 11:43 schrieb Maciej (Matchek) Blizinski: > I just got a review of my NSPR build from a NSPR/NSS developer, > Wan-Teh Chang. One of the comments was to stop creating a symlink to > a shared library. By default, nspr creates bare *.so files. My build > script renamed them to *.so.$(MINOR_VERSION) and created symlinks from > *.so to *.so.$(MINOR_VERSION). > >> ls -l /opt/csw/lib/nspr/libnspr4.so* > lrwxrwxrwx 1 root other 13 Nov 23 23:46 > /opt/csw/lib/nspr/libnspr4.so -> libnspr4.so.8 > -rwxr-xr-x 1 root bin 324344 Nov 23 23:02 > /opt/csw/lib/nspr/libnspr4.so.8 > > Do we have any policy which requires creating symlinks? I'm afraid > that shipping bare unversioned libraries is going to create problems > during updates. I don't think that we have an official "policy" on this as most libraries are well-behaved. One of the real troublemakers is libnet which was packaged unversioned and has been resisted to be updated until now. Best regards -- Dago From ihsan at opencsw.org Wed Nov 25 12:18:51 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 25 Nov 2009 12:18:51 +0100 Subject: [csw-maintainers] OpenCSW Winter Camp 2009, when/where? Feedback needed. In-Reply-To: <4B09ACE7.9040307@opencsw.org> References: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> <4AC51D40.7060007@opencsw.org> <4B09ACE7.9040307@opencsw.org> Message-ID: <4B0D129B.7030205@opencsw.org> Am 22.11.2009 22:28 Uhr, Sebastian Kayser schrieb: >>> before we head to Toronto next year in summer :D, i would like to kick off >>> this year's winter camp preparations for Munich. Two votes need your >>> input. >>> >>> - Which weekend can you participate? >>> http://doodle.com/p3rvwqkx542cu4rx >>> >>> - Which venue would you prefer (city/nature)? >>> http://doodle.com/xwnhvxp274i8b3iv >> Thanks to those who already voted, looking forward to seeing you (again) >> in a couple of months. Anyone else interested in coming? If so, please >> take part in the above polls so that we can plan accordingly (i will try >> to fix a date and venue by the end of next week). > > Sorry, it has taking me so long to pick this up again. Is the 22.01. - > 24.01. still a valid date for those who are interested in coming? If > there are no objections, I will go ahead and book the venue this Tuesday. I'm very sorry, but I can't attend at these dates. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Wed Nov 25 12:20:54 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 25 Nov 2009 12:20:54 +0100 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> Message-ID: <4B0D1316.5000704@opencsw.org> Am 8.11.2009 23:58 Uhr, Maciej (Matchek) Blizinski schrieb: >>> Sebastian mentioned someone who was interested in collaborating on the >>> MySQL package. I got us up to the point where we get something which >>> passes the smoke test: we can install the package and it doesn't blow >>> right after installation. That's a nice start, but it might still be >>> a long way to go. I think the main current issue is getting the tests >>> to pass. >> What do you mean with "it doesn't blow right after installation"? > Um, I meant "blow up". I meant that the package works after you > install it and start up the database. You could make default initialisation, but from my perspective, it's not really needed. It can be also dangerous with existing databases. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Wed Nov 25 12:43:10 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 25 Nov 2009 11:43:10 +0000 Subject: [csw-maintainers] Symlinks to shared libraries In-Reply-To: <6695242C-A227-40E6-9F8C-3444A89723E0@opencsw.org> References: <6695242C-A227-40E6-9F8C-3444A89723E0@opencsw.org> Message-ID: On Wed, Nov 25, 2009 at 11:15 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 25.11.2009 um 11:43 schrieb Maciej (Matchek) Blizinski: >> >> I just got a review of my NSPR build from a NSPR/NSS developer, >> Wan-Teh Chang. ?One of the comments was to stop creating a symlink to >> a shared library. ?By default, nspr creates bare *.so files. ?My build >> script renamed them to *.so.$(MINOR_VERSION) and created symlinks from >> *.so to *.so.$(MINOR_VERSION). >> >>> ls -l /opt/csw/lib/nspr/libnspr4.so* >> >> lrwxrwxrwx ? 1 root ? ? other ? ? ? ? 13 Nov 23 23:46 >> /opt/csw/lib/nspr/libnspr4.so -> libnspr4.so.8 >> -rwxr-xr-x ? 1 root ? ? bin ? ? ? 324344 Nov 23 23:02 >> /opt/csw/lib/nspr/libnspr4.so.8 >> >> Do we have any policy which requires creating symlinks? ?I'm afraid >> that shipping bare unversioned libraries is going to create problems >> during updates. > > I don't think that we have an official "policy" on this as most libraries > are well-behaved. One of the real troublemakers is libnet which was > packaged unversioned and has been resisted to be updated until now. Perhaps it makes sense to update the package using the same binary, but